With security context, you can even limit the user ID and group ID with which the container must be run. readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.įor demo purposes, we only need to add one small section in to the container spec: securit圜ontext:Īnd, if the image runs as root, it will fail at deployment.
AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has CAP_SYS_ADMIN. This bool directly controls whether the no_new_privs flag gets set on the container process. AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process.Seccomp: Filter a process's system calls.AppArmor: Use program profiles to restrict the capabilities of individual programs.Linux Capabilities: Give a process some privileges, but not all the privileges of the root user.Security Enhanced Linux (SELinux): Objects are assigned security labels.Discretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID).Security context settings include, but are not limited to: 1.2 Security ContextĪ security context defines privilege and access control settings for a Pod or Container. But how about the pod? If an image doesn't have a USER instruction, K8s will still allow it.Įnter security context. So, now we have sorted it out from the container level. We have changed the user with which the container will be run. So, by simply adding this line in the Dockerfile: USER 1000:1000 The USER instruction sets the user name (or UID), and optionally the user group (or GID) to use when running the image, and for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile. With Docker, you can use the USER instruction. You can deploy the test in K8s by running the following commands: git clone k8s-security-demo
WHAT IS KUBERNETES POD CODE
If you want to try it yourself, the code used for this section is shown in this pull request here. Since there aren't any restrictions, K8s will allow this pod to run as the root user. Image: ironcore864/k8s-security-demo:pod-as-non-root If we use this image to run a pod in a K8s cluster, consider the following container spec: # omitted above Since the user with which to run the container isn't explicitly set, if you start a Docker container with this image, the container process is running as root: /app $ whoami If you do the bare minimum and absolutely nothing else, by default, the Docker container will run as the root user, and K8s will allow it to do so.Ĭonsider the following Dockerfile: # omitted above
WHAT IS KUBERNETES POD HOW TO
how to do Docker image scan locally and with your CI pipelines.how to use immutable root fs (lock the root filesystem).Let's start with Pod security.Īfter reading this article, you will learn: Today, we will follow the advice of the second article and do some hands-on work to have a deeper understanding. Hardening Your Kubernetes Cluster - Guidelines (Pt. Hardening Your Kubernetes Cluster - Threat Model (Pt. If you haven't read them yet, here are the links: In my previous two articles, we discussed Kubernetes security and created a guideline for enhancing K8s. Tiexin Guo Senior DevOps Consultant, Amazon Web Services