Kubernetes permissions

What Kubernetes' permissions CAST AI components use

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 GroupResourcesVerbs
corepods, nodes, replicationcontrollers, persistentvolumeclaims, persistentvolumes, servicesget, list, watch
appsdeployments, replicasets, daemonsets, statefulsetsget, list, watch
storage.k8s.iostorageClasses, csinodesget, list, watch
batchjobsget, 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 GroupResourcesVerbsDescription
appsdeploymentspatchUsed 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 GroupResourcesVerbsDescription
corepods, nodesget, list
corenodespatch, updateUsed for node draining and patching.
corepods, nodesdelete
certificates.k8s.iocertificatesigningrequestsget, list, delete, createUsed for creating a new certificate when adding a node to the cluster.
certificates.k8s.iocertificatesigningrequests/approvalpatch, updateUsed for creating a new certificate when adding a node to the cluster.
certificates.k8s.iosignersapproveApplicable only for kubelet.
coreeventslist, create, patch
rbac.authorization.k8s.ioroles, clusterroles, clusterrolebindingsget, patch, update, delete, escalateApplicable to all CAST AI components.
corenamespacesdeleteApplicable 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 GroupResourcesVerbsDescription
coreeventscreate, patch
corenodesget, list, watch, patch, updateUsed to find a suitable node for eviction.
corepodsget, list, watch, patch, update, create, deleteList pods to find a suitable node for eviction and delete a stuck pod from the node.
appsreplicaSetsgetUsed to find out if it's safe to evict a pod (it belongs to RS and has replicas).
corepods/evictioncreateUsed for pod eviction.
coordination.k8s.ioleases*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 GroupResourcesVerbsDescription
corenodescreate, delete, getRequired to execute pod pinning actions
corepodsdelete, get, listRequired to execute pod pinning actions
corepods/bindingcreateRequired to execute pod pinning actions
admissionregistration.k8s.iomutatingwebhookconfigurationslist, watchRequired for Webhook functionality
admissionregistration.k8s.iomutatingwebhookconfigurationswatch, get, patch, updateRequired for Webhook functionality.
Scoped to pod-pinner resource only