How are we implementing policies in peerpods?

[katexochen]

The initial PR was merged into kata, enabling policy enforcement on calls from the kata-shim.

• Presentation
• Project dashboard

In the last peerpods-call, we started discussion how we should bring this feature to peerpods. I'm opening this issue so we can continue the discussion here. This is not intended to be an implementation proposal. I rather want to collect open questions and requirements, so we can build a proposal on top of this.I collected the following points from @danmihai1's presentation and our discussion, please correct me if I got things wrong.

---

Open questions

• Do we want to do policy validation on additional, peerpods-specific values?
  • In the call, user-data config was mentioned, I'm not quite sure where this is passes
• How is the policy delivered into the peerpods VM? Dan mentioned three ways the presentation:
  • Policy from pod annotation: the pod is annotated with the policy and set by the kata-shim
  • Policy hard-coded in image: the policy is part of the image.
  • Policy comes from the KBS: the kata-agent requests the policy from the KBS
• How do we attest the policy?
  • Dan suggests to bind the policy to the CVM attestation through HOST_DATA (or matching field in TDX). As far as I understand, this is possible for some peerpod TEEs (s390x?) but not for others (AzureCVMs don't let you set HOST_DATA).
  • Measure during runtime (e.g., when SetPolicy is called on the kata-agent). Possible, where a vTPM is available.
  • Other ways?

[jepio]

Measure during runtime (e.g., when SetPolicy is called on the kata-agent). Possible, where a vTPM is available.

I was thinking this.

[danmihai1]

Thanks for starting this discussion @katexochen @jepio !

If any folks are interested in pulling the Policy from KBS or similar service, please reach out to me to make sure we are on the same page. As Paul, James, and others said, these are the main steps for using Policy:

1. Create the policy

   • For example, AKS is generating their Policy using the tool from https://github.com/kata-containers/kata-containers/pull/8248 .

2. Provide the Policy to the Guest VM

   • The Policy is essentially just a file, that the Guest can obtain from any source it wants, including KBS or similar service.

3. Verifying the Policy integrity

   • If the policy has been downloaded securely from a KBS that has been authenticated correctly by the Guest already, that should be good enough to declare that the policy integrity has been already verified.

4. Enforcing the policy inside the Guest

   • This is now implemented in the main branch.

[katexochen]

@danmihai1 I don't really want to pull the policy from KBS. Rather, I would prefer using the SetPolicy mechanism that you already implemented in Kata. However, we need a mechanism to measure the policy.

Do you think we could integrate a feature in the kata-agent to measure the policy into a vTPM?

[danmihai1]

@katexochen It's very likely that you can measure the policy using vTPM. If you already measure other types of data, and you have a good way to verify the vTMP measurement, you'd "just" have to extend the vTPM measurement to cover the policy contents too.

check_policy_hash() from https://github.com/microsoft/kata-containers/blob/2795dae5e99bd918b7b8d0a9643e9a857e95813d/src/agent/src/policy.rs#L261 is how I compared the measurement of the policy against a the TEE field value that can be remotely attested.

In your case, you would add the policy measurement to vTPM, using code similar to check_policy_hash(). Then, you'd have to be sure that the verification of the vTPM based measurement takes place later (is that verification implemented using remote attestation?).

[katexochen]

Then, you'd have to be sure that the verification of the vTPM based measurement takes place later (is that verification implemented using remote attestation?).

Exactly, you would always allow SetPolicy and then check the expected policy was measured through remote attestation.

[bpradipt]

A phase wise implementation in peer-pods will help imho. Phase-1: Get the policy support working without measurements. This will be similar to Kata for Kata remote hyp without CoCo Phase-2: The measurement part (subject to conclusion of the discussions related to initdata)

I have started looking at Phase-1. If anyone is already looking at it please let me know and we can join forces :-)

[bpradipt]

The basic policy support is working using backported policy code here - https://github.com/bpradipt/kata-containers/tree/CC-0.8.1-policy The CAA changes are available in https://github.com/bpradipt/cloud-api-adaptor/tree/policy

The podvm changes to add opa service and rules depends on - https://github.com/confidential-containers/cloud-api-adaptor/pull/1602

If you run into any issues trying to get this working, let me know. Formal support will be added once we switch CAA to use kata-containers from main.

[bpradipt]

cc @katexochen @stevenhorsman @mkulke

[bpradipt]

Policy support is available in peer-pods. Closing this issue