WIP: Add signed image verification support for peer pods

[stevenhorsman]

Once we have signed image support in kata-containers, we should get it working in peer pods and add some testing in peer pods to check it works correctly

One complication is that we need to ensure that enable_signature_verification=true and image_policy_file=kbs:///default/security-policy/test in the agent config. At the moment I don't think we have an easy way to set dynamic data into agent-config.toml. There a few possible options I can think of:

1. Add agent-config.toml to the initdata annotation
2. Wait for Move guest pull ability to a configurable component kata-containers/kata-containers#9266 to be implemented and potentially add these setting to the cdh.toml in initdata annotation
3. Follow the aa_kbc_params approach and add these configuration to peer-pod-cm and then read them in as parameters on the CAA - this feels a bit messy and not very scalable
4. Follow a similar approach to auth.json and mount a new file with the dynamic data?
5. Something better than the above

I guess we also want these parameters to be part of the measurement, so that an admin couldn't just turn it off, which probably narrows our options too.

Update - I chatted to Ding about option 2 and it's in progress confidential-containers/guest-components#608 at the moment, so I guess we could either wait for it, or potentially start with a temporary strategy for passing the info into peer pods, and then switch to using CDH via init data after?

Acceptance Criteria

We have more test cases on Kata for different negative and positive test scenarios, but I think a basic positive and negative test on peer pods should be sufficient

Given I have a version of kata deployed with a peer pod image that has an agent with guest_pull feature enabled and the attestation-agent installed, as well as the and nydus-snapshotter installed and configured for guest-pulling
And a kbs deployed, which we can interact with via the kbs-client-cli
And I have setting enable_signature_verification=true and image_policy_file=kbs:///default/security-policy/test via the agent config somehow

Scenario: Create a pod from an unsigned image, on a 'restricted registry' is rejected
Given A public unsigned container image i from registry r and a KBS resources, or agent config configured to read a policy file like:

{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports": {
        "docker": {
            "<r>": [
                {
                    "type": "sigstoreSigned",
                    "keyPath": "kbs:///default/cosign-public-key/test"
                }
            ]
        }
    }
}

When I try and create a pod from i
Then The pod is not created an we get an appropriate error message in the logs e.g. Validate image failed

Scenario: Create a pod from a signed image, on a 'restricted registry' is successful
Given A public signed container image s signed with a key k from registry r and a KBS resources or agent config configured to read a policy file like:

{
    "default": [
        {
            "type": "reject"
        }
    ],
    "transports": {
        "docker": {
            "<r>": [
                {
                    "type": "sigstoreSigned",
                     "keyPath": "kbs:///default/cosign-public-key/test"
                }
            ]
        }
    }
}

And the public gpg key is provide in the KBS resource like:

"default/cosign-public-key/test": "<base64 encoding of k>"

When I try and create a pod from i
Then The pod is successfully created and runs

[wainersm]

Hi @stevenhorsman @Xynnn007 !

I'm trying to understand where we are with this feature. Mind to help me with some clarifications?

The confidential-containers/guest-components#608 was merged so I assume we chose the solution (2) (Wait for https://github.com/kata-containers/kata-containers/issues/9266 to be implemented and potentially add these setting to the cdh.toml in initdata annotation). On guest-components side, pull_image() is part of CDH's API and CDH's configuration toml has a [image] section to hold image pull specific configurations (see example.config.toml) for authenticated registries, container policy (signature verification)...etc.

On guest-components side, is there anything else needed?

On kata side, it seems that kata-containers/kata-containers#10163 is the next piece in the puzzle, isn't it?

[Xynnn007]

Hi @wainersm . I think you are right that kata-containers/kata-containers#10163 (moved to kata-containers/kata-containers#10610) is the next step, which I am working on.

Guest-components side is ok for now as you mentioned. Different kinds of images (authed registry, encrypted image, signed image) are test each PR with code here.