Skip to content

Implement rename org#4341

Open
ybykov-a9s wants to merge 3 commits intocloudfoundry:mainfrom
ybykov-a9s:implement-rename-org
Open

Implement rename org#4341
ybykov-a9s wants to merge 3 commits intocloudfoundry:mainfrom
ybykov-a9s:implement-rename-org

Conversation

@ybykov-a9s
Copy link
Copy Markdown
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants