Protecting Kubernetes Against MITRE ATT&CK: Credential Access

Part six of our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – covers Credential Access, a set of activities intended for stealing sensitive credentials such as application secrets, passwords, and tokens that may be used by either users or service accounts. These credentials can subsequently be used to gain access to resources that include applications, cluster resources (e.g., pods, controllers, or other Kubernetes objects), cloud resources, and others.

You can find the first five articles in the series below:

• Part one - Initial Access
• Part two - Execution
• Part three - Persistence
• Part four - Privilege Escalation
• Part five - Defense Evasion
• Part seven - Discovery
• Part eight - Lateral Movement
• Part nine - Impact
  

StackRox mitigates threats related to Credential Access in several ways. It monitors Kubernetes RBAC settings for overly permissive access to secrets, enforces security policies on Deployments’ access to the Kubernetes API server, and also automatically discovers potential secrets that are passed in environment variables.

Technique 6.1: List Kubernetes secrets

Issue

Kubernetes Secrets enable organizations to store sensitive credentials such as password, tokens, and keys. An attacker may utilize this technique to gain permission to secrets from the Kubernetes API service that may include credentials for key services such as a database service.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Organizations can achieve protections for this threat by limiting access to secrets, including permissions on users and service accounts that are able to list secrets, and rotating secrets regularly. They should also use Kubernetes Namespaces to avoid accidental secret disclosures since secrets cannot be mounted across namespaces and because Kubernetes RBAC access is delineated along namespace boundaries.

How StackRox Helps

StackRox helps provide protections for this threat by automatically monitoring RBAC settings and identifying users and accounts with overly permissive access to secrets.

Technique 6.2: Mount service principal

Issue

With this technique, an attacker can leverage access to a single container to gain access to other cloud resources. Note that there is substantial overlap with Techniques 3.2 “Writable hostPath mount”, 4.3 “hostPath mount”, and 4.4 “Access cloud resources” for reference.

Real-world example: In Azure Kubernetes Service (AKS), each node contains a “service principal” credential that is stored in /etc/kubernetes/azure.json. AKS uses this service principal to create and manage Azure resources that are needed for the cluster operation. By default, the service principal has contributor permissions in the cluster’s Resource Group. Attackers who get access to this service principal file (by hostPath mount, for example) can use its credentials to access or modify the cloud resources. Note that this concept of a service principal is specific to AKS and is not directly applicable elsewhere.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

In Kubernetes, users can apply Pod Security Policies to limit the file paths that can be mounted using a host mount or disallow host mounts completely (note that Persistent Volume Claims bypass this policy) Kubernetes: They can also mark any required host paths as read-only whenever possible.

Cloud Provider

When configuring cloud provider environments, teams can limit node lifetimes by ensuring reverse uptime of 24 hours or less and automatically provision new nodes to replace them.

How StackRox Helps

The StackRox platform helps mitigate this threat by delivering dynamic policy-driven admission control as part of its platform that enables organizations to enforce security policies, including limitations on host mounts and their writability, before containers are ever deployed into Kubernetes clusters.

Technique 6.3: Access container service account

Issue

By default, a service account is mounted to every pod in a Kubernetes cluster, which allows containers to send requests to the Kubernetes API server. An attacker who gains access to a pod can obtain the service account token. If Kubernetes RBAC is not enabled, the service account token will grant the attacker full access to the cluster. If RBAC is enabled, service account privileges are determined by role bindings. If these grant elevated privileges, an attacker can make requests to the Kubernetes API server to compromise cluster resources.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Organizations can mitigate this threat vector by configuring Kubernetes RBAC and adopting a least privilege model for service accounts and their role bindings. For example, the use of the cluster-admin role should be highly restricted (see Technique 4.2 “Cluster-admin role binding”).

How StackRox Helps

StackRox helps guard against this technique by monitoring Kubernetes RBAC configurations and enforcing security policies on pod access to the Kubernetes API server.

Technique 6.4: Application credentials in configuration files

Issue

Secrets are often stored as environment variables in pod configurations and Kubernetes configuration files. Access to these configurations would allow a malicious actor to steal these secrets and access cluster resources.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Other - Open source tooling

Kubernetes

Organizations should avoid the risks of this threat vector by implementing checks and processes to ensure secrets are not passed in Kubernetes manifests, which are used to create, modify and delete Kubernetes resources.

Other - Open source tooling

Organizations can consider using open source tools to identify secrets that have been added to source control.

How StackRox Helps

StackRox helps mitigate this technique by providing a built-in policy that identifies potential secrets being stored in environment variables.