Overview
This tactic refers to the techniques and activities attackers leverage to steal sensitive credentials such as application secrets, passwords, and tokens. These credentials could be used by users or service accounts. In containerized environments, attackers may steal cloud or application credentials, identities, or secrets stored in the cluster. By stealing these credentials, they may get access to applications, cloud resources, or cluster resources like pods, controllers, or other Kubernetes objects.
List K8s (Kubernetes) Secrets
Kubernetes Secrets are objects that enable organizations to store and manage sensitive credentials, including passwords, tokens, keys, and connection strings in the cluster. A K8S Secret is by default, stored unencrypted in the API server's underlying data store (etcd), so anyone with access to etcd or API access can retrieve or modify a Secret. An attacker with permission to retrieve the secrets from the API server may access sensitive information, including credentials for key services, such as a database service.
Mount Service Principal
An attacker may use this technique to get access to a single container in the cluster. This may allow them to gain access to cloud credentials resources. For example, in Azure Kubernetes Service (AKS), each node contains a “service principal” credential stored in /etc/kubernetes/azure.json. Attackers who get access to this service principal file can use its credentials to access or modify the cloud resources.
Access Container Service Account (SA)
In Kubernetes, a service account (SA) is an application identity. By default, an SA is mounted to every pod in a Kubernetes cluster. It allows containers to send requests to the Kubernetes API server. An attacker who gains access to a pod can obtain the SA token and perform unauthorized actions in the cluster. If RBAC is enabled, SA privileges are determined by the role bindings associated with it. But if RBAC is not enabled, the SA token will grant the attacker unlimited permissions and full access to the cluster.
Application Credentials in Configuration Files
Secrets are stored in the Kubernetes configuration files, for example, as environment variables in the pod configuration. If an attacker has access to these configurations, either by querying the API server or accessing files on the developer’s endpoint, they would be able to steal these secrets and use them to access cluster resources.
Access Managed Identity Credential
“Managed identities” and their secrets are managed by cloud providers, allocated to cloud resources such as virtual machines, and used to authenticate with cloud services. Applications can access the Instance Metadata Service (IMDS) to obtain the identity’s token. Attackers who get access to a Kubernetes pod can take advantage of their access to the IMDS endpoint to get the managed identity’s token, and then access cloud resources.
Malicious Admission Controller
Attackers may leverage generic, malicious admission controllers built into Kubernetes, such as ValidatingAdmissionWebhook to access credentials. This controller’s behavior is determined by an admission webhook deployed in the cluster. Attackers can use this webhook to intercept requests to the API server, or to record secrets and other sensitive information.
