Securing Pods with Pod Security Policies

Tutorial 3 of 5

Introduction

This tutorial aims to familiarize you with the process of securing pods in Kubernetes using Pod Security Policies (PSPs). Pod Security Policies are cluster-level resources that control the security-sensitive aspects of the pod specification and provide an extra layer of security.

By the end of this tutorial, you will learn how to create and implement Pod Security Policies to ensure that your pods follow the required security practices.

Prerequisites

  • Basic knowledge of Kubernetes and its components
  • A Kubernetes cluster up and running
  • Familiarity with Kubernetes command-line tool, kubectl

Step-by-Step Guide

Pod Security Policies are implemented as Kubernetes Admission Controllers. The Admission Controller intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.

Here's how to get started with Pod Security Policies:

  1. Enable the PodSecurityPolicy controller: To make use of Pod Security Policies, you must have the PodSecurityPolicy admission controller enabled.

  2. Create PodSecurityPolicy: Define the conditions that a pod must run with in order to be accepted into the system.

  3. Authorize Users or ServiceAccounts to use the PodSecurityPolicy: A Pod Security Policy is a cluster-level resource. Once created, it does nothing unless it is associated with a role and role binding.

Code Examples

Let's create a simple Pod Security Policy:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false  # Don't allow privileged pods!
  # The rest fills in some required fields.
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  runAsUser:
    rule: MustRunAsNonRoot
  fsGroup:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535

In this example:
- privileged: false disallows privileged pods.
- rule: RunAsAny for seLinux allows any seLinux context to be specified.
- rule: MustRunAs for supplementalGroups and fsGroup requires that the group ID for the pod be within the specified range.
- rule: MustRunAsNonRoot for runAsUser requires that the pod be run as a non-root user.

Summary

In this tutorial, we learned about Pod Security Policies, their components, and how to implement them in Kubernetes. The next step would be to familiarize yourself with different options in Pod Security Policies and try to create more complex policies as per your requirements.

Practice Exercises

  1. Create a Pod Security Policy that only allows pods to use the NET_RAW capability.
  2. Create a Pod Security Policy that disallows the use of host namespaces.

Solutions

  1. To create a PSP that only allows pods to use the NET_RAW capability, you would need to specify it under the allowedCapabilities:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: net-raw
spec:
  allowedCapabilities:
  - NET_RAW
  1. To disallow the use of host namespaces, you would need to set hostPID, hostIPC, hostNetwork to false:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: no-host-namespace
spec:
  hostPID: false
  hostIPC: false
  hostNetwork: false

Remember to apply these policies using kubectl apply -f <filename.yaml>. Continue exploring more about Kubernetes Pod Security Policies to enhance your understanding and expertise.