Epic Goal Transition the default Kata agent policy for all Confidential Containers (CoCo) deployments from permissive to restrictive, ensuring a secure-by-default posture that is consistent across both bare-metal and peer-pods environments.

Why is this important? Adopting a "secure by default" model aligns CoCo with a zero-trust security posture, which is a core expectation for confidential computing solutions. The current permissive default (allow-all) creates a significant risk that users could inadvertently deploy workloads with insecure configurations (e.g., leaving oc exec enabled) in production. This change strengthens the product's security narrative, reduces the cognitive load on administrators to secure the environment, and better aligns with customer expectations for a confidential computing product.

Scenarios

• An administrator deploys a new Confidential Container and, by default, cannot use oc exec or oc logs, confirming the restrictive policy is active.

• A developer needs to debug a failing application inside a Confidential Container, follows the new documentation to override the default policy for that specific pod, and successfully enables oc logs to view the output.

• A security architect reviews the CoCo configuration and confirms that the default Kata agent policy prevents unauthorized access to running confidential pods, satisfying their compliance requirements.

• An administrator managing a mixed cluster (bare-metal and peer-pods) observes a consistent, restrictive-by-default behavior for all confidential workloads, simplifying their operational procedures.

Acceptance Criteria (The Epic is complete when...)

• A new default restrictive Rego policy file (default-restrictive.rego) is created and checked into the appropriate repository.

• The pre-built initrd for CoCo on bare metal includes and enables this restrictive policy by default.

• The CoCo peer-pods flow is updated to enforce the same restrictive policy by default for confidential workloads.

• By default, a user can create a confidential pod, but attempts to use oc exec or oc logs on that pod fail as expected.

• A user can successfully override the default policy (e.g., via initdata) to enable exec and logs for a specific pod.

• Official documentation is updated to:

• • Explain the new "secure by default" behavior.

• • Provide clear, step-by-step instructions for enabling exec and logs when needed.

• • Include a troubleshooting section for debugging pods when logs are disabled.

• End-to-end CI tests are implemented and passing, which verify:

• • The default restrictive behavior (e.g., exec and logs are blocked).

• • The policy override mechanism works correctly.

Additional context: A key driver for this epic is the need for a uniform user experience across all CoCo deployment models. Any implementation must ensure that the default policy and the method for overriding it are identical for both bare-metal and peer-pods deployments. This consistency is critical for clear documentation, user expectations, and overall product coherence. The policy must still allow operations essential for basic pod functionality, such as CopyFileRequest when shared_fs = none is used.