Ensuring Pod Security for Containerized Applications in Kubernetes

Overview

In Kubernetes Pod Security Standards, different isolation levels for Pods are specified. With the help of these standards, you may specify how you want to clearly and consistently limit the behavior of pods.

Kubernetes provides a built-in Pod Security admission controller to enforce the Pod Security Standards. When creating a pod, security constraints are implemented at the namespace level.

Pod Security Modes and Levels

Pod Security admission places requirements on a Pod’s Security Context and other related fields according to the three levels defined by the Pod Security Standards:

Privileged – The Privileged policy is wide-open and entirely unrestricted. Typically, this policy targets workloads at the system and infrastructure levels that privileged, trusted users control.
Baseline – The Baseline policy is minimally restrictive policy that prevents known privilege escalations. It allows the default (minimally specified) Pod configuration. This policy is targeted at application operators and developers of non-critical applications.
Restricted – The Restricted policy is aimed at enforcing current Pod hardening best practices at the expense of some compatibility. It is targeted at operators, developers of security-critical applications, and lower-trust users. You can configure namespaces to define the admission control mode you want to use for pod security in each namespace.
Enforce – In this mode, policy violations will cause the pod to be rejected for creation.
Audit – Policy violations will trigger the addition of an audit annotation to the event recorded in the audit log, but pod creation will be allowed.
Warn – Policy violations will trigger a user-facing warning, but pod creation will be allowed.

Cloud Migration
Devops
AIML & IoT

Know More

Step-by-Step Guide

Step 1. Create an Amazon EC2 instance and AWS IAM Role.

Create an AWS IAM role
Add permission to the role to give Amazon EC2 full access and administrator access to Amazon EC2. Give the Role name and click on Create.
Create Amazon EC2 instance of t2.medium and ubuntu 20.4 LTS.
Under the advanced setting, attach the AWS IAM instance profile and select the role you created.
Add the following tags to your instance.

Note: In the security group, make sure to add 6443, 2379 port number or else you can also allow all ports.

Step 2. After cluster setup, perform the below tasks.

Create 3 namespace using the following command

kubectl create ns dev
kubectl create ns staging
kubectl create ns prod

kubectl create ns dev

kubectl create ns staging

kubectl create ns prod

Assign labels to the namespace by executing following command:

kubectl label ns dev pod-security.kubernetes.io/enforce=baseline
kubectl label ns prod pod-security.kubernetes.io/enforce=restricted
kubectl label ns staging pod-security.kubernetes.io/enforce=privileged

kubectl label ns dev pod-security.kubernetes.io/enforce=baseline

kubectl label ns prod pod-security.kubernetes.io/enforce=restricted

kubectl label ns staging pod-security.kubernetes.io/enforce=privileged

Step 3. Create below YAML files

privileged-pod.yaml – giving priviliged access to the pod

apiVersion: v1
kind: Pod
metadata:
  name: busypod-priliveged
spec:
  containers:
    - image: busybox
      name: busybox
      command: ["sh", "-c", 'while true; do echo "Running..."; sleep 2h; done']
      imagePullPolicy: Always
      securityContext:
        privileged: true
        runAsUser: 0
        allowPrivilegeEscalation: true
        readOnlyRootFilesystem: false
        capabilities:
          add: ["CAP_SYS_BOOT"]

apiVersion: v1

kind: Pod

metadata:

spec:

containers:

- image: busybox

command: ["sh", "-c", 'while true; do echo "Running..."; sleep 2h; done']

imagePullPolicy: Always

securityContext:

privileged: true

runAsUser: 0

allowPrivilegeEscalation: true

readOnlyRootFilesystem: false

capabilities:

add: ["CAP_SYS_BOOT"]

baseline-pod.yaml – giving baseline access to the pod

apiVersion: v1
kind: Pod
metadata:
  name: busypod-baseline
spec:
  containers:
    - image: busybox
      name: busybox
      command: ["sh", "-c", 'while true; do echo "Running..."; sleep 2h; done']
      imagePullPolicy: Always
      securityContext:
        privileged: false
        capabilities:
          add: ["CHOWN"]

apiVersion: v1

kind: Pod

metadata:

spec:

containers:

- image: busybox

command: ["sh", "-c", 'while true; do echo "Running..."; sleep 2h; done']

imagePullPolicy: Always

securityContext:

privileged: false

capabilities:

add: ["CHOWN"]

restricted-pod.yaml – restricting privileged access to the pod

