Kubernetes Pod Security Standards

Privileged Profile

• Unrestricted policy with minimal security controls
• Allows privileged operations that could compromise the node
• Provides the same level of access as the node's root user
• Suitable for system-level workloads that require extensive permissions
• Examples: cluster add-ons, node monitoring agents, CNI plugins
• Used when functionality takes precedence over security restrictions
• Represents the highest risk level if compromised
• Permits all privileged escalation paths, including:
  • Running as privileged containers
  • Accessing host namespaces (network, PID, IPC)
  • Using host ports and networking
  • Mounting host paths and sensitive volumes
  • Running as root with unrestricted capabilities
• Specific use cases include:
  • Container networking plugins requiring host network access
  • Storage drivers requiring direct device access
  • Node problem detectors requiring deep system visibility
  • Monitoring agents requiring comprehensive system metrics
  • Security tooling that enforces policies at the node level

Baseline Profile

• Minimally restrictive policy that prevents known privilege escalations
• Allows default (minimally specified) Pod configuration
• Permits most workloads to run without modification
• Blocks known privilege escalation vectors
• Restricts dangerous capabilities and host access
• Suitable for default security for non-sensitive applications
• Represents a middle ground between functionality and security
• Prevents the following high-risk practices:
  • Running privileged containers
  • Sharing host namespaces directly
  • Mounting host directories as writable volumes
  • Running as root with dangerous capabilities
  • Using hostPort to bind to host network interfaces
• Allows common container behaviors:
  • Running as any user ID, including root
  • Adding and dropping specific capabilities
  • Using the default seccomp profile
  • Using any SELinux context configured by the platform
  • Using any AppArmor profile configured by the platform
  • Mounting persistent volumes, configMaps, and secrets
• Most suitable for:
  • Legacy applications that haven't been designed for security
  • Applications from third parties without security modifications
  • Internal applications with moderate security requirements
  • Development and testing environments

Restricted Profile

• Highly restrictive policy enforcing security best practices
• Follows hardening guidelines for pods
• Significantly limits the attack surface of containerized applications
• Suitable for applications handling sensitive data or running in multi-tenant environments
• Implements principle of least privilege
• May require modifications to existing workloads to be compliant
• Represents the most secure configuration for critical workloads
• Enforces strong security controls including:
  • Mandatory non-root user execution
  • Prevention of privilege escalation completely
  • Removal of ALL Linux capabilities by default
  • Strict use of SecComp profiles (RuntimeDefault or Localhost)
  • Restriction of volume types to secure options only
  • Prohibition of hostPath volumes entirely
  • Restriction of file system groups and supplemental groups
  • Required read-only root filesystems
  • Explicit declaration of security contexts
• Applications must be specifically designed for:
  • Running with least privilege
  • Operating without root access
  • Using minimal container images
  • Functioning with immutable filesystems
  • Declaring all required permissions explicitly
• Best suited for:
  • High-security workloads with sensitive data
  • Multi-tenant environments with strong isolation needs
  • Financial, healthcare, and government applications
  • Applications subject to compliance requirements
  • Production environments with critical infrastructure

Pod Security Admission Controller

• Built-in admission controller in Kubernetes 1.23+
• Configurable at namespace level
• Supports three modes: enforce, audit, and warn
• Labels determine which standards apply to each namespace
• Three enforcement modes with different behaviors:
  • enforce: Rejects non-compliant pods at admission time
  • audit: Allows non-compliant pods but logs violations as audit events
  • warn: Allows non-compliant pods but returns warnings to the user
• Can apply different profiles to each mode:
  • Enforce baseline while auditing against restricted
  • Gradually increase enforcement as applications adapt
  • Maintain visibility into compliance status during migration
• Optional version control through additional labels:
  • pod-security.kubernetes.io/enforce-version: v1.25
  • Ensures stability during Kubernetes upgrades
  • Controls which version of the PSS specification applies
• Example namespace labels:
  apiVersion: v1
  kind: Namespace
  metadata:
    name: production
    labels:
      pod-security.kubernetes.io/enforce: restricted
      pod-security.kubernetes.io/audit: restricted
      pod-security.kubernetes.io/warn: restricted
  

• Graduated implementation example:
  apiVersion: v1
  kind: Namespace
  metadata:
    name: transitional-namespace
    labels:
      pod-security.kubernetes.io/enforce: baseline
      pod-security.kubernetes.io/audit: restricted
      pod-security.kubernetes.io/warn: restricted
      pod-security.kubernetes.io/enforce-version: v1.24
  

Webhook-based Solutions

• Use dynamic admission controllers for fine-grained control
• Examples include OPA Gatekeeper and Kyverno
• Allows for custom policies beyond standard PSS
• Supports advanced validation logic
• Key advantages over built-in admission controller:
  • More complex conditional logic and exceptions
  • Custom validation rules specific to organization needs
  • Integration with external policy systems
  • Ability to mutate pods to make them compliant
  • Centralized policy management across clusters
  • Integration with audit and compliance systems
  • Support for non-pod resources (Deployments, StatefulSets)
• Kyverno features:
  • Kubernetes-native policy management
  • No new language to learn (uses YAML)
  • Supports validation, mutation, and generation
  • Can enforce PSS profiles plus additional controls
  • Provides exceptions mechanism for special cases
• Example Kyverno policy:
  apiVersion: kyverno.io/v1
  kind: ClusterPolicy
  metadata:
    name: restrict-privileged-containers
  spec:
    validationFailureAction: enforce
    rules:
    - name: privileged-containers
      match:
        resources:
          kinds:
          - Pod
      validate:
        message: "Privileged containers are not allowed"
        pattern:
          spec:
            containers:
              - name: "*"
                securityContext:
                  privileged: false
  

• Advanced Kyverno policy with exceptions:
  apiVersion: kyverno.io/v1
  kind: ClusterPolicy
  metadata:
    name: restricted-security-context
  spec:
    validationFailureAction: enforce
    background: true
    rules:
    - name: restricted-securitycontext
      match:
        resources:
          kinds:
          - Pod
      exclude:
        resources:
          namespaces:
          - kube-system
          - monitoring
      validate:
        message: "Use of restricted security context settings is not allowed"
        pattern:
          spec:
            containers:
            - name: "*"
              securityContext:
                allowPrivilegeEscalation: "false"
                runAsNonRoot: "true"
                capabilities:
                  drop: ["ALL"]
                seccompProfile:
                  type: "RuntimeDefault"
  

Policy-as-Code Tools

• Define security policies as code
• Integrates with GitOps workflows
• Examples include Conftest and Checkov
• Validates manifests before deployment
• Shift-left security approach:
  • Catches security issues before deployment
  • Integrates into CI/CD pipelines
  • Provides feedback during development
  • Enforces policies at code review time
  • Prevents non-compliant resources from being applied
  • Reduces operational security burden
• Open Policy Agent (OPA) Conftest:
  • Uses Rego policy language
  • Validates Kubernetes YAML against policies
  • Can be run locally or in CI/CD pipelines
  • Provides detailed policy violation information
  • Supports multiple policy libraries
• Infrastructure as Code scanning:
  • Checkov analyzes Kubernetes manifests for misconfigurations
  • Detects security issues across multiple resources
  • Provides auto-remediation suggestions
  • Can enforce PSS controls pre-deployment
• Example Conftest policy:
  package main
  
  # Basic privileged container check
  deny[msg] {
    input.kind == "Pod"
    input.spec.containers[i].securityContext.privileged
    msg = sprintf("Privileged container is not allowed: %v", [input.spec.containers[i].name])
  }
  
  # Comprehensive PSS Restricted profile check
  deny[msg] {
    input.kind == "Pod"
    container := input.spec.containers[i]
    not restricted_security_context(container)
    msg = sprintf("Container %v does not comply with Restricted PSS profile", [container.name])
  }
  
  restricted_security_context(container) {
    # Must run as non-root
    container.securityContext.runAsNonRoot == true
    
    # Must not allow privilege escalation
    container.securityContext.allowPrivilegeEscalation == false
    
    # Must drop all capabilities
    container.securityContext.capabilities.drop[_] == "ALL"
    
    # Must use RuntimeDefault seccomp profile
    container.securityContext.seccompProfile.type == "RuntimeDefault"
  }
  

Security Contexts

• Apply security settings directly to pods and containers
• Implement controls without admission controllers
• Requires discipline from application teams
• Example pod with security contexts:
  apiVersion: v1
  kind: Pod
  metadata:
    name: security-context-demo
  spec:
    securityContext:
      runAsNonRoot: true
      seccompProfile:
        type: RuntimeDefault
    containers:
    - name: app
      image: myapp:1.0
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
        readOnlyRootFilesystem: true