Pod Security Standards

Feature state: stable

Pod Security Standards

Kubernetes has a special feature called the Pod Security Admission (PSA) controller. This admission controller is responsible for enforcing the Pod Security Standard policies. This means it will check any new pod against a set of security policies and either allow or deny the configuration.

The PSA controller responds to potential security standard violations in one of three ways, determined by the chosen mode:

  • Enforce Mode: If a policy violation occurs, the pod will be outright rejected. This mode ensures strict adherence to the defined security standards.
  • Audit Mode: In this mode, while policy violations are allowed, they are recorded as audit annotations in the Kubernetes audit log. This approach is useful for monitoring and understanding non-compliance issues without hindering pod deployment.
  • Warn Mode: This mode provides a middle ground. Policy violations result in user-facing warnings, but the pods are still permitted to deploy. This approach can be valuable for awareness and gradual enforcement without immediate disruption.

Profiles

Avisi Cloud provides a default set of profiles that allow you to configure the default behaviour of your Kubernetes Cluster when creating new workloads or pods. These are restricted, baseline and privileged. The profiles are explained below.

You can select the profile within the Console during cluster create, or update it for any existing cluster.

Rectangle
Selecting a profile in the Console

It is recommended to switch this setting to restricted for all clusters, and use namespace labels for configuring less restrictive policies for workloads on a case-by-case basis.

Pod Security Standards Explained

Kubernetes Pod Security Standards (PSS) are a set of predefined security policies for Kubernetes pods, providing a framework to ensure secure and compliant pod configurations in a Kubernetes environment. The standards ensure that the containerised workloads are secure against known privilege escalations and adhere to current best practices for Pod hardening. Pod security restrictions are applied at namespace level.

Pod Security Standards in Kubernetes are classified into three levels:

Baseline

This level is aimed at minimising the risk of security vulnerabilities while ensuring minimal disruption to existing applications. It’s designed for general-purpose use and is suitable for most workloads.

See pod-security-standards/#baseline for controls that the Baseline profile enforce/disallow.

Restricted

This level provides a significantly higher security posture and is recommended for sensitive workloads. It imposes stricter controls and limitations, ensuring pods have the least privilege necessary to function correctly. This level is good practice to target at operators and developers of security-critical applications, as well as lower-trust users.

See pod-security-standards/#restricted for controls that the Restricted profile enforce/disallow.

Privileged

This level is essentially unrestricted and is not recommended for most workloads. It is intended for system— infrastructure-level workloads done by privileged users. The Privileged policy disables all restrictions.

Configuring namespaces

Configuring a namespace to use certain standards can be done by using labels. The supported labels by built-in Pod Security Admission makes it possible to configure one or more pod security standard checks on a namespace. The following example command will enforce ,in the ‘example’ namespace ,the latest version of baseline Pod Security Standard, but warn for the latest restricted Pod Security Standards.

kubectl label namespace example \
 pod-security.kubernetes.io/enforce=baseline \
 pod-security.kubernetes.io/enforce-version=latest \
 pod-security.kubernetes.io/warn=restricted \
 pod-security.kubernetes.io/warn-version=latest

Expected Behaviour for Non-Compliant Pod Deployments

Scenario 1: Baseline Security Standards Violation

When attempting to deploy a pod with specifications that breach the enforced baseline Pod Security Standards, the deployment will fail. Below is an example of a pod definition that would trigger such a failure due to the use of host ports, which are restricted under baseline standards:

apiVersion: v1
kind: Pod
metadata:
  name: non-compliant-pod
  namespace: example
spec:
  containers:
  - name: non-compliant-container
    image: nginx
    ports:
    - containerPort: 80
      hostPort: 8080

Deploying the above configuration will result an error message, see below, indicating the specific restrictions that have been violated.

The Pod "non-compliant-pod" is invalid: spec: Forbidden: pod updates may not change fields other than `spec.containers[*].image`,`spec.initContainers[*].image`,`spec.activeDeadlineSeconds`,`spec.tolerations` (only additions to existing tolerations),`spec.terminationGracePeriodSeconds` (allow it to be set to 1 if it was previously negative)
  core.PodSpec{
  	Volumes:        {{Name: "kube-api-access-phh2c", VolumeSource: {Projected: &{Sources: {{ServiceAccountToken: &{ExpirationSeconds: 3607, Path: "token"}}, {ConfigMap: &{LocalObjectReference: {Name: "kube-root-ca.crt"}, Items: {{Key: "ca.crt", Path: "ca.crt"}}}}, {DownwardAPI: &{Items: {{Path: "namespace", FieldRef: &{APIVersion: "v1", FieldPath: "metadata.namespace"}}}}}}, DefaultMode: &420}}}},
  	InitContainers: nil,
  	Containers: []core.Container{
  		{
  			... // 3 identical fields
  			Args:       nil,
  			WorkingDir: "",
- 			Ports:      nil,
+ 			Ports:      []core.ContainerPort{{HostPort: 8080, ContainerPort: 80, Protocol: "TCP"}},
  			EnvFrom:    nil,
  			Env:        nil,
  			... // 10 identical fields
  			TerminationMessagePolicy: "File",
  			ImagePullPolicy:          "Always",
- 			SecurityContext:          &core.SecurityContext{RunAsUser: &0},
+ 			SecurityContext:          nil,
  			Stdin:                    false,
  			StdinOnce:                false,
  			TTY:                      false,
  		},
  	},
  	EphemeralContainers: nil,
  	RestartPolicy:       "Always",
  	... // 28 identical fields
  }

Scenario 2: Restricted Security Standards Warning

For a namespace where the ‘restricted’ Pod Security Standards are enforced, the following pod deployment will issue a warning:

apiVersion: v1
kind: Pod
metadata:
 name: non-compliant-pod
 namespace: example
spec:
 containers:
 - name: non-compliant-container
  image: nginx
  securityContext:
   runAsUser: 0

This configuration attempts to run the container as the root user (runAsUser: 0). As a result, the following warning will be generated, but the pod may still be created.

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "non-compliant-container" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "non-compliant-container" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "non-compliant-container" must set securityContext.runAsNonRoot=true), runAsUser=0 (container "non-compliant-container" must not set runAsUser=0), seccompProfile (pod or container "non-compliant-container" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/non-compliant-pod created

The warning outlines the violations and suggests the required security context changes to comply with the ‘restricted’ standards.

← Kubernetes Persistent Storage
Kubernetes Cluster Node Pool →