Skip to content
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

Disable update of "top level" objects #745

Open
mlbiam opened this issue Apr 21, 2023 · 3 comments
Open

Disable update of "top level" objects #745

mlbiam opened this issue Apr 21, 2023 · 3 comments
Labels
question Further information is requested

Comments

@mlbiam
Copy link

mlbiam commented Apr 21, 2023

Question
Is there a way to disable the policy-controller's rewriting of top level objects' image tags to specific digests? For instance if I have the image: docker.io/mlbiam/openuison-operator:0.0.2 in a CronJob, the Pod gets image: index.docker.io/mlbiam/openunison-kubernetes-operator@sha256:a4af44351bfcf7fe1cfd05a9711f560127f6522508f89fd797e64d8a296d2159, which makes sense. The CronJob also gets this image though. Is there a way to disable this behavior?

While I understand that goal of pinning the specific hash, it means that my GitOps controller is no longer the source of truth for my configuration (and could create a "thrashing" scenario where my controller and what is in cluster are constantly out of sync).

@mlbiam mlbiam added the question Further information is requested label Apr 21, 2023
@hectorj2f
Copy link
Collaborator

No. There isn't a way to disable the mutation from a tag to a digest. Using tags is a bad security practice. Your gitOps controller could use a digest with the image version, e.g. ldocker.io/library/golang:1.17.1@sha256:232a180dbcbcfa7250917507f3827d88a9ae89bb1cdd8fe3ac4db7b764ebb25a

@mlbiam
Copy link
Author

mlbiam commented Apr 21, 2023

Using tags is a bad security practice

digests are important because without a signature it's the only way for kubernetes to guarantee that the image being used is trusted. With signature validation it's redundant. I know the image is trusted because it's been validated against the identity used to sign it from the transparency log. If I don't trust that identity, i don't trust the automated process that generates the digest that's put in the manifest. it's redundant.

I get being "secure" by default, but this sort of rigidity is likely to lead to policy enforcement being turned off or being ignored. It's not a great idea to make assumptions for cluster operators without context and without the option to let more advanced users configure exceptions based on their level of risk tolerance. it will lead to a better UX and a more secure environment.

@CodeGlitcher
Copy link

Kinda have the same problem.
We use a few kuberntes operators en for some it is not really easy to override every image to the digest.

if the policy controller would have a option:
Juist validate the current digest of the selected tag on a pod start it would be perfect.
Our goal is juist to make sure that the pod we start is the pod we signed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants