Skip to content

Kubernetes PSS (Restricted Profile) - Development

Enforcement Level: Restricted  |  Scope: Build Environment Isolation  |  K8s Ver: v1.24+

Shared Responsibility: Developer & Operator

This report confirms that the Development SDK Image is architected to run within a Restricted Kubernetes Namespace. While the image is natively non-root and lacks privileged binaries, the final compliance is a shared effort. Learn more about the Shared Responsibility Model

Admission Controller Readiness

  • Policy Status --- READY
    SDK is Restricted-Capable

    - Rules Satisfied

    17 / 17

    Baseline + Restricted Policies

  • Blocking Violations --- 0 Must Resolve in Dockerfile

Secure Pipeline Ready

The Development SDK satisfies all Static PSS Checks. It is safe to use as a CI/CD build agent in hardened, multi-tenant Kubernetes clusters.

Policy Enforcement Matrix

ID Restriction Rule Impact Level Static Audit
1 HostProcess HIGH
2 Host Namespaces HIGH
3 Privileged Containers HIGH
4 Capabilities MEDIUM
5 HostPath Volumes MEDIUM
6 host ports HIGH
7 AppArmor HIGH
8 SELinux MEDIUM
9 /proc Mount Type MEDIUM
10 Seccomp MEDIUM
11 Sysctls MEDIUM
12 Volume Types LOW
13 Privilege Escalation MEDIUM
14 Running as Non-root MEDIUM
15 Running as Non-root user LOW
16 Seccomp LOW
17 Capabilities LOW

Why This Matters for Development?

Running build tools (Compilers, Linkers) in a Restricted PSS environment ensures that the development phase doesn't become the "weakest link":

  1. Isolation: Even if a compiler is compromised, it cannot access the host network or sensitive kernel namespaces.
  2. Least Privilege: Ensuring build agents run as openssl (non-root) prevents "Escape-to-Host" attacks from within the CI pipeline.
  3. Governance: Matches the security posture of the production Distroless image, creating a consistent security baseline across the SDLC.

Back to Top