Top 10 Kubernetes Application Security Hardening Techniques

When deploying applications to a Kubernetes cluster, developers face the challenge of managing security risks. A quick way to address this is to harden the application manifests during development. This article introduces ten techniques developers can apply to strengthen their applications.

General Methods

All workload manifests (Pods, Deployments, DaemonSets, etc.) contain a securityContext section where security parameters can be specified.

runAsUser, runAsGroup

Containers run as the root user by default, which is insecure. Setting non‑zero runAsUser and runAsGroup values in the securityContext forces the container to run as a non‑root user.

Ensure the container image itself supports the chosen UID/GID, typically by adding a USER instruction in the Dockerfile.

Privileged

The privileged flag removes most security isolation and should be avoided unless absolutely necessary. Set privileged: false in the securityContext by default.

Capabilities

Linux capabilities grant specific root‑only privileges. The best practice is to drop all capabilities and only add those explicitly required by the application.

Read‑Only Root Filesystem

Setting readOnlyRootFilesystem: true makes the container’s root filesystem immutable, forcing any writable data to be placed on a separate volume such as an emptyDir .

AllowPrivilegeEscalation

This flag controls whether a child process can gain more privileges than its parent. Set allowPrivilegeEscalation: false in the securityContext when not needed.

Seccomp

Seccomp profiles filter system calls that containers can make. Enable the default profile or provide a custom one. In Kubernetes 1.18 and earlier, Seccomp is enabled via annotations; from 1.19 onward it is part of securityContext .

Resource Limits

Define CPU and memory requests and limits to prevent a single container from exhausting node resources.

Image Tag

Avoid using the mutable latest tag. Specify an immutable tag or the image’s SHA‑256 digest to ensure the exact image version is deployed.

AppArmor

For Debian‑based distributions, AppArmor profiles add a mandatory security layer. Custom profiles are added via annotations in the pod metadata.

SELinux

For Red Hat‑based distributions, SELinux provides a similar mandatory access control mechanism. Using the default policy is usually sufficient; custom policies can be created for higher‑security environments.

Conclusion

Creating a secure Kubernetes environment involves many aspects, from the control plane to the workloads running on the cluster. Proactively hardening the manifests used to deploy workloads early in the development lifecycle significantly improves security and reduces vulnerability risk.

References

[1] Original article: https://blog.aquasec.com/kubernetes-hardening-techniques