Kubernetes Security Risks and Hardening Recommendations

Kubernetes has become the de‑facto container orchestration platform, but its widespread adoption brings numerous security risks that span the cloud infrastructure, the cluster control plane, and the workloads running inside containers.

1. Cloud‑level risks

Public‑cloud accounts with high‑privilege RAM permissions (e.g., ram:CreateAccessKey , ram:AttachPolicyToUser , ram:UpdateRole combined with sts:AssumeRole ) can manage the entire Kubernetes cluster. Default administrator policies such as QcloudCAMPFullAccess (Tencent Cloud) and AdministratorAccess (Alibaba Cloud) grant these rights. The recommendation is to follow the principle of least privilege and remove unnecessary high‑risk permissions from RAM accounts.

2. Cluster‑level risks

2.1 Etcd data encryption – Unencrypted etcd stores sensitive data. Enable KMS‑based encryption for etcd in Tencent Cloud TKE, Alibaba Cloud ACK, or on‑prem clusters (see the referenced documentation links).

2.2 Etcd authentication – Without certificate authentication, anyone with etcd access can read secrets. Example query to list secret keys:

# 查询 etcd 中存储的 secret 信息
./etcdctl --endpoints=127.0.0.1:2379 get / --prefix --keys-only | grep secret

Default ServiceAccounts such as namespace-controller have admin rights. Tokens can be extracted via etcdctl:

# 获取 namespace-controller-token-nkx2x token 信息
./etcdctl --endpoints=127.0.0.1:2379 get /registry/secrets/kube-system/namespace-controller-token-nkx2x

After obtaining the token, an attacker can list pods:

TOKEN='eyJhbGciOi...'
curl -ik -H "Authorization: Bearer $TOKEN" https://10.0.0.80:6443/api/v1/pods

Fix: add --client-cert-auth=true and proper certificates to the etcd startup parameters:

- --cert-file=/etc/kubernetes/pki/etcd/server.crt
- --client-cert-auth=true
- --key-file=/etc/kubernetes/pki/etcd/server.key
- --advertise-client-urls=https://10.0.0.80:2379
- --listen-client-urls=https://127.0.0.1:2379,https://10.0.0.80:2379
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

2.3 API Server authentication – Versions < 1.16 expose the unauthenticated 8080 port. Verify with curl http:// host :8080 . Ensure system:anonymous has no extra permissions beyond get:configmaps/cluster-info .

2.4 Kubelet authentication – Unauthenticated access to /runningpods/ or /run/ can leak pod data. Example:

# 执行 curl 请求, 如果存在 kubelet 未授权访问则会列出当前节点运行的 Pod 信息
curl -k https://10.0.0.80:10250/runningpods/

Fix: set authentication.anonymous.enabled: false and authorization.mode: Webhook in kubelet config.yaml :

authentication:
  anonymous:
    enabled: false
authorization:
  mode: Webhook

3. High‑privilege users & ServiceAccounts

Reduce bindings to cluster-admin , limit secrets read access, and audit create pod permissions. Example Neo4j‑style query to list users with cluster-admin :

match p=(n)-[relation:ActTo]->(r) where r.name='cluster-admin' return distinct labels(n), n.kind as 账号类型, n.name as 账号名称, r.name as 角色名称, relation.namespace as 关系命名空间

Check secrets access:

# 获取 secrets
kubectl get secrets default-token-sr6zg -o yaml

Detect users with create pods permission and bind them to high‑privilege ServiceAccounts:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: create-pod-account
---
kind: ClusterRole
metadata:
  name: create-pod-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create"]
---
kind: ClusterRoleBinding
metadata:
  name: create-pod-rolebinding
subjects:
- kind: ServiceAccount
  name: create-pod-account
  namespace: default
roleRef:
  kind: ClusterRole
  name: create-pod-clusterrole
  apiGroup: rbac.authorization.k8s.io

Bind‑verb abuse example (grant cluster-admin via a ServiceAccount with bind permission):

# 绑定了高权限 serviceaccount
kubectl --as=system:serviceaccount:default:bind-account create rolebinding rbac-cluster-admin --clusterrole=cluster-admin --serviceaccount=default:bind-account