apiVersion: v1
kind: Pod
metadata:
  name: busypod-restricted
spec:
  containers:
    - image: busybox
      name: busybox
      command: ["sh", "-c", 'while true; do echo "Running..."; sleep 2h; done']
      imagePullPolicy: Always
      securityContext:
        runAsUser: 3000
        runAsNonRoot: true
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
        seccompProfile:
          type: "RuntimeDefault"

apiVersion: v1

kind: Pod

metadata:

spec:

containers:

- image: busybox

command: ["sh", "-c", 'while true; do echo "Running..."; sleep 2h; done']

imagePullPolicy: Always

securityContext:

runAsUser: 3000

runAsNonRoot: true

allowPrivilegeEscalation: false

capabilities:

drop: ["ALL"]

seccompProfile:

type: "RuntimeDefault"

Step 4. Create different scenarios for pod security.

In this scenario, we have given enforce mode in the namespace label as mentioned in 2nd step

Execute the below commands none of them should throw an error.

kubectl apply -f privileged-pod.yaml -n staging
kubectl apply -f baseline-pod.yaml -n dev
kubectl apply -f restricted-pod.yaml -n prod

kubectl apply -f privileged-pod.yaml -n staging

kubectl apply -f baseline-pod.yaml -n dev

kubectl apply -f restricted-pod.yaml -n prod

Execute the below command to create a pod in a different namespace.

kubectl apply -f privileged-pod.yaml -n prod

1	kubectl apply -f privileged-pod.yaml -n prod

This command should throw an error because we are trying to execute a privileged access pod in a restricted mode namespace. In this case pod will not create.

kubectl apply -f privileged-pod.yaml -n dev

1	kubectl apply -f privileged-pod.yaml -n dev

This command should throw an error because we are trying to execute a privileged access pod in baseline level namespace, which should not have privileged access in this case pod will not create.

kubectl apply -f baseline-pod.yaml -n prod

1	kubectl apply -f baseline-pod.yaml -n prod

This command should throw an error because we are trying to execute a baseline pod with capabilities in a restricted level namespace which does not allow any capabilities to be added in this case pod will not create.

step4

Make sure to delete the pod by using the command below in each namespace before going to the next scene.

kubectl delete -f <yaml file name> -n <namespace name> –force

In this scenario, we have given a warning mode in the namespace label by executing the commands below.

kubectl edit ns dev //change label: pod-security.kubernetes.io/enforce=baseline as pod-security.kubernetes.io/warn=baseline

1	kubectl edit ns dev //change label: pod-security.kubernetes.io/enforce=baseline as pod-security.kubernetes.io/warn=baseline

step4b

kubectl edit ns prod //change label: pod-security.kubernetes.io/enforce=restricted as pod-security.kubernetes.io/warn=restricted

1	kubectl edit ns prod //change label: pod-security.kubernetes.io/enforce=restricted as pod-security.kubernetes.io/warn=restricted

step4c

kubectl edit ns staging //change label: pod-security.kubernetes.io/enforce=privileged as pod-security.kubernetes.io/warn=privileged

1	kubectl edit ns staging //change label: pod-security.kubernetes.io/enforce=privileged as pod-security.kubernetes.io/warn=privileged

step4d

Execute the below commands none of them should throw an error and warning.

kubectl apply -f privileged-pod.yaml -n staging
kubectl apply -f baseline-pod.yaml -n dev
kubectl apply -f restricted-pod.yaml -n prod

kubectl apply -f privileged-pod.yaml -n staging

kubectl apply -f baseline-pod.yaml -n dev

kubectl apply -f restricted-pod.yaml -n prod

Execute the below command to create a pod in a different namespace.

kubectl apply -f privileged-pod.yaml -n prod

1	kubectl apply -f privileged-pod.yaml -n prod

In this case pod will be created by throwing and warning message of violation of restricted level.

kubectl apply -f privileged-pod.yaml -n dev

1	kubectl apply -f privileged-pod.yaml -n dev

In this case pod will be created by throwing and warning message of violation of baseline level.

kubectl apply -f baseline-pod.yaml -n prod

1	kubectl apply -f baseline-pod.yaml -n prod

In this case pod will be created by throwing and warning message of violation of restricted level.

step4e

Make sure to delete the pod by using the command below in each namespace before going to the next scenario.

kubectl delete -f <yaml file name> -n <namespace name> --force

