[POC] restrict images at the kubelet #10114
Conversation
|
Oh, and builds are the red-headed step children. You'd have to update the build code to perform a similar check, though if we did this it would be non-contentious. |
|
I've got an alternate admission controller I'd like to use instead.
We can talk on Monday.
|
So do I, but I think it takes two. I'd like to see this restriction in 1.3. See #10116 for where I ended up. |
|
I have a general purpose solution for image admission into pods on the
cluster that covers all the use cases described.
|
|
#8995 adds a lot of API and policy to this. You want to deal with a that right now or should we enable a very simple, zero config option now and add a full thought out policy based on later? |
|
I want to go through and strip out / comment our anything we don't
need now, but get the basic resolution, lookup, and match rules sorted
out. Forcing resolution is pretty important, but I'm not sure yet
whether it should be bypassable by admins. Ultimately we need to have
this control, and next steps are just going to add to it (i.e. we both
attacked the same problem, signatures will be a next step, and license
/ placement is just the natural next step).
|
|
If you're willing to cut deeply into your existing pull, I think we could make that work. I really like the idea of having an ootb annotation that will mostly do what an admin needs. I'm less sure of rushing through a bypass mechanism, because I think it's closely tied to PSP and carrying patches in that area has been painful for us in the past. |
|
Yeah I'm not sure about bypass but I want to be really careful. Ops |
Demonstrates a kubelet patch that could be used to restrict images stored in the openshift API with
"images.openshift.io/deny-execution" = "true". The kubelet could hold an LRU of images. The biggest downside is carrying a kubelet patch, though I'd expect a webhook of some kind here eventually.@smarterclayton