Covering the essentials of security in Kubernetes environments, this Refcard addresses the three primary areas of attack within a Kubernetes cluster. Security concepts range from the software supply chain — images, build systems, and container registry security — to Kubernetes infrastructure, as well as deploy-time and runtime security. Key examples like threat vectors, security measures, and vulnerability and violation types within each section will help you continue strengthening your Kubernetes environment security as you automate and scale the deployment and management of your cloud-native applications.
Kubernetes supports over 30 Admission Controllers. Subsequent to Authorization and Authentication, Admission Controllers are the final step in a 3-step process before Kubernetes persists the resource in etcd (a consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data). Some relevant Admission Controllers to secure running containers are:
- PodSecurityPolicy: this option implements pod admission based on security context and available policies.
- DenyEscalatingExec: when hackers open shells in privileged containers, they have access to the host. This option ensures that
exec and attach commands from privileged containers are blocked.
- AlwaysPullImages: while there is a performance advantage to storing and reusing image on a node, hygiene and the assurance that you always run up-to-date container images may be important. Since vulnerabilities are patched upstream, pulling images ensures that the latest remediation are always downloaded.
- LimitRange and ResourceQuota: to prevent denial of service attacks, and any spawning of unauthorized processes from established pods, this option observes incoming requests for violation of these limits.
- NodeRestriction: this limits the permissions of each
kubelet, ensuring that it can only modify pods that are bound to it and its own Node object.
NodeRestriction
This admission controller limits the Node and Pod objects a kubelet can modify. In order to be limited by this admission controller, kubelet must use credentials in the system:node group, with a username in the form system:node:<NodeName>. Such kubelet will only be allowed to modify their own Node API object.
Kubernetes is the most popular container orchestration platform in today's cloud-native ecosystem. Consequently, Kubernetes is also an area of increased interest and attention.
In this blog post, first I will discuss the Pod Security Policy admission controller. Then we will see how Open Policy Agent can implement Pod Security Policies. In fact, during Kubernetes SIG Auth at Kubecon + CloudNaticeCon North America 2019, Open Policy Agent/Gatekeeper was touched upon as a potential alternative to Pod Security Policy.
