Implement rename org

[ybykov-a9s]

Summary

This PR completes the org rename fix and hardens metadata protection across Korifi objects described in this Issue

It includes three parts:

• Fix org rename handling for PATCH requests.
• Keep Danail’s context-aware repository validation for metadata patching.
• Add label-signing and a validating webhook to protect Korifi-managed labels at the Kubernetes API level.

What changed

• Fixed org rename issues in the API patch flow.
• Kept metadata patch validation in repositories, where the code can compare incoming values with the current object and allow unchanged echoed metadata.
• Extended that repository-side validation/error propagation to other metadata patch paths.
• Added label signing for Korifi-managed labels.
• Added a validating webhook that rejects tampering with internal korifi.cloudfoundry.org/* labels and rejects non-Korifi *.cloudfoundry.org label keys.
• Added migration/backfill support and Helm wiring for the label-signing secret.
• Updated repository, webhook, e2e, and smoke coverage accordingly.

Why repository-side validation should co-exist with the webhook solution

Both solutions protect different layers and should both remain in place.

Repository-side validation is still needed because:

• it gives the correct behavior for requests coming through the Korifi API
• it has object context, so it can distinguish between “client echoed existing metadata back unchanged” and “client is trying to modify protected metadata”
• it returns proper Korifi API errors from the handler/repository flow

The webhook solution is also needed because:

• repository validation only runs for requests that go through the Korifi API
• it does not protect direct writes to Korifi CRDs through the Kubernetes API
• the validating webhook blocks those direct mutations at admission time

In short:

• repository validation protects the Korifi API path
• webhooks protect the Kubernetes API path

Together they provide correct API semantics and cluster-level enforcement.

Testing

• Added/updated repository tests for invalid metadata patch handling
• Added validating webhook integration tests
• Added e2e and smoke coverage for protected labels

[danail-branekov]

I did not have the time to look in the change throughly, but it is great that you managed to implement a webhook validation.

I have two major comments:

• Computing the labels signature requires a secret which might be awkward with regards to lifecycle management
• If we manage to propagate the webhook error to the cli (see comments), then repositories should not explicitly need to validate the metadata patch (that would make repositories even simpler)

[danail-branekov]

I wonder whether using hmac signature with a secret is an overkill. Would it not be sufficient to sha256sum the reserved keys map? Then we would not need a secret that is seeded on helm install

[danail-branekov]

Provided that in korifi we have a concept of returning webhook errors to the cli, see this example, I wonder could we not do the same here? Then, if the error from the webhook is propagated to the cli, then we would not need to validate the metadata patch in the repositories. This would significantly reduce the amount of changes, and all the metadata patch validation tests in the api would become redundand