Impersonation risk – a ServiceAccount with impersonate can act as system:master and read all secrets:

# 使用 impersonate 权限
curl -ik -H "Authorization: Bearer $TOKEN" -H "Impersonate-User: system:master" https://10.0.0.80:6443/api/v1/secrets

Escalate verb, nodes/proxy, certificate‑signing‑request approval, webhook configuration, and serviceaccount/token creation are also highlighted with corresponding Neo4j queries and YAML examples.

4. Workload‑level risks

Image metadata may contain hard‑coded credentials – scan images with tools like Trivy. Example query for containers running vulnerable images exposed externally:

match (image:Image)-[:ExistVul]->(vul:Vulnerability) where vul.severity='CRITICAL' with image match (container)-[:BaseOn]->(image) with container match p=(container)-[:ControllerBy|OpenTo*1..]->(s:Service) where s.type <> 'ClusterIP' return distinct container.name, s.name

4.1 Privileged containers – securityContext.privileged: true enables host filesystem access. Example deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: privileged-deployment
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        securityContext:
          privileged: true

Fix: query all privileged containers and evaluate necessity:

match (c:Container)-[:ControllerBy*1..]->(p) where c.privileged=true return distinct labels(p), p.name, p.namespace

4.2 hostPID – Pods with hostPID: true can inspect host processes and environment variables. Example pod spec and command to dump all env files:

apiVersion: v1
kind: Pod
metadata:
  name: hostpid
spec:
  hostPID: true
  containers:
  - name: ubuntu
    image: ubuntu
    command: ["/bin/sh", "-c", "while true; do sleep 30; done;"]

for e in `ls /proc/*/environ`; do echo; echo $e; xargs -0 -L1 -a $e; done > envs.txt

Fix: locate such pods and prioritize removal, especially when combined with privileged containers.

match (p:Pod)-[:ControllerBy*0..]->(n) where p.hostPID=true return distinct labels(n), n.name, n.namespace

4.3 SYS_ADMIN capability – Allows loading host kernel modules. Example malicious kernel module source ( evilmodule.c ) and Makefile are provided. Build the module on a host with the same kernel version, copy it into the pod, and load with insmod evilmodule.ko to obtain a reverse shell.

Fix: query containers with SYS_ADMIN in addCapabilities and remediate:

match (c:Container)-[:ControllerBy]->(pod:Pod)-[:ControllerBy*0..]->(obj) where 'SYS_ADMIN' in c.addCapabilities return distinct labels(obj), obj.name, obj.namespace

4.4 SYS_MODULE capability – Enables loading kernel modules from the container. Same remediation pattern as SYS_ADMIN.

4.5 hostPath mounts – Mounting sensitive host paths (e.g., /var/log , / , /etc , .ssh , docker.sock ) can lead to credential theft or node compromise. Neo4j query to find such mounts:

MATCH p=(c:Container)-[r:MountStorage]->(s:Storage) WHERE s.storageType='hostPath' WITH apoc.convert.fromJsonMap(s.volumeSource, '$.hostPath') AS hp, c WHERE hp.path IN ['/var/log/','/','/proc','/root','/etc'] OR hp.path CONTAINS '.ssh' OR hp.path CONTAINS '.bashrc' OR hp.path CONTAINS 'docker.sock' OR hp.path CONTAINS '/etc/cron.d' OR hp.path CONTAINS '/var/spool/cron' OR hp.path = '/etc/crontab' WITH hp, c MATCH p=(c)-[:ControllerBy*1..3]->(n:Pod|Deployment|StatefulSet|DaemonSet) RETURN distinct n.name, n.namespace, hp.path

Conclusion

Audit all high‑privilege accounts, bind them to concrete use‑cases, restrict network exposure, and establish baselines using API‑server audit logs. When high‑privilege accounts deviate from normal behavior, trigger immediate investigation.

References:

https://github.com/neargle/my-re0-k8s-security

https://unit42.paloaltonetworks.com/kubernetes-privilege-escalation/

https://github.com/BloodHoundAD/BloodHound