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.
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.
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.
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.
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.