6. Credential Access in the Kubernetes – ATT&CK® Matrix
MITRE’s ATT&CK®
List Kubernetes secrets
A Kubernetes secret is an object that lets users store and manage sensitive information, such as passphrases and connection strings in the cluster. Consuming the Secrets by referencing in the pod configuration is quite easy—attackers who have permissions to retrieve the secrets from the API server. By using the pod service account, for instance, can access sensitive information that might include credentials to various services.
Mount service principal
When the cluster is deployed in the cloud, in some cases, intruders can leverage their access to a container in the cluster to obtain cloud credentials. For instance, in AKS, each node contains service principal credential.
Access container service account
Service account (SA) represents an application identity in Kubernetes. By default, an SA is mounted to every created pod in the cluster. Using the SA, containers in the pod can send requests to the Kubernetes API server. Attackers who get access to a pod can access the SA token (located in /var/run/secrets/kubernetes.io/serviceaccount/token) and perform actions in the cluster, according to the SA permissions. If RBAC is not enabled, the SA has unlimited permissions in the cluster. If RBAC is activated, its permissions are determined by the RoleBindings \ ClusterRoleBindings that are correlated with it.
Application credentials in configuration files
Usually, developers store secrets in the Kubernetes configuration files, such as environment variables in the pod configuration. Azure Security Center observes such behaviours very frequently. Attackers who have access to those configurations, by querying the API server or by accessing those files on the developer’s endpoint, can steal the stored secrets and use them.