feat(profile-controller): propagate labels from CR to namespace

[droctothorpe]

Resolves #7480.

We noticed that there were no tests for the Reconcile function in profile_controller_test.go, otherwise we would have extended those tests to validate this specific scenario, even though it's just one line of code with very limited impact. We'd potentially be open, bandwidth permitting, to contributing broader tests for Reconcile down the road.

Confirmed working E2E on our clusters. Labels applied to profile CRs are propagated to the corresponding namespaces.

[google-cla]

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.

[google-oss-prow]

[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.

Needs approval from an approver in each of these files:

• components/profile-controller/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[droctothorpe]

@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.

[droctothorpe]

Bump.

[thesuperzapper]

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

/hold

[thesuperzapper]

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).

[droctothorpe]

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)?