Kubernetes Service Accounts and permissions used by CAST AI components

CAST AI components running on your clusters use predefined service accounts and relevant permissions to be able to perform functions such as, sending data about the cluster state. This section discusses all required service accounts and permissions granted to CAST AI components.

Kubernetes Service Accounts used by CAST AI components

Each CAST AI component installed in your cluster uses a dedicated service account. Such a setup allows you to fine-tune permissions for each component:

» kubectl get serviceAccounts -n castai-agent
NAME                        SECRETS   AGE
castai-agent                1         46h
castai-cluster-controller   1         4h20m
castai-evictor              1         4h20m
castai-spot-handler         1         4h20m
default                     1         46h

The CAST AI agent's permissions (Read-only)

The CAST AI agent collects cluster operational details (snapshots) and delivers them to the central platform to assess if there is room for optimization. That's why it must get cluster-wide permissions:

API Group	Resources	Verbs
core	pods, nodes, replicationcontrollers, persistentvolumeclaims, persistentvolumes, services	get, list, watch
core	namespaces	get
apps	deployments, replicasets, daemonsets, statefulsets	get, list, watch
storage.k8s.io	storageClasses, csinodes	get, list, watch
batch	jobs	get, list, watch

The CAST AI agent's resource consumption vastly depends on the cluster size. The agent must be able to adjust resource limits proportionally to the size of your cluster. For that purpose, Cluster Proportional Vertical Autoscaler patches the CAST AI agent's deployment with re-estimated limits, which requires the following permission:

API Group	Resources	Verbs	Description
apps	deployments	patch	Used only to patch the `castai-agent` deployment

Cluster controller's permissions

CAST AI's cluster controller component gets installed when your connected cluster moves to Phase 2, in which you can enable managed cost savings:

» kubectl get deployments -n castai-agent
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
castai-agent                1/1     1            1           43h
castai-cluster-controller   2/2     2            2           64m
castai-evictor              0/0     0            0           64m

Cluster-wide permissions used by the cluster controller

The cluster controller operates mostly on the cluster level as it performs operations required to optimize its costs:

API Group	Resources	Verbs	Description
core	namespaces	get
core	pods, nodes	get, list
core	nodes	patch, update	Used for node draining and patching.
core	pods, nodes	delete
core	pods/eviction	create
certificates.k8s.io	certificatesigningrequests	get, list, delete, create	Used for creating a new certificate when adding a node to the cluster.
certificates.k8s.io	certificatesigningrequests/approval	patch, update	Used for creating a new certificate when adding a node to the cluster.
certificates.k8s.io	signers	approve	Applicable only for kubelet.
core	events	list, create, patch
rbac.authorization.k8s.io	roles, clusterroles, clusterrolebindings	get, patch, update, delete, escalate	Applicable to all CAST AI components.
core	namespaces	delete	Applicable only to the CAST AI agent.

Namespace-wide (castai-agent) permissions used by the cluster controller

One of the main tasks of the cluster controller is to update CAST AI components. The cluster controller is granted with all permissions in castai-agent namespace necessary for current and future changes.

Additionally, it includes two cluster-wide permissions for managing the RBAC of CAST AI components and the possibility of deleting the CAST AI namespace (see above).

Evictor permissions

When onboarding the cluster to Phase 2 for automated cost optimization, CAST AI installs more components than the cluster controller. One such component is Evictor, which minimizes the number of nodes your cluster uses.

Cluster-wide permissions used by Evictor

When installed, Evictor handles non-CAST AI pods, so it requires a set of cluster-wide permissions:

API Group	Resources	Verbs	Description
core	events	create, patch
core	nodes	get, list, watch, patch, update	Used to find a suitable node for eviction.
core	pods	get, list, watch, patch, update, create, delete	List pods to find a suitable node for eviction and delete a stuck pod from the node.
apps	replicaSets	get	Used to find out if it's safe to evict a pod (it belongs to RS and has replicas).
core	pods/eviction	create	Used for pod eviction.
coordination.k8s.io	leases	*	Used for leader election when there may be a single instance active.

Pod Pinner permissions

To function correctly, Pod Pinner requires the following cluster-wide permissions:

API Group	Resources	Verbs	Description
core	nodes	create, delete, get	Required to execute pod pinning actions
core	pods	delete, get, list	Required to execute pod pinning actions
core	pods/binding	create	Required to execute pod pinning actions
admissionregistration.k8s.io	mutatingwebhookconfigurations	list, watch	Required for Webhook functionality
admissionregistration.k8s.io	mutatingwebhookconfigurations	watch, get, patch, update	Required for Webhook functionality. Scoped to `pod-pinner` resource only