search

kubernetes-sigs / security-profiles-operator

The Kubernetes Security Profiles Operator
Apache License 2.0
721 stars 107 forks source link

Question: Distributing policies with images? #2286

Open imjasonh opened 6 months ago

imjasonh commented 6 months 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 6 months 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 6 months 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 6 months 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 5 months 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).

k8s-triage-robot commented 2 months ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 1 month ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

ccojocar commented 1 month ago

/remove-lifecycle roten

k8s-triage-robot commented 4 weeks ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-ci-robot commented 4 weeks ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes-sigs/security-profiles-operator/issues/2286#issuecomment-2459143347): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages issues according to the following rules: >- After 90d of inactivity, `lifecycle/stale` is applied >- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied >- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed > >You can: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
ccojocar commented 3 weeks ago

/remove-lifecycle rotten