# Safe K8s Deployment with Pod Security Admission

## Introduction

[Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) is the predecessor of the [Pod Security Policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/) and has been introduced as Alpha feature in Kubernetes version 1.22. Starting with Kubernetes version 1.25 [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) is regarded stable and [Pod Security Policies](https://kubernetes.io/docs/concepts/security/pod-security-policy) have been removed. Please check this [blog post on kuberneetes.io](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) and the alpha documentation for [pod security admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) in Kubernetes version 1.22 for details.

Pod Security Admission is a Kubernetes admission controller that lets you apply Pod Security Standards toPods running on your cluster. Pod Security Standards are predefined security policies. These policies range from being highly permissive to highly restrictive.

You can apply one of these Pod Security Standards:

* **Privileged**: An unrestricted policy that provides the widest level of permissions. Allows for known privilege escalations.
* **Baseline**: A minimally restrictive policy that allows the default, minimally specified Pod configuration. Prevents known privilege escalations.
* **Restricted**: A highly restrictive policy that follows Pod hardening best practices.

You can use the PodSecurity admission controller to apply Pod Security Standards in the following modes:

* **Enforce**: Policy violations reject Pod creation. An audit event is added to the audit log.
* **Audit**: Policy violations trigger adding an audit event to the audit log. Pod creation is allowed.
* **Warn**: Policy violations trigger a user-facing warning. Pod creation is allowed.

To use the Pod Security admission controller, you must apply specific Pod Security Standards in specific modes to specific namespaces. You can do this by using namespace labels.

## Lab

In this lab, you will do the following:

* Create two new namespaces
* Apply specific security policies to each namespace
* Test the configured policies by using different deployments

For details on the demo application see [hello spring boot application](/secure-kubernetes-development/application-security/step1-hello-spring-boot.md).

### Prepare the namespaces

Create the following namespaces using this commands:

```bash
kubectl create ns privileged
kubectl create ns baseline
kubectl create ns restricted
```

Now apply the following Pod Security Standards:

* **baseline**: Apply `baseline` standard to `baseline` namespace in the `warn` mode
* **restricted**: Apply `restricted` standard to `restricted` namespace in the `enforce` mode

```bash
kubectl label --overwrite ns baseline pod-security.kubernetes.io/warn=baseline
kubectl label --overwrite ns restricted pod-security.kubernetes.io/enforce=restricted
```

These commands achieve the following result:

* Workloads in the `privileged` namespace can be deployed without any restrictions (even in privileged mode).
* Workloads in the `baseline` namespace that violate the `baseline` policy are reject, and the client displays a warning message.
* Workloads in the `restricted` namespace that violate the `restricted` policy are rejected, and the cluster adds a corresponding entry to the audit logs.

Verify that the labels were added:

```bash
kubectl get ns --show-labels
```

The output should be similar to the following (other existing namespaces are omitted here):

```bash
baseline       Active   74s   kubernetes.io/metadata.name=baseline-ns,pod-security.kubernetes.io/warn=baseline
restricted     Active   18s   kubernetes.io/metadata.name=restricted-ns,pod-security.kubernetes.io/enforce=restricted
```

### Testing the configured policies

To test the policy enforcement we now try to deploy a privileged pod/container into the privileged, baseline or restricted namespaces and see what happens.

Then we will deploy a non-privileged pod/container into the baseline or restricted namespaces to see if this will run there.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://andifalk.gitbook.io/secure-kubernetes-development/kubernetes-security/step8-pod-security-admission.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.