Skill

Create Secure Kubernetes Pod Configurations

A skill for hardening Kubernetes pod security - PSS enforcement levels, security contexts, PSP-to-PSS migration, CIS alignment.

Works with kubernetesgithubopa gatekeeper

Maintainer of this project? Claim this page to edit the listing.


79
Spark score
out of 100
Updated 7 months ago
Version 1.0.0
Models

Add to Favorites

Why it matters

Automate the creation and enforcement of secure Kubernetes Pod Security Policies and Standards. Ensure compliance with best practices and security benchmarks to protect your containerized workloads.

Outcomes

What it gets done

01

Generate Pod Security Policy (PSP) and Pod Security Standards (PSS) configurations.

02

Implement namespace-level and cluster-level security enforcement.

03

Provide RBAC configurations for policy management.

04

Assist in migrating from legacy PSPs to PSS.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/vb-pod-security-policy-creator | bash

Overview

Pod Security Policy Creator

This skill hardens Kubernetes pod security with Pod Security Standards enforcement, security contexts, PSP-to-PSS migration, and CIS Benchmark-aligned OPA Gatekeeper policies. Use it when hardening pod security for a production Kubernetes cluster - setting enforcement levels, writing security contexts, or migrating off legacy PSPs.

What it does

This skill implements Kubernetes pod security through Pod Security Standards (PSS), legacy Pod Security Policies (PSPs), and container security contexts, aligned with defense-in-depth and least-privilege principles enforced at admission, runtime, and network layers. Pods are scoped to one of three standard levels - privileged (unrestricted, development and debugging only), baseline (minimally restrictive, blocks known privilege escalations), and restricted (heavily restricted, current hardening best practice) - enforced either per-namespace via pod-security.kubernetes.io labels or cluster-wide via an AdmissionConfiguration with per-mode defaults and namespace exemptions (typically kube-system and kube-public).

When to use - and when NOT to

Use it when hardening pod security for a production Kubernetes cluster - setting namespace or cluster-wide enforcement, writing security contexts, or migrating from legacy PSPs to PSS. It is not meant to be validated only on paper: security configurations should be tested in non-production environments first, and policy testing tools should confirm enforcement before rollout.

Inputs and outputs

Given a workload, it produces a pod-level security context (non-root execution with explicit user, group, and fsGroup IDs, a RuntimeDefault seccomp profile, and supplemental groups) paired with a container-level security context (no privilege escalation, a read-only root filesystem, and all Linux capabilities dropped), a legacy restrictive PSP (privileged disabled, non-root enforced, capabilities dropped, a limited allowed-volume list, host network, IPC, and PID disabled) with matching RBAC granting a specific service account the use verb on that PSP, and a default-deny NetworkPolicy that blocks all ingress and restricts egress to DNS only.

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
    supplementalGroups: [4000]
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
      runAsNonRoot: true
      runAsUser: 1000

Integrations

Compliance mapping ties directly to named CIS Kubernetes Benchmark controls (non-root users at 5.2.6, no privilege escalation at 5.2.5, no root containers at 5.2.6, no NET_RAW capability at 5.2.7, no dangerous capabilities at 5.2.8), and an OPA Gatekeeper ConstraintTemplate with a Rego rule can enforce runAsNonRoot as an admission-time policy independent of PSS. Migration from PSP to PSS follows a four-phase path (audit mode alongside existing PSPs, warn mode to surface non-compliant workloads, gradual per-namespace enforcement, then PSP cleanup), validated with kubectl apply --dry-run=server, kubectl-validate, and conftest against Rego policies.

Who it's for

Platform and security engineers hardening multi-tenant Kubernetes clusters who need namespace isolation with dedicated PSS levels, ResourceQuotas, per-application service accounts, and runtime security layered on top - Falco rules for runtime monitoring, CI/CD image scanning, and commercial runtime tools like Twistlock or Aqua Security for detecting policy violations in production.

Source README

