HNS and crossplane provider-kubernetes is not compatible

[btwseeu78]

Hi All,

it seems there is issues if we use crossplane provider kuberntes together.I dont think its bug as per hns or how it works its fine but crossplane is used in our environment and its rapidly growing, as well as we are really interested using HNS and the plan was to use it via crossplane to give projects better reach but there is issues in it as of now,and i would love some feedback from community. (crossplane creates the roles in all new namespaces for it to use)

how to reproduce:

1. install crossplane and provider-kuberntes
2. Configure provider kuberntes so it can create resources on all namespaces.clb + providerconfig
3. kubectl hns set team-a --parent acme-org ( simply taken from examle)

but if we use kubectl hns create the it works with no problem.as roles are not injected yet.

so for existing namespaces if we want to adopt them part of the tree whats the approach we should take.

[adrianludwin]

Sorry for the delay in getting back to you. Does Crossplane put any labels or annotations on the objects it inserts into your namespaces? If so, we could extend K8s to support crossplane in the same way we supported OpenShift and Rancher. Sadly, this isn't configurable today so we'd need to make a change to HNC. This will allow Crossplane to do its thing without HNC getting in the way.

wdyt?

[adrianludwin]

... we could also make this configurable, it's always been easier not to though until now :/

[btwseeu78]

To be precise its not actually crossplanes doing rather provider-Kubernetes ,its used to create Kubernetes resources that uses cross plane to do that, so for that it auto injects some permissions for all newly created ns so that it can create those resources on behalf. Now the think i'm asking here is ,if there is an old namespace and i want to retain its previous bindings also take what hnc wants to add to it.

i think hnc working smooth as long as the ns are created gradually but its not working that way for already created. im not sure what you guys wnat to do with this open or close i can understand its still new so it would require some time.so you may close this and take it as feedback maybe.as of now its not blocking anything on my prod.so we might have some time

[adrianludwin]

I'm afraid I don't really know anything about Crossplane and don't have time to look into it. I do think the fix would be fairly easy if Crossplane (or its K8s provider, I don't know what that means exactly) put an annotation on the the RBAC rolebindings. Do you know if this is true? If so, it's a one-line change to fix this in the next version of HNC.

[btwseeu78]

Crossplane does put labels on the roles injected by it.

[btwseeu78]

This is the repo for crossplane provider-kuberntes:

https://github.com/crossplane-contrib/provider-kubernetes

just for information

[btwseeu78]

its because of this config on provider : https://github.com/crossplane-contrib/provider-kubernetes/blob/main/examples/provider/config-in-cluster.yaml.

i am exactly not sure if i am explaining the problem clearly. my question was if the NS already exists ,with some roles in it. is it possible to add it to the hnc tree,as sub namespace or as parent.(it should be because that why HNC is supposed to be used for this im i understand properly).

so my idea is HNC does not want to modify the roles as its managed by some other manager.(here we have crossplane-rbac-manager)

what hierarchy addition does actually to a ns is it juts adds some labels and annotations to justify depth ,parent child or there is some more stuff happening , if the roles are propagating then it should be append .I plan to dig out some more this weekend. If this is not satisfactory please let me know for info.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.