[DEV] Integrate Keylime for Secure Attestation in Deployment Recipes

[alexlovelltroy]

Proposal to Integrate Keylime for Enrollment and Continuous Attestation

Background

This proposal builds on our RFD for secure attestation by integrating Keylime into one of our existing deployment recipes within the repository. The primary aim is to leverage Keylime’s attestation capabilities to ensure secure enrollment and continuous attestation.

Objectives

• Incorporate Keylime Client: The Keylime client will need to be included as part of the deployment process for systems requiring attestation.
• Agent Configuration: For testing with the Keylime server, we will ensure that the Keylime agent is either pre-installed in the system image or provisioned via a post-boot script.
• User Data Script for Flexibility: While pre-installing the Keylime agent in the build image is preferable, we propose also providing an example cloud-init user_data script. This script will automate the installation and initialization of the Keylime Rust agent after the instance boots. This approach provides flexibility and serves as an example for developers aiming to adapt Keylime to their deployment scenarios.

Proposed Implementation

1. Integration of Keylime in Deployment Recipe:
   [ ] Identify a deployment recipe in the repository that would benefit from secure attestation.
   [ ] Incorporate the Keylime server and configuration in the deployment process.

2. Build Image with Pre-installed Keylime Agent:
   [ ] Add the Keylime Rust agent to the build image, ensuring it is included in systems that will undergo attestation.
   [ ] Configure the image so the agent communicates with the Keylime server after boot. Cloud-init? Kernel Param?

3. Example cloud-init User Data Script:
   [ ] Provide a sample cloud-init user_data script that installs, configures, and starts the Keylime Rust agent post-boot.
   Note The script will serve as a template for users who may not wish to modify their build images directly but still require Keylime's functionality.

Future Options to Discuss

• Custom UEFI boot firmware that can perform attestation before handing off to the user-provided OS
• Continuous Attestation Procedure
• Attestation pre and post job runs with transparency log
• Keylime alternatives

This feature will enhance the security profile of OpenCHAMI deployments by providing an integrated and flexible approach to attestation, helping ensure integrity throughout the deployment lifecycle. Your feedback and ideas are greatly appreciated!