This page answers to some classical questions regarding Krossboard.
Krossboard is subject to terms of use described in the NOTICE file, which is available in each release package and via our GitHub Page.
These terms of use are subject to change and may be applicable for specific versions of Krossboard.
To operate properly, Krossboard does basically need read-only access to the following permissions Kubernetes APIs:
/apis/metrics.k8s.io/v1beta1
/api/v1
For a fine-grained and least permissions set, the KUBECONFIG files provided to Krossboard can be configured with a user and service account bound to the following ClusterRole and ClusterRoleBindding.
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
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.
The following system configuration would be sufficient to run a Krossboard instance to support 10+ Kubernetes clusters.
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.
Krossboard natively handles multiple KUBECONFIG files without additional configuration settings.
You only need to copy your KUBECONFIG files in the folder /opt/krossboard/data/kubeconfig.d
on the Krossboard instance.