-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add policy support to peer-pods #1607
Conversation
134f466
to
7466793
Compare
For testing, new Kata shim (from CCv0) is needed. A quick way is to use the following daemonset to replace the existing shim with the new one - https://gist.githubusercontent.com/bpradipt/971b2423e183839ae2f73e3bfa3670eb/raw/0db094e6bc85337b252a0456ea8c751f51543751/kata-ds.yaml CAA image: quay.io/bpradipt/cloud-api-adaptor:latest |
9051a5e
to
69bf62a
Compare
Tested a scenario where the default policy only allows SetPolicy API
And policy is made available via annotation
CAA logs
|
In order to test with mkosi image, apply the following patch
I had to add a commit to fix the missing agent-config.toml in |
@mkulke @katexochen @stevenhorsman ptal The default policy is to allow all api. There are sample policies to "disable only exec api" and "disable all except setpolicy". Here is a sample pod yaml which disables exec
|
@stevenhorsman I couldn't find s390x binary for opa from the release page, however the opa support code is written in a way that it should be easy to extend and include opa binary for s390x podvm images. |
Good point - in kata-containers (https://github.com/kata-containers/kata-containers/pull/7769/files) we built it from source, but I'm not sure if there is any plan to get upstream to create s390x & ppc64le releases, or if we'll need to self-build in peer pods too. @BbolroC - might know |
I haven't raised any discussion internally yet. I will bring up this topic soon and update you guys on the plan. Thanks! |
I can also add support to build the opa binary from source. |
@stevenhorsman @BbolroC I have switched to building OPA from source. Ptal. |
|
Is there any intention to add an e2e test for this? I think without it and considering that a user can't run it with standard operator deploy as they need a custom payload we should add at the start of the docs that this is an untested, experimental feature and mention the manual adjustment required? |
I'll add it. My intention was to avoid additional Makefile options if possible. So only added it in Dockerfile allowing anyone to use explicit docker build to use a different policy file than what is shipped and tested as part of upstream. |
e2e is definitely needed. But I would prefer to do it as a separate PR. Also for users, we expect them to deploy released version and main is anyway unstable. Or am I missing something ? |
Sorry if I confused things further. I didn't necessarily mean for it to get added now (though we need to make our docs consistent long term), which is why I said |
I think that's fair, I didn't really mean users, more developers who want to play around with policy to let them know it doesn't work from the |
Personally my thinking is that operator deployment from main and kata payload are transient aspects. |
I think this is enough. I definitely appreciate the position you are coming from where this is dev code, not a release, so things aren't expected to work cleanly, and I don't want to hold up good work, but I'm aware that 0.9 is likely to be an extended release, so want to try and be sympathetic and let people try out the great new features as easily as possible. I think the answer though is doc that it needs a supporting shim and once we switch to the kata-containers |
@stevenhorsman the e2e failure looks unrelated |
I guess it is might be due to the problem fixed in #1651 ? |
|
So when testing this - as soon as I add the
If I remove that annotation then the pod starts fine, but unfortunately with the instant shut-down I'm not sure how to debug what is going wrong with the system.
I don't want to hold this up, so we can merge it based on the code (as long as the libvirt e2e regression tests pass, which hopefully they should after a rebase), but I'm not sure if anyone other than Pradipta, with a similarly hacked version has it working, so I that until we have an e2e test there is a big caveat over this feature (which isn't reflective of Pradipta's code, just that we are in an unstable state with the operator, peer-pods and kata-agent at the moment until everything can switch to |
We'll be in a state of flux for sometime. I feel as long as existing tests passes without adding a policy and also the default policy is to allow everything, we can continue working on the shim side. |
This commit adds the required configurations for policy support in podvm based on OPA. The default policy is to allow all APIs. There are additional policy files included - disable exec api - allow only setpolicy api Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
The following makefile options are added - AGENT_POLICY option for building the kata-agent with policy support. This is enabled by default - DEFAULT_AGENT_POLICY_FILE option to specify the policy file to be used as default. The default policy file is allow-all.rego Additionally the OPA binary is built from source since binaries for s390x is not available Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
SetPolicy allows setting per-pod policy via annotations. This commit adds support for the same in cloud-api-adaptor The policy needs to be base64 encoded and provided as an annotation. Example ``` ... annotations: io.containerd.cri.runtime-handler: kata-remote io.katacontainers.config.agent.policy: <base64_rego_policy> ... ``` Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
update unit test code to include SetPolicy Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
This commit just enables the kata-opa service Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
Provide details on policy configuration using OPA Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
Agent policy file can be specified as part of containerised builds. The build arg is DEFAULT_AGENT_POLICY_FILE and it takes a policy file name kept under podvm/files/etc/kata-opa Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
Agent policy file can be specified as part of containerised builds. The build arg is DEFAULT_AGENT_POLICY_FILE and it takes a policy file name kept under podvm/files/etc/kata-opa Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
We're getting a failure in the kcli setup:
I tried re-queuing it a few times last night and still got it and we saw it in the nightly run this morning: https://github.com/confidential-containers/cloud-api-adaptor/actions/runs/7456619508/job/20288166316. I had a quick look at https://github.com/karmab/kcli/blame/main/kvirt/common/__init__.py#L2107 and the code doesn't seem to have changed recently, but we'll need to dig in a bit more. I'll raise a separate issue for this though... #1655 - issue raised |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks okay to me. I wasn't able to get it working myself, but we aren't in a very stable state wrt supported shim versions. Based on the discussions we've had about this being 'experimental'/'WIP', we'll need to do more work on this once we are using the main
branch of the agent and shim e.g. adding e2e tests for the feature. However it doesn't impact the current e2e CI I think we can merge it to not block progress on this. Thanks for your patience and the updates Pradipta!
592c646
into
confidential-containers:main
This series add policy support to peer-pods.
Only packer built podvm images will work for now. A follow on commit will enable addition ofopa
and related deps via mkosi build