Lateral movement

Controller of pods with administrator-like permissions in cluster scope

Risk Level

Hazardous (3)

Platform(s)

  • Non-platform specific

Compliance Frameworks
  • EKS CIS
    • ,
  • GDPR
    • ,
  • GKE CIS
    • ,
  • HITRUST
    • ,
  • K8s CIS
    • ,
  • NIST 800-53

About Controllers and Roles

A primary responsibility of Kubernetes controllers is to create new pods when required. For instance, a controller may spawn a new pod if another crashes or malfunctions. Or it may launch multiple new pods to auto-scale the cluster during peak hours.

Every pod is assigned a service account (SA) upon creation. If no user-defined SA is specified, the default SA is auto-assigned to the pod. An SA serves as the pod’s identity. All applications running inside a pod can use the SA to communicate with the kube-apiserver.

The privileges of a service account are determined by the RBAC Role or ClusterRole attached to it. Both Role and ClusterRole define a set of permissions, with the primary differences being that ClusterRoles are non-namespaced and apply to the entire cluster. 

To associate a Role or ClusterRole to a SA, you have to create a RoleBinding or ClusterRoleBinding respectively. For example, the following command binds the ClusterRole “secretreader” to the service account “myserviceaccount”, granting all the permissions of the ClusterRole to the service account.

kubectl -n test create clusterrolebinding allowreadingsecrets \

–clusterrole=secretreader \

–serviceaccount=test:myserviceaccount

There are two main components of a Role/ClusterRole specification: resources and verbs. The former contains a list of all the allowed resources, and the latter determines which operations a service account can be used to perform. For example, a Role may specify “pods” as resources and [“get”, “list” “create”] as verbs.

Practice the principle of least privilege when specifying resources and verbs.

Cloud Risk Description

A controller is creating pods with a service account that’s bound to a ClusterRole with resources and verbs both set to [“*”]. This allows unrestricted, administrator-like privileges to the pods across the cluster scope. 

If an attacker gains access to any pod’s container, they can extract the service account token and use its privileged permissions to access the Kubernetes API and perform any arbitrary actions on the cluster.

How Orca Helps

With support for CIS Kubernetes benchmarks, Orca will give you details of passed and failed control checks with extensive details around failed checks for the cloud infrastructure plane and Kubernetes Pods. 

With Orca’s agentless design, you also gain two important advantages: complete 100% visibility of both the Kubernetes control plane nodes, the Pods, and the containers within them.In this specific case (as seen in the above screenshot), Orca has detected that the Controller {K8sController} creates pods with a service account which has administrative (all verbs on all resources) privileges in {K8sController.PodSpec.K8sCluster} cluster, going against the principle of least privilege.

Orca

Orca Security, the cloud security innovation leader, provides cloud-wide, workload-deep security and compliance for AWS, Azure, and GCP － without the gaps in coverage, alert fatigue, and operational costs of agents.

Need help?

Get a free Security Risk Assessment. Start today

Demo the Orca Platform

In just 10 minutes, you’ll see how Orca Security can revolutionize your cloud security strategy. Watch a recorded demo from a cloud security expert now.

Get a Demo