1	kubectl delete -f <yaml file name> -n <namespace name> --force

In this scenario, we have given Audit mode in the namespace label by executing the commands below.

kubectl edit ns dev

1	kubectl edit ns dev

change label: pod-security.kubernetes.io/enforce=baseline as pod-security.kubernetes.io/audit=baseline

step4f

kubectl edit ns prod

1	kubectl edit ns prod

change label: pod-security.kubernetes.io/enforce=restricted as pod-security.kubernetes.io/audit=restricted

step4g

kubectl edit ns staging

1	kubectl edit ns staging

change label: pod-security.kubernetes.io/enforce=privileged as pod-security.kubernetes.io/audit=privileged

step4h

Step 5. Enabling Auditing.

To enable auditing, you need to perform below steps:

create audit-policy.yaml

1	create audit-policy.yaml

This defines what we need to audit. In this yaml file, we are auditing request, request response, and metadata for the namespace prod.

Below yaml file you need to store at location: /etc/kubernetes/

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    namespaces: ["prod"]
    resources:
      - group: ""
        resources: ["pods/log", "pods/status"]

apiVersion: audit.k8s.io/v1

kind: Policy

rules:

- level: Metadata

namespaces: ["prod"]

resources:

- group: ""

resources: ["pods/log", "pods/status"]

Now, to enable auditing, we need to make some changes in the api-server configuration file. Before making any changes to the original kube-apiserver.yaml, it is best practice to make a copy of the file and then make the changes.

Go to /etc/kubernetes/manifests/kube-apiserver.yaml and add the below flags:

- --audit-policy-file=/etc/kubernetes/audit-policy.yaml
- --audit-log-path=/var/log/test.log
- --audit-log-maxage=30

- --audit-policy-file=/etc/kubernetes/audit-policy.yaml

- --audit-log-path=/var/log/test.log

- --audit-log-maxage=30

Then you need to mount the yaml file to the volume so the API server can read that file. And also, mount the log path where you need to store the test.log file. For storing the log file, you can give the path in the volume mount as shown below:

Add this in the volume mount section.

volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/test.log
    name: audit-log
    readOnly: false

volumeMounts:

- mountPath: /etc/kubernetes/audit-policy.yaml

readOnly: true

- mountPath: /var/log/test.log

readOnly: false

Add this in the volume section.

volumes:
- name: audit
  hostPath:
    path: /etc/kubernetes/audit-policy.yaml
    type: File
- name: audit-log
  hostPath:
    path: /var/log/test.log
    type: FileOrCreate

volumes:

- name: audit

hostPath:

path: /etc/kubernetes/audit-policy.yaml

type: File

- name: audit-log

hostPath:

path: /var/log/test.log

type: FileOrCreate

Execute the below command to create pod in different namespace.

kubectl apply -f privileged-pod.yaml -n prod //In this case pod will be created but the logs will be send to audit.log file which we specified in the kube-apiserve.yaml.
kubectl apply -f baseline-pod.yaml -n prod //In this case pod will be created but the logs will be sent to the audit.log file which we specified in the kube-apiserve.yaml.
Execute command tail –f /var/log/test.log to see the logs. After execution test.log file will create.

Conclusion

Pod security is critical to ensuring the safety and integrity of containerized applications within a Kubernetes cluster. By implementing effective pod security measures, organizations can mitigate potential security risks, protect sensitive data, and maintain the overall stability of their infrastructure.

Get your new hires billable within 1-60 days. Experience our Capability Development Framework today.

Cloud Training
Customized Training
Experiential Learning

About CloudThat

CloudThat is an official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner and Microsoft Gold Partner, helping people develop knowledge of the cloud and help their businesses aim for higher goals using best-in-industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.

Drop a query if you have any questions regarding Pod Security, I will get back to you quickly.

To get started, go through our Consultancy page and Managed Services Package, CloudThat’s offerings.

FAQs

1. What is meant by pod security?

ANS: – Pod Security Policies (PSPs) are admission controllers in Kubernetes that provide authorization policies for creating and updating pods, allowing fine-grained control over security-sensitive aspects of pod specifications. They operate at the cluster level and enforce security policies for users and service accounts.

2. Why is pod security important in Kubernetes?

ANS: – Pod security is important in Kubernetes to ensure containerized applications’ isolation, integrity, and confidentiality. Organizations can protect sensitive data, prevent unauthorized access, and mitigate potential security risks by implementing pod security measures.