Epic Goal

• Enhance the official Red Hat Kata Containers RPM to include all necessary components for CoCo on Bare Metal, providing a secure-by-default guest environment that is customizable for enterprise needs (like authenticated private registries, using custom CA certs etc) and includes critical storage modules.

Why is this important?

• This epic focuses on packaging all guest-side requirements and tools into the Kata RPM. Key activities include:

• Kata-containers rpm with CoCo changes
  • Changes merged in the main branch of downstream fork

• Basic initrd
  • Guest Component Integration: Integrate CoCo guest components (attestation agent, etc.) and initrd build scripts into the RPM.
  • Guest Content - Storage & Security Modules: Ensure the default guest initrd includes essential storage client kernel modules (NFS, iSCSI, dm-crypt).
  • Implement a default restrictive Kata agent security policy (e.g., exec/logs disabled).

• • Debug initrd
• Debug tools (bash shell, other utilities for debugging)

• • initrd Customization for CAs/Auth: Provide a robust and documented mechanism for users to customize the Kata guest initrd with their own CA certificates and registry authentication files. Deliver a container image to facilitate this build process outside the host.
  • Guest Agent Policy & Hardening:
  • Provide a clear, documented mechanism for users to select a "debug" initrd or policy (e.g., via pod annotation) to enable commands like exec for troubleshooting. This is a prerequisite for the Milestone 1 demo.
  • Provide launch measurements for the initrd

Scenarios

1. As a Security Officer, I need the initrd build process to generate a measurement hash so this can be used in attestation policies to ensure the integrity of the guest environment.
2. As a Security Officer, I want the default CoCo guest environment to have a restrictive policy (e.g., no exec access) to minimize the attack surface.
3. As a Developer, I want to enable a debug mode for a specific CoCo pod so I can troubleshoot issues inside the guest.
4. As a DevOps Engineer, I need a container image with all the necessary tools (kata-osbuilder, etc.) so I can build a custom initrd with my company's CA certificates.
5. As a DevOps Engineer, I want to be able to add custom entries to the /etc/hosts file within the initrd to resolve internal service names.

Acceptance Criteria 

(The Epic is complete when...)

1. The initrd build script provided in the RPM outputs a verifiable measurement hash.
2. The default Kata guest agent policy disables exec and logs access.
3. A documented pod annotation allows the selection of a debug policy/initrd that enables exec.
4. A container image for building the initrd is available and documented.
5. The default initrd contains essential storage client kernel modules (iSCSI, dm-crypt).
6. The Kata runtime can expose the TEE status of a running sandbox to the OSC Monitor.

Additional context: