fix: adopt pre-existing namespaces with no owner annotation

[rckr2710]

Problem

The Profile controller rejects a namespace that already exists when its
Profile CR is applied, unless the namespace already has a matching
owner annotation. A namespace created via kubectl create ns (no
annotation at all) was always rejected, even with no other claimant.

Fix

Adopt the namespace when it has no owner annotation yet (nothing has
claimed it), and continue to reject only when it's owned by a different
user. On adoption, also set a controller OwnerReference so the
namespace is garbage-collected with its Profile, matching the behavior
of namespaces this controller creates itself.

Testing

Unit Tests

Added unit tests in profile_controller_test.go covering the following scenarios:

• Adoption of an existing namespace without an owner annotation.
• Verification that an OwnerReference is added during namespace adoption.
• Existing namespace already owned by the same user.
• Existing namespace owned by a different user (Profile reconciliation is rejected).
• Preservation of an existing custom istio-injection label during adoption.

All unit tests pass successfully.

make test

Manual Validation

The changes were verified on a local Kind cluster by:

1. Building the updated Dashboard image.
2. Deploying the custom image.
3. Creating a namespace using:
   kubectl create namespace test-profile
4. Applying a corresponding Profile resource.
5. Verifying that:
   • the existing namespace is successfully adopted;
   • the owner annotation is added;
   • the Profile is set as the controller OwnerReference;
   • default namespace labels are applied;
   • existing custom labels (including istio-injection) are preserved.
6. Verifying that a namespace already owned by another user continues to be rejected.

related: #330
closes: #330

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

Details

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

[thesuperzapper]

This would need significant discussions about the security implications before we can make any changes like this.

It would also likely be classified as a "breaking change" and so only be able to be done on a major version.

Can you share what your motivation was here so we can understand if there is a better solution?

/hold

[vamshirajagiri]

Yes, this is a feature we're looking for because of one of our enterprise onboarding workflows @thesuperzapper

A couple of use cases:

• Pre-provisioned namespaces: In our environment, the platform team creates the namespace first and configures everything (NetworkPolicies, ResourceQuotas, LimitRanges, storage, etc.). Kubeflow is onboarded later, so Profile creation fails simply because the namespace already exists.

• GitOps-managed clusters: Namespaces are created and managed by GitOps/platform automation, not by applications. It would be useful if Kubeflow could integrate with these existing namespaces instead of requiring a new one.

I completely agree that automatically adopting any existing namespace would be a security concern.

Instead, what if adoption was explicitly allowed by an administrator?

For example, only namespaces with a label like:

kubeflow.org/adoption: "true"

would be eligible for adoption.

Label present → Kubeflow can adopt the namespace.

Label absent → Keep the current behavior and reject adoption.

This way, the decision stays with the Kubernetes/Kubeflow administrators, and teams can enable it only for namespaces that are intentionally prepared for Kubeflow. The default behavior remains secure while still supporting enterprise onboarding workflows @rckr2710 , I would help you with the changes.

[thesuperzapper]

Was thinking more about this, and the one of the most serious question this feature opens is:

Could someone with Profile access take over the kube-system namespace, or other critical namespaces?
And how would we prevent this.

[vamshirajagiri]

That's a valid concern, and I agree Profile users should never be able to adopt arbitrary namespaces. My thought was that the decision should be entirely in the hands of the Kubernetes/Kubeflow administrator.

For example, Kubeflow would only consider adopting a namespace if:

• the namespace is explicitly marked as adoptable by an admin (e.g. kubeflow.org/adoption: "true"),
• it isn't already managed by another Profile,
• and the requesting user is authorized for that namespace.

Namespaces like kube-system, argocd, cert-manager, monitoring, etc. would never be labeled as adoptable in the first place, so they would continue to be rejected.

The intention isn't to let users take over existing namespaces, but to support enterprise environments where platform teams pre-provision dedicated namespaces for Kubeflow users and explicitly allow Kubeflow to manage them.

[Copilot]

Pull request overview

Enables the Profile controller to adopt pre-existing, unclaimed namespaces while retaining ownership-conflict protection.

Changes:

• Adds namespace adoption, labels, Istio injection, and controller ownership.
• Adds unit tests for adoption, conflicts, and label preservation.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
profile_controller.go	Implements namespace adoption and ownership handling.
profile_controller_test.go	Tests namespace adoption scenarios.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.