search

kubernetes-sigs / security-profiles-operator

The Kubernetes Security Profiles Operator
Apache License 2.0
667 stars 100 forks source link

Question: Distributing policies with images? #2286

Open imjasonh opened 1 month ago

imjasonh commented 1 month ago

First of all, great project, love it. I built a similar proof of concept in https://github.com/imjasonh/seccomp-profile which I can now archive and point to this much better replacement 🎉

One thing we'd thought of while building that project, that I would be curious to get your thoughts on, is being able to distribute policies alongside/inside container images, in addition to as CRDs.

The general idea is that either at build time, or shortly after in some e2e testing phase, some policy could be generated and attached to the image, and distributed alongside it into the cluster.

The policy could either be attached post-hoc using something like a Sigstore signed attestation, or even just embedded in the image annotations or config (they're plenty small). There are benefits and disadvantages to both, but neither would be too hard to implement I think.

Practically speaking I'd thought of implementing this as a mutating webhook that gets notified when a Deployment/etc is created, finds the images being used, extracts the policies and creates Policy resources which are enforced on the Pod resources being created. The CRD itself could be an implementation detail at that point.

What do you think? In theory this could be implemented as a layer on top of this project, using the CRDs implemented here, but it seems like it could be useful to integrate it from the start.

saschagrunert commented 1 month ago

Thank you for the input @imjasonh!

I'm wondering if we already can fulfill the outlined use case using:

Applying seccomp profiles (plain JSON) directly from pod or image annotations is something CRI-O has now support for: https://kubernetes.io/blog/2024/03/07/cri-o-seccomp-oci-artifacts/

I'm wondering if a feature like this would be a good fit for the operator to be runtime independent. :thinking:

ccojocar commented 1 month ago

Interesting idea, I am thinking we can build on to of the existing features to achieve something similar. We can extend the ProfileBindings with OCI Artifact based profile support.

In this case the profile will be distributed in a different image but for example if a POD uses the nginx image which has an associated profile image in a separate OCI Artifact, the profile binding can automatically distribute that profile to all the nodes. The profile can be referenced from the start in the deployment, maybe we can build some validation.

saschagrunert commented 4 weeks ago

Extending the binding sounds like a good feature to me, but that's not exactly matching the point of "in addition to as CRDs". @imjasonh would that feature be helpful?

ccojocar commented 3 weeks ago

Extending the binding sounds like a good feature to me, but that's not exactly matching the point of "in addition to as CRDs".

I think the point is that the profile will be distributed via the OCI image instead of being installed in a CR. It's true that this will require a CR for ProfileBinding to bind the profile to a container image.

This seems a bit more involved than having the profile directly into the container image but I believe has some benefits. It provides some separation of concerns. I can image a use case when the same container image can have two different profiles, maybe one profile a bit more permissive, this approach will make it easy to swap these two profiles whenever is needed without creating a new image (or dedicated images for each profile).