This page answers questions users may have.
To work properly, Krossboard basically needs read-only permissions to the following Kubernetes API:
For a fine-grained permissions set with only the required permissions, the credentials can be configured using the following ClusterRole and ClusterRoleBindding definition. definition.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: krossboard labels: app: krossboard rules: - apiGroups: - "" resources: - namespaces - nodes - pods verbs: - get - list - watch - apiGroups: - metrics.k8s.io resources: - nodes - nodes/stats - pods verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: krossboard labels: app: krossboard roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: krossboard subjects: - kind: ServiceAccount name: krossboard
Any KUBECONFIG file with credentials allowing this minimum set of permissions should be sufficient.
When deployed to automatically discover and handle managed Kubernetes (GKE, AKS, EKS), Krossboard requires appropriate cloud IAM permissions. These are read-only permissions. You can review the setup scripts to get more details.
However, during the deployment, administration permissions on the cloud platform are required to configure the instance with appropriate privileges.
Connect with SSH on the instance and restart the service:
sudo systemctl restart krossboard-ui
If your Krossboard instance has been deployed against managed Kubernetes (e.g. Google GKE, Microsoft AKS or AWS EKS), the deployment script ends up with a summary listing all the cloud resources created during the installation (e.g. IAM role, security group, service account, etc.).
If you want to completely remove Krossboard from your cloud environment, you just have to remove all those resources.