Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign thesuperzapper for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

@thesuperzapper per the WG meeting, let me know if you think it makes more sense to add something like namespaceLabels to the profile CR spec. We tested to confirm that, at present, no labels are applied to profile CRs. The main advantage of this approach is that it's a much smaller lift since it doesn't require updating the CRD, but easy doesn't necessarily mean right.

Bump.

I think this PR is a security issue for many users, holding for review.

/hold

I am really not sure how (or even if) we can do this safely without causing the following issues:

1. We can't replicate the labels from the profile resource, because this will break GitOps apps like ArgoCD (which use labels to track resources)
2. We can't add a new spec.namespaceLabels to the Profile CRD, because that might be a security risk, and allow users to arbitrarily label Namespaces to avoid some restrictions. (But I am more open to be convinced on this one).

Thanks, @thesuperzapper. Regarding (1), could I trouble you to clarify your concerns with the first option? Is the concern that if profiles are created used ArgoCD, the labels will be propagated to the namespace? Why would that be a problem? Regarding (2), in our use case, end users don't have permission to edit namespaces or profiles directly. It's hard to imagine a scenario where namespace CRUD access would be disabled but profile CRUD access would be enabled, except via the UI as a privileged service. In addition, what if we contributed this feature but disabled it by default and made it contingent on a specific env var being set (that can be configured via the chart)?