Create Secure Kubernetes Pod Configurations
A skill for hardening Kubernetes pod security - PSS enforcement levels, security contexts, PSP-to-PSS migration, CIS alignment.
Maintainer of this project? Claim this page to edit the listing.
1.0.0Add 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
Generate Pod Security Policy (PSP) and Pod Security Standards (PSS) configurations.
Implement namespace-level and cluster-level security enforcement.
Provide RBAC configurations for policy management.
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
- Audit Phase: Enable PSS in audit mode alongside existing PSPs
- Warning Phase: Add warn mode to identify non-compliant workloads
- Enforcement: Gradually enforce PSS levels per namespace
- 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.