Controller of pods with the ability to read secrets

About Controllers and Service Accounts

Kubernetes controllers are responsible for monitoring the cluster state and making any necessary changes to move the current state as close as possible to the desired state. The desired state is the cluster’s operational structure defined via configuration files.

For example, a configuration file specifies running three instances of the same application. When the cluster starts, Kubernetes spawns three pods for the application. Now, let’s suppose one of the pods goes down. It’s the controller’s job to observe this change, spawn a new application pod, and move the current state back to the desired state.

When processes inside a Kubernetes pod try to access the kube-apiserver, they authenticate themselves using a service account. A service account is an identity assigned to a Kubernetes pod upon creation. The same service account can then be used by all of the pod’s processes to communicate with the API server.

If the controller detects that there isn’t a service account specified for a pod, it creates the pod with the default service account. The authorization policy of the service account determines the levels of API access the pod’s processes will have.

For example, a service account may allow a pod to only get meta-information regarding the cluster. Another service account may allow pods to update whatever they want at the apiserver. It’s important to follow the principle of least privilege while granting service account permissions. It’s also important to not create service accounts that allow reading sensitive information like Kubernetes secrets.

Cloud Risk Description

A controller is creating pods with a service account that allows reading secrets in a namespace or cluster. Kubernetes secrets are objects that contain security-critical information like passwords, tokens, or keys.

If a malicious actor gains access to any pod’s container, they can extract the tokens of other service accounts and use them to steal all the secrets of 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. Orca can even scan containers for vulnerabilities in pods that are either paused or stopped. In this specific case (as seen in the above screenshot), Orca has detected that the Controller read-secrets creates pods with a role that allows reading secrets in the rnd namespace or eks-dev cluster. 

Related Risks

• Controller creating pod with privileged Docker: Docker privileged mode grants a pod container root permissions for all the devices on the host system. This is in violation of the principle of least privilege. If a cybercriminal gains access to the container, they can use it to compromise the entire system.
• Controller of pods with administrator-like permissions in cluster scope: A controller is creating new pods with a service account that allows the pods to perform any and all operations on the API server. This violates the principle of least privilege.

Recommended Mitigation Strategies

• 

  Consider removing the rules that allow pods to read secrets.

• 

  Follow the principle of least privilege when granting permissions to service accounts.

• 

  If your pods run different applications and/or serve different use-cases, consider creating different service accounts for them.

• 

  Use encryption to secure Kubernetes secrets.

• 

  Use a logging framework to monitor and analyze Kubernetes and OS logs.

Useful Links

• Kubernetes controllers: https://kubernetes.io/docs/concepts/architecture/controller/
• Configuring service accounts for pods: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
• Kubernetes authorization overview: https://kubernetes.io/docs/reference/access-authn-authz/authorization/
• Kubernetes API server: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
• Kubernetes secrets: https://kubernetes.io/docs/concepts/configuration/secret/