{"id":444,"date":"2024-10-29T10:16:21","date_gmt":"2024-10-29T10:16:21","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=444"},"modified":"2024-10-29T10:16:21","modified_gmt":"2024-10-29T10:16:21","slug":"run-kubernetes-pod-as-non-root-user","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=444","title":{"rendered":"How To Run Kubernetes Pod as Non-Root User?"},"content":{"rendered":"

In this blog, we will look at how to run containers inside a Kubernetes pod<\/a> run as a non-root user.<\/p>\n

We will look at pod and container-level security contexts to define non-root users.<\/p>\n

SecurityContext in Kubernetes<\/h2>\n

To run pods as non-root users, first, you need to understand SecurityContext<\/code> Kubernetes.<\/p>\n

In Kubernetes, the securityContext<\/code><\/strong> configuration feature defines pod or container-level security settings. We will use securityContext<\/code><\/strong> it to run the container with a specific non-root user.<\/p>\n

It is one of the simple and efficient ways to improve the security of your containers; it has two types:<\/p>\n

    \n
  1. Pod-level<\/strong> – This security context applies to all the containers in the pod.<\/li>\n
  2. Container-level <\/strong>– This security context applies to individual containers.<\/li>\n<\/ol>\n

    SecurityContext<\/strong> has many security options. We will use the runAsUser<\/strong> parameter specifically to control the user used by the container.<\/p>\n

    Container Image Configuration for Non-Root User Compatibility<\/h2>\n

    Even if you set up a SecurityContext<\/code><\/strong> to enforce non-root user policies, the container image itself must support running as a non-root user.<\/p>\n

    This means the container image should be configured with the necessary user permissions and should not rely on root privileges to execute processes inside the container.<\/p>\n

    For example, if you are using a Nginx image, the Nginx process inside the image<\/strong> should be able to run as a non-root user, similar to<\/strong> how you would run a Nginx process as a non-root user in Linux.<\/p>\n

    This is because the nginx process inherently writes to several locations owned by the root user (like \/var\/log\/nginx<\/code> for logs or \/var\/cache\/nginx<\/code> for cache). Therefore, we need to modify the container image to assign specific permissions to a non-root user (e.g., nginxuser<\/code>) to allow modification of these files.<\/p>\n

    You can configure it while building the Docker image<\/a>. You can refer to building non-root container image<\/a> guide to know more.<\/p>\n

    Also, if the process you run inside the container doesn\u2019t need access to any files owned by root or root privileges, it won\u2019t be a problem. For example, running a BusyBox container with a simple shell script doesn\u2019t need an image-level non-root configuration unless you are writing to files owned by root.<\/p>\n

    \n
    Important Note: <\/strong><\/b>If the container image isn\u2019t properly configured for non-root execution for processes that need access to files or directories owned by the root user , setting non-root policies in Kubernetes will not be effective, and the pod will throw an error.<\/div>\n<\/div>\n

    Container Images With Non Root User<\/h2>\n

    We need to use the following images to understand Pod Non-Root user implementation better.<\/p>\n

    Two images with non-root user configuration, one is exposed to port 8080 and the other to port 9090 to avoid port conflict.<\/p>\n

    Use the Dockerfile in this GitHub repo<\/a> to create both images. Check the running containers as a non-root user<\/a> guide to learn more about creating a Docker image with a non-root user.<\/p>\n

    \n
    Note<\/strong><\/b>: If you just want to learn about the functionality , you can use our images specified on this guide<\/div>\n<\/div>\n

    Kubernetes Pod Non-Root User Configurations<\/h2>\n

    When we say Kubernetes pod<\/a>, it can have more than one container. You can apply the securityContext<\/code><\/strong> configuration at the pod and container levels.<\/p>\n

    To understand it better, we will look at the following use cases that use container images with non-root users:<\/p>\n

      \n
    1. Running the pod with pod-level security context<\/strong> in which both container images have non-root users. (Should run without any issues)<\/li>\n
    2. Running the pod with a pod-level security context, but in this one container image has a non-root user, and the other container image doesn’t have a root user. (The one without root user should fail)<\/li>\n
    3. Running the pod with a container-level security context<\/strong> involves running one container as a non-root user and the other as a root user (Both should run without any issues)<\/li>\n
    4. Running pod with both pod-level and container-level security context (Container-level security context overrides the pod-level context)<\/li>\n<\/ol>\n

      Use Case 1: Running Containers as a non-root user with a pod with the pod-level security context<\/h3>\n

      For this use case, we will use a container image that has non-root user configuration<\/strong> as part of its image.<\/p>\n

      We will run a pod with pod-level security context<\/strong> in which both container images have non-root users.<\/strong><\/p>\n

      Create a file called pod-level.yaml<\/code><\/strong> and copy the below manifest file content.<\/p>\n

      apiVersion: v1\nkind: Pod\nmetadata:\n  name: testing-pod\nspec:\n  securityContext:\n    runAsUser: 1001\n  containers:\n  - name: first-container\n    image: techiescamp\/nginx-non-root-01:1.0.0\n    ports:\n    - containerPort: 8080\n  - name: second-container\n    image: techiescamp\/nginx-non-root-02:1.0.0\n    ports:\n    - containerPort: 9090<\/code><\/pre>\n
      \n
      Note<\/strong><\/b>: You can also set runAsNonRoot: true<\/code> that will set the non-root user from the container image automatically.<\/div>\n<\/div>\n
      Then, run the following command to apply the manifest file to deploy the pod with pod-level security context.<\/p>\n
      kubectl apply -f pod-level.yaml<\/code><\/pre>\n
      Now, how to check if pod is running as root?<\/p>\n
      Once the pod is up and running, use the  kubectl exec<\/code> command with linux id<\/code><\/strong> command to check if the pod is running as root or non root user.<\/p>\n
      kubectl exec testing-pod -c first-container -- id\n\nkubectl exec testing-pod -c second-container -- id<\/code><\/pre>\n
      You will get the following output.<\/p>\n
      \"output<\/figure>\n
      You can see both containers are running on UID 1001,<\/strong> which is the UID of non-root users.<\/p>\n
      Does this mean kubectl exec command logins as non root user?<\/p>\n
      When you use the kubectl exec<\/code> command to start a session in a container running with a non-root user, you will be logged in as that non-root user.<\/p>\n
      This means that:<\/p>\n
        \n
      1. Any commands you run will have the permissions of the non-root user that the container is using.<\/li>\n
      2. You will not have root (superuser) privileges inside the container.<\/li>\n<\/ol>\n
        Use Case 2: Running the pod with a pod-level security context with only one container as non-root user<\/h3>\n
        In the second use case, we will run a pod with a pod-level security context, but in this, one container has a non-root user, and the other container doesn’t run as a root user.<\/p>\n
        In this use case, we expect one of the containers that runs as root to end up in CrashLoopBackoff<\/code><\/strong> because of the pod level non-root user securityContext.<\/p>\n
        For this use case, use the same pod-level.yaml<\/strong> used in the above use case.<\/p>\n
        Just change the image of the first-contianer<\/strong> to the official Nginx image as given below.<\/p>\n
        apiVersion: v1\nkind: Pod\nmetadata:\n  name: testing-pod\nspec:\n  securityContext:\n    runAsUser: 1001\n  containers:\n  - name: first-container\n    image: nginx:latest\n    ports:\n    - containerPort: 8080\n  - name: second-container\n    image: techiescamp\/nginx-non-root-02:1.0.0\n    ports:\n    - containerPort: 9090<\/code><\/pre>\n
        We will be using the official nginx: latest<\/strong> image to test what happens if the container runs with an inactive user.<\/p>\n
        Apply the manifest file and check the pod’s status using the following command.<\/p>\n
        kubectl get po<\/code><\/pre>\n
        You can see that only one pod is ready, and another pod crashes continuously because the first container doesn’t have a non-user with UID 1001.<\/p>\n
        If you want to run the container as a non-root user, you must first create the user during the container image creation.<\/p>\n
        The second container runs without any issues because it has a non-root user with UID 1001.<\/p>\n
        \"output<\/figure>\n
        Run the following command to check the pod logs.<\/p>\n
        kubectl logs testing-pod<\/code><\/pre>\n
        You can see the following error because the UID we gave is only available for the second container,<\/strong> not for the first container<\/strong>.<\/p>\n
        2024\/10\/09 10:32:06 [emerg] 1#1: mkdir() \"\/var\/cache\/nginx\/client_temp\" failed (13: Permission denied)\nnginx: [emerg] mkdir() \"\/var\/cache\/nginx\/client_temp\" failed (13: Permission denied)<\/code><\/pre>\n
        Because of the unavailable UID, it doesn’t have permission to access the directors to run Nginx.<\/p>\n
        If you check for the UID the containers are using, you will get the following output<\/p>\n
        \"output<\/figure>\n
        Use Case 3: Running the pod with a container-level security context to use different users on containers<\/h3>\n
        In the third use case, we will be running the pod with a container-level security context,<\/p>\n
          \n
        1. run one container as a non-root user<\/li>\n
        2. other as a root user.<\/li>\n<\/ol>\n
          Create a file called container-level.yaml<\/strong> and copy the manifest file content below.<\/p>\n
          apiVersion: v1\nkind: Pod\nmetadata:\n  name: testing-pod\nspec:\n  containers:\n  - name: first-container\n    image: techiescamp\/nginx-non-root-01:1.0.0\n    ports:\n    - containerPort: 8080\n    securityContext:\n        runAsUser: 1001\n  - name: second-container\n    image: techiescamp\/nginx-non-root-02:1.0.0\n    ports:\n    - containerPort: 9090\n    securityContext:\n        runAsUser: 0<\/code><\/pre>\n
          In the above manifest file, the security content is given inside each container with a different UID, which tells the containers to run with a non-root user (1001) and a root user (0).<\/p>\n
          \n
          By default, the UID 0 will be assigned to the root user.<\/div>\n<\/div>\n
          Run the following command to apply the manifest file to deploy the pod with the pod-level security context.<\/p>\n
          kubectl apply -f container-level.yaml<\/code><\/pre>\n
          Once the pod is up and running, use the following command to check in which users the container is running.<\/p>\n
          kubectl exec testing-pod -c first-container -- id\n\nkubectl exec testing-pod -c second-container -- id<\/code><\/pre>\n
          You will get the following output.<\/p>\n
          \"Output<\/figure>\n
          You can see the first container is running with the non-root user(1001), and the second container is running with the root user(0).<\/p>\n
          Use Case 4: Running pod with both pod-level and container-level security context<\/h3>\n
          In the final use case, we will run the pod with pod-level and container-level security contexts.<\/strong><\/p>\n
          We will specify to run as a non-root user in the pod-level security context and define one container to run as a root user using the container-level security context.<\/p>\n
          Create a file called pod.yaml<\/strong> and copy the manifest file content below.<\/p>\n
          apiVersion: v1\nkind: Pod\nmetadata:\n  name: testing-pod\nspec:\n  securityContext:\n    runAsUser: 1001\n  containers:\n  - name: first-container\n    image: techiescamp\/nginx-non-root-01:1.0.0\n    ports:\n    - containerPort: 8080\n  - name: second-container\n    image: techiescamp\/nginx-non-root-02:1.0.0\n    ports:\n    - containerPort: 9090\n    securityContext:\n        runAsUser: 0<\/code><\/pre>\n
          As you can see in the above manifest, the first container is defined to run as a non-root user in the pod-level security context, and the second container is defined to run as a root user using the container-level security context.<\/p>\n
          Let’s apply the manifest file and see what happens. Run the following command to apply the manifest file.<\/p>\n
          kubectl apply -f pod.yaml<\/code><\/pre>\n
          Once the pod is up and running, use the following command to check in which users the container is running.<\/p>\n
          kubectl exec testing-pod -c first-container -- id\n\nkubectl exec testing-pod -c second-container -- id<\/code><\/pre>\n
          You will get the following output.<\/p>\n
          \"Output<\/figure>\n
          You can see the first container is running with the non-root user(1001), and the second container is running with the root user(0).<\/p>\n
          This means the container-level security context overrides the pod-level security context.<\/strong><\/p>\n
          FAQ’s<\/h2>\n
          How to run pod with non-root user?<\/h3>\n
          Using securityContext<\/code><\/strong> parameter and runAsUser<\/strong> subfield, you can run a pod with non root user. In the runAsUser<\/strong> parameter you can specify the username or userid.<\/p>\n
          Conclusion<\/h2>\n
          Running pods as non-root use is one of the best security practice. It minimizes the risks associated with potential vulnerabilities by limiting the privileges of the application inside the container.<\/p>\n
          So to strengthen the overall security posture<\/strong> of your Kubernetes environment, you can implement this from the development stages. You can add checks using tools like Trivy<\/a> in your Docker build pipelines to ensure container images are built with only with non-root users.<\/p>\n
          You can also prevent pods from deploying that doesnt run as non-root using kubernetes built-in admission controller called Pod Security Admission<\/strong>.<\/p>\n
          Also, implementing Kubernetes policy management tools like Kyverno to prevent pods from running as the root user by checking fields like runAsNonRoot<\/code>. It can also validate existing workloads for security misconfigurations.<\/p>\n
          Now, we would like to know your thoughts?<\/p>\n
          Are you planning to implement non-root user pods in your environment?<\/p>\n
          Are you planning to implement policy management tools to ensure compliance?<\/p>\n
          Let us know the comments.<\/p>\n
          \n
          Ngu\u1ed3n:<\/strong> How To Run Kubernetes Pod as Non-Root User? \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
          Source: https:\/\/devopscube.com\/run-kubernetes-pod-as-non-root-user\/<\/p>\n","protected":false},"author":1,"featured_media":445,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-444","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/444","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=444"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/444\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/445"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=444"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=444"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=444"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}