# Microservice Vulnerabilities: Pod Security Standards

> Chapter 13 of the Courseiva CNCF-CKS curriculum — https://courseiva.com/learn/cncf-cks/microservice-vulnerabilities-pod-security

**Official objective:** 5.1 — Implement Pod Security Standards (Baseline, Restricted)

## Introduction

The CKS exam domain of Pod Security Standards is your first line of defence against container breakouts and privilege escalation attacks. This chapter solves the critical problem of how to enforce security policies on every workload running in your Kubernetes cluster without having to manually check each one. Mastering this concept is essential because the exam will test your ability to configure and apply these policies at the namespace or cluster level using a straightforward admission controller.

## The Sealed Apartment Building Analogy

A locked apartment building is only as safe as its weakest unit. The building has a main entrance with a keycard for all tenants. The superintendent decides that every unit must meet two security levels: 'Baseline' and 'Restricted'. The Baseline rule says every apartment must have a deadbolt lock on the front door and a peephole. No unit can have the door propped open with a chair. The Restricted rule goes further: no unit can have windows that open more than a crack, all packages must go through a secure delivery box, and guests must be escorted by the tenant at all times.

When new tenants move in, the superintendent checks their apartment against these rules. If a tenant wants to add a cat flap (which would break the deadbolt rule under Baseline), the superintendent says no. The superintendent doesn't care about the colour of the walls or the tenant's name—those are irrelevant. The rules focus only on how the door, windows, and deliveries are handled. This is exactly how Pod Security Standards work in Kubernetes. The building is the cluster. The apartments are the pods. The superintendent is the Pod Security Admission controller. Baseline and Restricted are the two standards that enforce security policies on how pods are allowed to run. The rules prevent dangerous configurations, such as running a pod with privileged access to the host system (like leaving the apartment door wide open for intruders).

## Core explanation

Pod Security Standards (PSS) are a set of predefined security policies for Kubernetes pods. A pod is the smallest deployable unit in Kubernetes—it is like a wrapper around one or more containers that run your application. Before PSS existed, cluster administrators had to either trust developers to set secure security contexts manually or resort to complex, third-party admission controllers. This was error-prone and inconsistent.

The Kubernetes project created three Pod Security Standards: Privileged, Baseline, and Restricted. The exam focuses on Baseline and Restricted exclusively, because those are the ones you implement for secure microservice deployments. Privileged is intentionally unrestricted and is only used for system-level pods (like network plugins or storage drivers).

