Kubernetes Security: Common Risks and How to Test Them

Kubernetes runs much of the modern internet, and its flexibility means there are many ways to misconfigure it. A single over-privileged pod or exposed API can give an attacker control of the whole cluster.

Exposed control plane and dashboards

• API server reachable from the internet without network restrictions.
• Kubernetes Dashboard exposed with weak or no authentication.
• Kubelet API accessible without authentication on older or misconfigured nodes.
• etcd exposed, which stores all cluster secrets.

Fix: restrict API server access to known networks or private endpoints, avoid exposing the Dashboard, enable kubelet authentication and keep etcd private.

Over-privileged workloads

Pods running with:

• privileged: true
• Host namespaces such as hostPID or hostNetwork
• Host path mounts, especially the container runtime socket
• Running as root with writable filesystems
• Excessive Linux capabilities

Any of these can allow escaping the container to the node.

Fix: enforce Pod Security Standards, typically the restricted profile, with Pod Security Admission or a policy engine.

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

Weak RBAC

• Service accounts with cluster-admin.
• Roles granting * on *.
• Permissions to create pods, read secrets, or create role bindings, which enable escalation.
• Default service account tokens mounted into every pod.

Fix: least privilege roles, separate service accounts per workload, and automountServiceAccountToken: false where not needed.

Secrets handling

Kubernetes Secrets are base64-encoded, not encrypted, unless encryption at rest is enabled. Anyone who can read secrets in a namespace has them all.

Fix: enable encryption at rest, restrict secret read access, and consider an external secrets manager.

Network policies

By default, every pod can reach every other pod. A compromised frontend pod can talk directly to databases.

Fix: apply default-deny network policies and explicitly allow required traffic.

Cloud metadata from pods

Pods can often reach the cloud metadata service and obtain node credentials.

Fix: use workload identity features from your cloud provider, block metadata access from pods, and enforce IMDSv2 hop limits on AWS.

Supply chain

• Images from untrusted registries.
• Outdated base images with known vulnerabilities.
• Mutable latest tags.

Fix: scan images, pin digests, use minimal base images and sign images.

Kubernetes security checklist

Testing Kubernetes exposure

External testing should check for exposed API servers, dashboards, kubelets and ingress-routed services. SecurityInfinity's network and recon agents find exposed Kubernetes components and test the applications running behind your ingress. Start free.

Frequently asked questions

Is managed Kubernetes secure by default?

Managed services secure the control plane infrastructure, but workload configuration, RBAC and network policies are your responsibility.

What is a container escape?

Breaking out of a container's isolation to access the host node, often enabled by privileged settings or kernel vulnerabilities.

Do I need a service mesh for security?

Not necessarily. Network policies and good RBAC cover the essentials. A mesh can add mutual TLS and finer traffic control.