-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Allow-List of supported k8s kinds should be used only when applying labels #4489
Comments
Our current approach is very indiscriminate: for the allowed resources, we change every occurrence of There are also cases where we munged immutable fields (#3219, #3133). |
We can make the allowlist extensible by specifying G(V)Ks in the But perhaps rather than just listing G(V)Ks, what if we also allowed specifying a JSONPath-like syntax for identifying the specific fields to be rewritten? This is really only important for images for CRDs that may specify images by some other field name. (Assuming that we shouldn't be munging labels everywhere). |
If we were to not use the allow-list for replacing
|
Our I'd just like to have some knobs for users to tweak in case we're wrong. Maybe a configurable blocklist would be sufficient? |
For me, a possible knob is just changing image names. |
wdyt? |
We have to consider the |
For labels, we could keep the allow list until we find better. The idea is to stop using that list to apply image names and collect namespaces. |
If we can do a configurable group-kind block-list — so that users can unbreak themselves — I'm good with it. |
The
imageReplacer
's role is to replace image names in k8s yaml by fully qualified names. It does that by visiting the k8s resources, looking forimage
fields and replacing image names that it has a fully qualified name for.Since #3833, we have an Allow-List that specifies which resource kinds can be transformed and we lost the possibility to replace
image
fields in any random Custom Resource. This was mainly introduced to stop applying labels to resources that had ametadata
field but didn't supportmetadata/labels
.I think we went to far with that Allow-List and that it should apply only when we set labels on resources. (Which by the way we might stop doing)
Another case that we have broken is that we collect namespaces only on resources whose kind is in the Allow-List.
The text was updated successfully, but these errors were encountered: