fix: Added .Values.validatingWebhookExemptNamespacesLabels to the /v1/admitlabel webhook

[Gaardsholt]

What this PR does / why we need it: When running on GKE we get the following error in the console:

[maxsmythe]

Thanks for the PR!

Unfortunately, this change would get clobbered by our auto-gen pipeline as-is. Please see https://open-policy-agent.github.io/gatekeeper/website/docs/help/#contributing-to-helm-chart for more details.

[Gaardsholt]

Thanks for the PR!

Unfortunately, this change would get clobbered by our auto-gen pipeline as-is. Please see https://open-policy-agent.github.io/gatekeeper/website/docs/help/#contributing-to-helm-chart for more details.

@maxsmythe like this then?

[JaydipGabani]

@Gaardsholt you need to modify this and add this there as well. Then run make manifests and push the changes

[Gaardsholt]

Thank you so much for pointing me the the right direction @JaydipGabani !
I think I have made the changes correctly now :)

[JaydipGabani]

LGTM

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (5db70c1) 53.68% compared to head (8e67093) 53.78%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3147      +/-   ##
==========================================
+ Coverage   53.68%   53.78%   +0.10%     
==========================================
  Files         136      136              
  Lines       12198    12198              
==========================================
+ Hits         6548     6561      +13     
+ Misses       5145     5136       -9     
+ Partials      505      501       -4     

Flag	Coverage Δ
unittests	53.78% <ø> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JaydipGabani]

@Gaardsholt please sign the commit to resolve DCO

[Gaardsholt]

@JaydipGabani DCO has been fixed

[maxsmythe]

There is a security hole in modifying the admitLabel webhook like this in the form of a privilege escalation.

The purpose of admitLabel is to make sure the ability to add/remove/edit namespaces is not equivalent to the ability to bypass admission policy. As such, it needs to be evaluated against all namespaces. Essentially this is our way of creating ACLd namespace labels.

If we were to merge this as-is, the effect would be to nullify the purpose of the webhook, since any user with permissions to edit namespaces would be able to modify that namespace's label, bypassing the webhook. At that point, it would be clearer (and more stable), to just remove the admitLabel entirely.

Some users may consider the ability to add/remove/edit namespaces to be a privileged operation, and therefore would be fine with relying on RBAC alone as the security mechanism here. For these users, disabling admitLabel makes sense.

TL;DR we probably just want a switch that makes the admitLabel webhook optional. It would be a more robust and more explicit in its behavior. We should document the security implications of disabling that webhook.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.