agent: add container launch control parameters from kernel commandline #6707
Conversation
`image_policy_file` is the URI of the image security policy file which is used to control the allowlist and denylist of the containers to be run inside the guest. `image_registry_auth_file` is the URI of the auth file which is needed to access an private registry. `simple_signing_sigstore_config` is a configuration file that shows where the signature files are when simple signing is enabled. All the config items support both `kbs://..` scheme, `file://..` scheme, or a direct absolute path `/...`, which means either the file is to be fetched from a remote KBS that `aa_kbc_params` points to, or from the local filesystem of the guest. Fixes: kata-containers#6640 Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
|
Can one of the admins verify this patch? |
|
/test |
|
I like this idea. In the last release we added resource URIs that allow the KBS to serve multiple versions of the signature policy and other resources, but currently the URI of the signature policy is hard-coded so we don't really use that feature. One suggestion would be to simplify the interface by just supplying repository/id from the command line. These could be used to generate the three URIs. Do you think that would be simpler? It is slightly less flexible. |
|
Thanks, Tobin!
In my opinion the kernel parameter here to specify these configurations are underlying things and they'd better be flexible enough. For the convenience of users, we can consider a CLI tool or something that receives a simple request from user and translate that request into a complex one. User can maintain an default "secure" config on the My core point of view is that the underlying things should be as extensible as possible, so that only encapsulation is required in the subsequent development process, so as to avoid repeated development at the bottom layer in order to expand a certain feature. |
Maybe we could implement this in the shim? Rather than setting the kernel params directly the user could set an annotation that specifies some kind of pod identity. The shim would use this to formulate the path for the configs and add them to the kernel params. |
I like this idea. Maybe the process can be described as the following:
Up to know, AS can already know the requested policy and the identity of the pod. We can think whether we also need to embed the identity into CONFIGID-like fields before launch the VM. |
|
Thanks Ding, this PR looks good and would help a use-case that we've heard in the peer pods community where people want to effectively use the offline_fs_kbc for image pull credentials, but cc_kbc for pulling runtime secrets/decryption keys from remote attestation. From what I understand this would allow us to just embed the cc_kbc module built attestation-agent into the peer pod VM image and then rather than use the offline_fs_kbc writing our credentials to I guess with the remote-hypervisor we don't use annotations, or the shim to set the kernel_params, so Tobin's question isn't so important. I do prefer the idea of the annotation over overloading the kernel_params even more than we already do though! |
|
@stevenhorsman Sounds great to me Steve! @fitzthum Hey Tobin, can we get this PR approved/merged now? It can be done in future about the derivation of the kernel commandline. |
There was a problem hiding this comment.
LGTM - thanks @Xynnn007.
Just one question - will we need to bump image-rs in order to test this, or is the 0.6 release version compatible with this?
v0.6.0 is compatible with this. |
Thanks - Do you think it is worth adding some CI tests for this behaviour and then we can repurpose them to check the annotation when that gets added? |
Ci test sounds good to me. With the base CI we can extend it into different aims, including the stated annotation test. Furthermore, any potential test in future that would have a specific parameter in kernel parameter would benefit from this, like the dm-verity for encrypted rootfs. |
Would you be able to raise an issue on the tests repo for this? I won't have capacity to look at it myself in the short-term, but might be able to find someone else to help and otherwise it would be good to track so I don't forget about it. |
|
One thing to mention is that we may need to think about the best way to handle some of these features from the KBS side. For instance, we are introducing the ability for different pods to request different resources, but we don't really have any logic to group resources together in the KBS. |
|
I flagged this up on last weeks CoCo call as available to review and there have been no takers, so I think we can merge it in now. |
Hi, I'm not sure whether it is still ok to make PR to CCv0 branch. If not, please tell me the correct thing to do.
About this PR
Add three commdline parameters to control the container launch process
image_policy_fileis the URI of the image security policy file which is used to control the allowlist and denylist of the containers to be run inside the guest. If not set, usekbs:///default/security-policy/testby default.image_registry_auth_fileis the URI of the auth file which is needed to access an private registry. If not set, usekbs:///default/credential/testby default.simple_signing_sigstore_configis a configuration file that shows where the signature files are when simple signing is enabled. If not set, usekbs:///default/sigstore-config/testby default.All the config items support both
kbs://..scheme,file://..scheme, or a direct absolute path/..., which means either the file is to be fetched from a remote KBS thataa_kbc_paramspoints to, or from the local filesystem of the guest.Fixes: #6640