Initial access Execution Persistence Privilege escalation Defense evasion Credential access Discovery Lateral movement Collection Impact
Using Cloud Exec into Container Backdoor Container Privileged Container Clear Container Logs List K8s secrets Access the K8s API server Access cloud resources Images from a private repository Data Destruction
Compromised images in registry bash/cmd in container Writable hostPath mount Cluster-admin binding Delete k8s events Mount service principal Access Kubelet API Container service account Ressource hijacking
Kubeconfig file New container Kubernetes CronJob hostPath mount Pod / container name similarity Access container service account Network mapping Cluster internal networking Denial of Service
Application vulnerability Application exploit (RCE) Malicious admission controller Access cloud resources Connect from proxy server Applications credentials in configuration files Access Kubernetes dashboard Applications credentials in configuration files
Exposed sensitive interfaces SSH server running in inside container Disable Namespacing Access managed identity credentials Instance metadata API Writable volume mounts on the host
Sidecar injection Malicious admission controller CoreDNS poisoning
ARP poisoning and IP spoofing

List K8s secrets

A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services.

Example

Create a ClusterRole secret-reader that can read secrets:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Create a service account and a ClusterRoleBinding for the secret-reader ClusterRole

apiVersion: v1
kind: ServiceAccount
metadata:
  name: secret-reader
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: secret-reader-binding
subjects:
  - kind: ServiceAccount
    name: secret-reader
    namespace: default
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Create secret for the secret-reader service account (needed for Kubernetes >=1.24 as no secrets for service accounts will be auto-generated by default):

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: secret-reader
  annotations:
    kubernetes.io/service-account.name: "secret-reader"

We can now read all secrets in our Kubernetes cluster:

$ kubectl auth can-i --list --as system:serviceaccount:default:secret-reader
Resources                                       Non-Resource URLs                     Resource Names   Verbs
selfsubjectaccessreviews.authorization.k8s.io   []                                    []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                                    []               [create]
secrets                                         []                                    []               [get watch list]
...

If we create a pod which uses the secret-reader service account as follows, the token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token can be used by an attacker to perform the actions described above:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccount: secret-reader
  containers:
  - image: nginx
    name: my-pod

References