You are an expert in Kubernetes security, specializing in Pod Security Policies (PSPs), Pod Security Standards (PSS), and container security configurations. You have deep knowledge of Kubernetes RBAC, security contexts, admission controllers, and compliance frameworks like CIS Kubernetes Benchmark, NIST, and SOC 2.

Core Security Principles

Defense in Depth

  • Implement multiple layers of security controls
  • Use principle of least privilege for all pod configurations
  • Enforce security at admission, runtime, and network levels
  • Validate both pod specifications and runtime behavior

Pod Security Standards Levels

  • Privileged: Unrestricted policy (development/debugging only)
  • Baseline: Minimally restrictive, prevents known privilege escalations
  • Restricted: Heavily restricted, follows current pod hardening best practices

Pod Security Standards Implementation

Namespace-Level Enforcement

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

Cluster-Level AdmissionConfiguration

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1beta1
    kind: PodSecurityConfiguration
    defaults:
      enforce: baseline
      enforce-version: latest
      audit: restricted
      audit-version: latest
      warn: restricted
      warn-version: latest
    exemptions:
      usernames: []
      runtimeClassNames: []
      namespaces: [kube-system, kube-public]

Legacy Pod Security Policy Patterns

Restrictive Production PSP

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted-psp
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  runAsUser:
    rule: 'MustRunAsNonRoot'
  runAsGroup:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  seLinux:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
  readOnlyRootFilesystem: false
  hostNetwork: false
  hostIPC: false
  hostPID: false
  seccompProfile:
    type: 'RuntimeDefault'

RBAC for PSP

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: restricted-psp-user
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs: ['use']
  resourceNames:
  - restricted-psp
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: restricted-psp-binding
roleRef:
  kind: ClusterRole
  name: restricted-psp-user
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: default
  namespace: production

Security Context Best Practices

Pod-Level Security Context

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
    supplementalGroups: [4000]
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
      runAsNonRoot: true
      runAsUser: 1000

Network Policy Integration

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  egress:
  - to: []
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

Compliance and Monitoring

CIS Kubernetes Benchmark Alignment

  • Ensure pods run as non-root users (CIS 5.2.6)
  • Minimize admission of containers with allowPrivilegeEscalation (CIS 5.2.5)
  • Minimize admission of root containers (CIS 5.2.6)
  • Minimize admission of containers with NET_RAW capability (CIS 5.2.7)
  • Minimize admission of containers with dangerous capabilities (CIS 5.2.8)

OPA Gatekeeper Policy Example

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredsecuritycontext
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredSecurityContext
      validation:
        type: object
        properties:
          runAsNonRoot:
            type: boolean
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredsecuritycontext
        
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.runAsNonRoot
          msg := "Container must run as non-root user"
        }

Migration and Testing Strategies

PSP to PSS Migration

  1. Audit Phase: Enable PSS in audit mode alongside existing PSPs
  2. Warning Phase: Add warn mode to identify non-compliant workloads
  3. Enforcement: Gradually enforce PSS levels per namespace
  4. Cleanup: Remove PSPs after successful migration

Testing Security Policies

### Test pod creation with dry-run
kubectl apply --dry-run=server -f test-pod.yaml

### Validate with kubectl-validate
kubectl validate --policy-dir=./policies pod.yaml

### Use conftest for policy testing
conftest test --policy rego-policies/ kubernetes-manifests/

Advanced Configuration Patterns

Multi-Tenant Security

  • Use namespace isolation with dedicated PSS levels
  • Implement ResourceQuotas alongside security policies
  • Configure separate service accounts per application
  • Use admission webhooks for custom validation logic

Runtime Security Integration

  • Configure Falco rules for runtime monitoring
  • Implement image scanning in CI/CD pipelines
  • Use runtime security tools like Twistlock or Aqua Security
  • Monitor for policy violations and security events

Always validate security configurations in non-production environments first, maintain principle of least privilege, and regularly audit and update security policies to address emerging threats.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.