The Baseline standard is the minimal security posture. It prevents the most obvious and dangerous escapes. It blocks pods from running as the root user inside the container by default. It forbids the use of host namespaces (which would give the container direct access to the host's network or process list). It also prohibits the use of hostPath volumes that could allow a container to write to the host's filesystem. Baseline does not stop all attacks, but it closes the easy doors.

The Restricted standard is far stricter. It is designed for running non-privileged, untrusted workloads. Restricted requires that the container's root filesystem is read-only (the container cannot write to its own disk). It forces the container to run with a non-root user (UID not zero). It also forbids adding Linux capabilities beyond a very small allowed set, such as NET_BIND_SERVICE. Restricted also requires the use of seccomp profiles (a security feature that limits the system calls a container can make to the Linux kernel). The idea is to reduce the attack surface to almost zero.

These policies are enabled through the Pod Security Admission (PSA) controller. An admission controller is a piece of code that intercepts requests to the Kubernetes API server before the object is created or updated. The PSA controller checks each pod against the defined standard. You configure it at the namespace level using labels. For example, you can label a namespace with:
- 'pod-security.kubernetes.io/enforce: baseline' – blocks any pod that violates Baseline.
- 'pod-security.kubernetes.io/audit: restricted' – logs violations of Restricted without blocking them.
- 'pod-security.kubernetes.io/warn: restricted' – shows a warning to the user if the pod violates Restricted, but still allows creation.

The PSA controller provides three modes: enforce (block), audit (log), and warn (warn). This gives you flexibility to roll out policies gradually. You can audit namespaces first to see what violations exist, then switch to enforce once the teams have fixed their pods.

Why does this matter? Because in a microservice architecture, you might have hundreds of pods. You cannot manually check each one for security misconfigurations. PSS gives you declarative policy as code. You write the label once, and the system automatically enforces it for every new pod and every update to existing pods. This completely replaces the old approach of relying on developers to remember to set 'securityContext.runAsNonRoot: true' on every pod manifest.

For the CKS exam, you must memorise the exact label syntax and the three modes. You also need to know the key differences between Baseline and Restricted. Baseline blocks hostNetwork, hostPID, hostIPC, and privileged containers. Restricted additionally blocks: running as root, writable root filesystem, adding most Linux capabilities, and requires a seccomp profile. The exam loves to test which policy prevents a specific dangerous behaviour, such as: 'A developer wants to run a container with SYS_ADMIN capability. Which standard would block this?' The answer is Restricted, because Baseline allows most capabilities except the most dangerous ones like NET_RAW and SYS_ADMIN are not explicitly blocked in Baseline—actually, Baseline blocks only a small set of capabilities (like NET_RAW, SYS_ADMIN is also blocked by Baseline? I need to clarify: Baseline blocks a limited set of capabilities, specifically: CAP_NET_RAW, CAP_SYS_ADMIN, and a few others. Restricted blocks all capabilities except the allowed list. So if a pod requests any capability outside the allowed set, Restricted blocks it. The exam tests this nuance.

Important terms to understand:
- securityContext: a field in the pod specification that sets user IDs, group IDs, Linux capabilities, and other security options for the container.
- Linux capabilities: a way to break down the privileges that the root user usually has into smaller pieces. For example, CAP_NET_BIND_SERVICE allows binding to a port below 1024 without being root.
- seccomp: a Linux kernel feature that restricts which system calls a process can make. In Kubernetes, you can set seccomp profiles at the pod level.
- hostPath volume: a volume that mounts a directory from the host node's filesystem into the container. This is dangerous because the container could read or write sensitive host files.

To apply these standards in practice, you add labels to your namespace definition. Here is a complete example:

apiVersion: v1
kind: Namespace
metadata:
  name: production-critical
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/warn: baseline

This example enforces Restricted strictly, but audits and warns for Baseline violations. The 'enforce-version' label pins the policy to a specific version of Kubernetes to avoid breaking changes.

The CKS exam expects you to recognise that Pod Security Standards replace the old PodSecurityPolicy (PSP) which was deprecated in Kubernetes v1.21 and removed in v1.25. If you see PSP in an exam question, the answer is that it is no longer available and PSS is the replacement. Do not get trapped into selecting PSP-related answers.

One more critical detail: Pod Security Standards only apply to pods, not to other Kubernetes objects like Deployments or Jobs. The admission controller evaluates pod templates inside those objects. If a Deployment has a pod template that violates the standard, the PSA controller will reject the entire Deployment creation. This is a common source of confusion for beginners: you label the namespace, not the Deployment. The policy applies to the pod specs inside the higher-level controllers.

Finally, note that PSS does not cover network security (that is NetworkPolicies) or secret management (that is RBAC and Secrets). It is narrowly focused on the runtime security of the container itself. The exam may combine PSS with other topics like security context settings or service accounts, but PSS is always about the pod's host-level and container-level privileges.

## Real-world context

A real-world IT professional uses Pod Security Standards when onboarding a new application team into a shared Kubernetes cluster. Imagine a finance company that runs a cluster hosting applications from multiple departments. The security team wants to ensure that no pod can escalate privileges and break out to the host node.

Step one: The platform engineer creates a new namespace called 'team-payments' for the payments team. They label the namespace with:
- pod-security.kubernetes.io/enforce: restricted
- pod-security.kubernetes.io/warn: baseline
- pod-security.kubernetes.io/audit: baseline

Step two: The payments team deploys their application using a Deployment. Their deployment manifest sets the container to run as root because the old documentation said to do that. When they try to create the Deployment using 'kubectl apply -f deployment.yaml', the API server rejects it immediately. The error message says 'pods 'payments-app-xxx' is forbidden: violates PodSecurity 'restricted:latest': non-root groups (container must not set securityContext.runAsUser=0)'. The deployment never gets created.

Step three: The platform engineer sees the rejection and explains the policy to the team. They guide the team to change their Docker image to run as a non-root user, and to set 'securityContext.runAsNonRoot: true' in their pod spec. They also need to make the container root filesystem read-only by setting 'securityContext.readOnlyRootFilesystem: true' and add a seccomp profile reference.

Step four: Once the team updates their manifest, they reapply it. This time, the PSA controller passes the pod through and the Deployment is created successfully. The pods run with no privilege elevation risk.

Step five: The security team checks the audit logs from the 'audit' mode. They see that the original pod attempt was logged with a violation of the Baseline standard (since it would have also violated Baseline by running as root). They use this data to report to management on how many teams needed to fix their configurations.

What tools does the platform engineer use?
- kubectl label namespace team-payments pod-security.kubernetes.io/enforce=restricted – to apply the label.
- kubectl describe namespace team-payments – to verify the labels are present.
- kubectl get events – to see the rejection events and exact violation messages.
- kubectl apply -f team-deployment.yaml – to attempt the deployment and see the error.
- kubectl run test-pod --image=nginx – to quickly test if a simple pod violates the policy.

The professional also uses 'kubectl auth can-i' to check if the service account of the team has permissions to create pods in that namespace, but that is separate from PSS.

The key actions an IT professional performs are:
- Identify the namespace's security posture based on team trust level.
- Apply the correct labels (enforce, audit, warn) appropriate for that posture.
- Communicate the violation errors to developers in non-technical terms.
- Maintain a CI/CD pipeline that runs 'kubectl apply --dry-run=server' to test manifest compliance before actual deployment.
- Regularly review audit logs to detect configuration drift or new vulnerabilities.
- Update the 'enforce-version' label when upgrading the Kubernetes cluster to maintain policy compatibility.

## Exam focus

The CKS exam heavily tests Pod Security Standards and it is a core part of Domain 5 (Supply Chain Security) though it is often cited under runtime security. Expect at least 3-5 questions on this topic. The exam is performance-based, meaning you will be given a cluster (via SSH to a control plane node) and you must configure PSS on existing namespaces, or fix a broken configuration.

Typical question types:
- Configure a namespace to enforce the Restricted standard. You must write the correct label command.
- Given a namespace that has an 'enforce' label, you need to create a pod that passes the policy. You must set the correct securityContext fields.
- A pod is failing to run because of a PSS violation. You must inspect the pod events, identify the violation, and fix the pod spec.
- Compare and contrast Baseline and Restricted for a specific scenario, such as: 'Which standard blocks the use of hostPID?' The answer is both Baseline and Restricted. 'Which standard requires a seccomp profile?' Only Restricted.
- You are asked to identify which component enforces PSS. The answer is the Pod Security Admission controller, not the old PodSecurityPolicy.

Traps the exam sets:
- They will show you a pod with 'privileged: true' and ask you to identify which standard blocks it. Both Baseline and Restricted block privilege escalation, but Baseline explicitly blocks privileged containers. Restricted also blocks them. So either answer could be correct depending on the question wording. Read carefully: if they ask 'Which standard is the most restrictive that would block this?' answer Restricted. If they ask 'Which standard would block this?', Baseline also blocks it, so both work—but normally the question expects the minimal one that blocks it, which is Baseline. If the pod also has 'runAsUser: 0', Baseline blocks it too? Actually, Baseline does not block running as root; it only blocks running as root if combined with privileged? No, Baseline does not block runAsUser=0 by itself. So if a pod is privileged and runs as root, Baseline blocks it because of the privileged flag. If a pod is not privileged but runs as root, Baseline allows it, but Restricted blocks it. The exam will give you a pod spec and ask you to pick the policy that blocks it. You must check each field.
- They will ask you to enable PSS with 'audit' mode. You must remember the label key is 'pod-security.kubernetes.io/audit', not 'audit-mode' or 'audit'. 
- They will ask you to update a namespace that already has an enforce label to a different version (e.g., from 'v1.24' to 'latest'). You must write the correct command to overwrite the label.
- They will ask: 'A team wants to run a pod that needs to write logs to a directory on the host. What is the correct approach?' The answer is not to use hostPath, because that violates Baseline. Instead, use a PVC or a hostPath with readOnly=true if the pod only needs to read. But if it needs to write, you must use a different volume type, or relax the policy to Privileged (which is almost never the answer for a team that does not manage system components).

Concepts you must memorise:
- The exact label format: pod-security.kubernetes.io/<mode>: <standard>
- The three modes: enforce, audit, warn.
- The three standards: Privileged, Baseline, Restricted.
- Baseline blocks: privileged containers, host namespaces (hostPID, hostIPC, hostNetwork), hostPath volumes (with some exceptions), AppArmor (if not default), SELinux (if not default), certain capabilities (CAP_NET_RAW, CAP_SYS_ADMIN).
- Restricted blocks everything Baseline blocks, plus: runAsUser=0, readOnlyRootFilesystem=true (requires it), adds a seccomp profile requirement, and restricts capabilities to a minimal allowed set (specifically: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_SETGID, CAP_SETUID, CAP_SETPCAP, CAP_NET_BIND_SERVICE, CAP_NET_RAW (wait, no, CAP_NET_RAW is not in allowed set for Restricted? Actually, the allowed capability list for Restricted is defined in the Kubernetes documentation: it is a short list. You must know that CAP_NET_RAW is NOT allowed in Restricted, but Baseline blocks it anyway. So any host of capabilities beyond the allowed list is blocked. CAP_NET_RAW is explicitly forbidden by both.).
- The term 'user namespace' and how it relates to PSS: user namespace remapping is a way to run rootless containers, but PSS still applies at the pod level regardless.

Sample exam question pattern:
'You are tasked with ensuring that all pods in namespace 'secure-app' run without privilege escalation. The pods must be able to read host files. Which standard do you enforce, and what volume type do you allow?'
Answer: Enforce Baseline. Use a ConfigMap or secret for reading files, or a PVC. Do not use hostPath because that is blocked by Baseline. If they need hostPath, they must use a different namespace with a more permissive policy.

Another trap: 'A pod runs as user 1000 but has 'allowPrivilegeEscalation: true'. Which standard blocks this?' Both Baseline and Restricted block allowPrivilegeEscalation. So the correct answer is both, but the exam might ask 'which standard blocks this and why?' They want you to say Baseline, because it is the minimal standard that blocks it.

Finally, the exam will test that you know PSS is cluster-scoped policy that works with the AdmissionRegistration API. You may need to check the PodSecurity configuration in the kube-apiserver arguments (e.g., --admission-control-config-file). But most exam tasks are focused on label-based configuration at namespace level.

## Step by step

1. **Identify the namespace to protect** — First, decide which namespace needs the policy. For example, a namespace for a critical microservice called 'payments'. You should choose the appropriate standard based on the trust level of the workloads that will run there. This step determines whether you will enforce Baseline or Restricted.
2. **Label the namespace with the desired policy** — Apply the label to the namespace using kubectl. For enforce mode, use: 'kubectl label namespace payments pod-security.kubernetes.io/enforce=restricted'. You can also add audit and warn labels simultaneously. This is where the configuration starts to take effect.
3. **Attempt to deploy a pod into the namespace** — Write a pod manifest and try to create it with 'kubectl apply -f pod.yaml'. If the pod violates the policy, the API server will return an error immediately. The pod is not stored in etcd. This step demonstrates the admission control in action.
4. **Read the violation error message** — The error message tells you exactly which field violated which policy. For example: 'pods 'test-pod' is forbidden: violates PodSecurity 'restricted:latest': non-root groups (container must not set securityContext.runAsUser=0)'. This message guides you on what to fix in the pod spec.
5. **Modify the pod spec to comply** — Based on the error, update the pod spec. For Restricted, you would set 'runAsNonRoot: true', 'runAsUser: 1000', 'readOnlyRootFilesystem: true', and add a seccomp profile reference. Then reapply the manifest. If the fix is correct, the pod will be created successfully.

## Comparisons

### Baseline Standard vs Restricted Standard

**Baseline Standard:**
- Blocks privileged containers, host namespaces, and hostPath volumes.
- Allows running as root (UID 0) inside the container.
- Does not require a seccomp profile or read-only root filesystem.

**Restricted Standard:**
- Blocks everything Baseline blocks, plus running as root.
- Requires read-only root filesystem for the container.
- Requires a seccomp profile to be applied (default or custom).

### Enforce Mode vs Audit Mode

**Enforce Mode:**
- Actively blocks creation of any pod that violates the policy.
- The pod never gets stored in etcd; user sees an error.
- Used after you have fixed all violating workloads.

**Audit Mode:**
- Does not block creation; logs violations to the audit log.
- The pod is created and runs despite the violation.
- Used for initial discovery and monitoring of existing workloads.

### Pod Security Standards (PSS) vs PodSecurityPolicy (PSP)

**Pod Security Standards (PSS):**
- Implemented as labels on namespaces; no separate API object.
- Much simpler with only three profiles and three modes.
- Available from Kubernetes v1.23 onwards; supported in current versions.

**PodSecurityPolicy (PSP):**
- Implemented as a Cluster-level API object with complex RBAC and mutation.
- Very complex with 30+ fields and multiple controllers.
- Deprecated in v1.21 and completely removed since v1.25.

### Pod Security Standards vs SecurityContext on Pod

**Pod Security Standards:**
- A policy gate that evaluates the entire pod against rules.
- Applied at the namespace level, not on individual pods.
- Does not modify the pod; only admits or rejects based on pre-defined rules.

**SecurityContext on Pod:**
- A configuration field on each pod or container that sets runtime options.
- Applied to the pod manifest directly by the developer.
- Can be overridden by admission controllers, but is the source of truth for runtime behaviour.

## Diagram

_Flowchart showing how the Pod Security Admission controller evaluates a pod against namespace labels and either allows or rejects the pod creation._

```mermaid
flowchart TD
    A[User kubectl apply] --> B[API Server]
    B --> C{Pod Security Admission Controller}
    C -->|Check namespace labels| D{What standard?}
    D -->|Baseline| E[Evaluate pod against Baseline rules]
    D -->|Restricted| F[Evaluate pod against Restricted rules]
    D -->|No label| G[Allow all pods]
    E -->|Violation?| H[Reject pod with error]
    E -->|Compliant| I[Allow pod creation]
    F -->|Violation?| J[Reject pod with error]
    F -->|Compliant| K[Allow pod creation]
    I --> L[Pod scheduled to node]
    K --> L
```

## Common misconceptions

- **Misconception:** I can apply Pod Security Standards directly to a pod or deployment using a label on that object. **Reality:** Pod Security Standards are applied to namespaces via labels, not to individual pods or higher-level controllers like Deployments. The admission controller checks the pod template inside the Deployment, but the label goes on the namespace. (Beginners mistakenly think because they see 'pod-security' in the name that it is a field on the pod itself. The label syntax is namespace-based, which is counterintuitive for someone used to annotating individual resources.)
- **Misconception:** If I set enforce: baseline, all pods in the namespace must comply with baseline. If a pod does not comply, it is rejected when it tries to run, not when it is created. **Reality:** The pod is rejected at creation time by the admission controller. The API server evaluates the pod spec against the policy before the object is persisted in etcd. The pod never gets created, so it never runs. The rejection happens during 'kubectl apply' or 'kubectl create'. (Beginners think of security policies as runtime checks (like a firewall that blocks traffic at runtime). But PSS is an admission-time gate. This confusion comes from not understanding the Kubernetes admission control flow.)
- **Misconception:** Baseline and Restricted are the only two standards; Privileged is not a real standard. **Reality:** Privileged is a real standard, but it is the least restrictive. It allows everything, including privileged containers and host namespaces. The CKS exam focuses on Baseline and Restricted, but Privileged exists for system components like kube-proxy or networking daemons. (Because the exam materials emphasise Baseline and Restricted, learners often forget Privileged exists and think it is just 'no policy'. It is actually a defined profile with its own label value.)
- **Misconception:** The audit mode in PSS works just like enforce, but it is weaker; it only blocks some violations. **Reality:** Audit mode does not block any pods. It only logs violations to the audit log for review. Warn mode shows a warning to the user but still creates the pod. Enforce mode is the only one that blocks. This is a critical distinction because beginners mix up the three modes. (The word 'audit' sounds like a security audit that would block things, but in Kubernetes it is purely observational. This misuse of terminology is confusing.)
- **Misconception:** Pod Security Standards are the same as PodSecurityPolicy (PSP), just renamed. **Reality:** PSS completely replaces PSP. PSP was a different API object with a complex system of admission and mutation. PSS is a much simpler label-based approach. PSP is deprecated and removed since Kubernetes v1.25. Any exam question about PSP should be answered with 'use PSS instead'. (Both names start with 'Pod Security', which leads beginners to assume they are the same thing under a new name. The implementation is entirely different.)
- **Misconception:** If I set enforce: restricted, my pod must also have a matching seccomp profile defined in the pod spec. **Reality:** You do not need to explicitly set a seccomp profile in the pod spec if the runtime defaults is used. The Restricted standard requires that a seccomp profile is applied, but it accepts the default profile if one is configured at the cluster level. You only need to set it in the pod spec if your cluster does not have a default. (Beginners read 'requires seccomp profile' and think they must manually add 'seccomp.security.alpha.kubernetes.io/pod' annotations. If the cluster already defaults to a profile, it is satisfied without manual intervention.)

## Key takeaways

- Pod Security Standards are enforced via namespace labels, not pod labels or annotations.
- The three profiles are Privileged, Baseline, and Restricted, with Baseline being the minimum security and Restricted being the strictest.
- The three modes are enforce (block), audit (log only), and warn (show warning but allow), and you must use the exact label syntax pod-security.kubernetes.io/<mode>.
- Baseline blocks privileged containers, host namespaces, hostPath volumes (with exceptions), and a few dangerous Linux capabilities.
- Restricted additionally blocks running as root, requires a read-only root filesystem, and mandates a seccomp profile.
- If a pod template inside a Deployment violates the policy, the entire Deployment creation is rejected by the admission controller.
- Pod Security Standards replaced the deprecated PodSecurityPolicy (PSP) and are the only supported way to enforce pod-level security policies in modern Kubernetes.

## FAQ

**How do I apply Pod Security Standards to an existing namespace without breaking running pods?**

Use the audit or warn mode first. Label the namespace with 'pod-security.kubernetes.io/audit: restricted' to see which pods would violate without blocking them. Then update the pods to comply before switching to enforce mode.

**What is the difference between Pod Security Standards and securityContext on a pod?**

securityContext is a per-pod or per-container field that sets runtime security features like user ID and capabilities. Pod Security Standards are policy gates that require or forbid certain securityContext values. You must set securityContext correctly to pass the policy.

**Can I use Pod Security Standards with a service account that has cluster-admin?**

Yes. The policy applies to the pod spec regardless of who creates it. Even a cluster-admin cannot bypass the admission controller unless they modify the namespace labels or the admission configuration itself.

**Does Pod Security Standards apply to pods created by a Deployment or a Job?**

Yes. The policy evaluates the pod template inside the Deployment or Job. If the template violates the standard, the entire higher-level resource creation is rejected. The pod spec inside the controller must comply.

**What happens if I label a namespace with two different enforce policies?**

You cannot have two enforce labels of different standards on the same namespace. The admission controller uses the most restrictive one that is present, but this is not a supported configuration. Only one enforce label per namespace is expected. If you have both, the behaviour is undefined, so avoid it.

**How do I remove a Pod Security Standard from a namespace?**

Use 'kubectl label namespace <name> pod-security.kubernetes.io/enforce-'. The trailing dash removes the label. You can do the same for audit and warn labels. After removal, no policy is enforced.

## Check your understanding

1. **What are the three modes available for Pod Security Standards?**

   Answer: The three modes are enforce (blocks violating pods), audit (logs violations but allows creation), and warn (shows a warning to the user but allows creation).

2. **If a namespace has the label 'pod-security.kubernetes.io/enforce: baseline', will a pod with 'privileged: true' be allowed?**

   Answer: No, a privileged container is blocked by the Baseline standard. The pod will be rejected at creation time.

3. **Which standard requires the container's root filesystem to be read-only?**

   Answer: The Restricted standard requires 'readOnlyRootFilesystem: true' in the securityContext of the container.

4. **You need to monitor violations without blocking any pods. Which mode should you use?**

   Answer: Use audit mode. It logs violations to the audit log but does not block the pod creation.

5. **True or false: Pod Security Standards are applied by the kubelet on each node after the pod is scheduled.**

   Answer: False. Pod Security Standards are enforced by the Pod Security Admission controller on the API server at admission time, before the pod is scheduled to any node.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/cncf-cks/microservice-vulnerabilities-pod-security