Could not update the hierarchical configuration - on Openshift

[arturobrzut]

Environment Openshift 4.8
HNC v0.9.0

Hi
I install HNC on Openshift cluster 4.8
And I have such issue:

kubectl create namespace my-parent
namespace/my-parent created

kubectl hns create -n my-parent my-child1   
Successfully created "my-child1" subnamespace anchor in "my-parent" namespace

kubectl create namespace my-child2
namespace/my-child2 created

kubectl hns set my-child2 --parent my-parent
Setting the parent of my-child2 to my-parent

Could not update the hierarchical configuration of my-child2.
Reason: admission webhook "hierarchyconfigurations.hnc.x-k8s.io" denied the request: Cannot update hierarchy because it would overwrite the following object(s):
  * Namespace "my-child2": system:image-pullers (rbac.authorization.k8s.io/v1, Kind=RoleBinding)
  * Namespace "my-child2": system:image-builders (rbac.authorization.k8s.io/v1, Kind=RoleBinding)
  * Namespace "my-child2": system:deployers (rbac.authorization.k8s.io/v1, Kind=RoleBinding)
To fix this, please rename or remove the conflicting objects first.

Can we turn off checking some OCP resource in HNC?

[adrianludwin]

Are you able to add annotations to the RBAC role bindings? If so, you can use exceptions <https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/master/docs/user-guide/how-to.md#use-limit-propagation> to disable annotations for them. Otherwise, is there a systematic way to identify which objects *shouldn't* be propagated, like a name or a label? If so, we could add all the necessary OpenShift information here <https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/082779afa4b5bdd6c9231906f3639f41d79a6999/internal/selectors/selectors.go#L161> for the next version of HNC.

…

On Tue, Feb 1, 2022 at 4:03 AM Artur Obrzut ***@***.***> wrote: Environment Openshift 4.8 HNC v0.9.0 Hi I install HNC on Openshift cluster 4.8 And I have such issue: kubectl create namespace my-parent namespace/my-parent created kubectl hns create -n my-parent my-child1 Successfully created "my-child1" subnamespace anchor in "my-parent" namespace kubectl create namespace my-child2 namespace/my-child2 created kubectl hns set my-child2 --parent my-parent Setting the parent of my-child2 to my-parent Could not update the hierarchical configuration of my-child2. Reason: admission webhook "hierarchyconfigurations.hnc.x-k8s.io" denied the request: Cannot update hierarchy because it would overwrite the following object(s): * Namespace "my-child2": system:image-pullers (rbac.authorization.k8s.io/v1, Kind=RoleBinding) * Namespace "my-child2": system:image-builders (rbac.authorization.k8s.io/v1, Kind=RoleBinding) * Namespace "my-child2": system:deployers (rbac.authorization.k8s.io/v1, Kind=RoleBinding) To fix this, please rename or remove the conflicting objects first. Can we turn off checking some OCP resource in HNC? — Reply to this email directly, view it on GitHub <#140>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE43PZCN63JT7ZT2MOY6YPTUY6OWDANCNFSM5NIRBU4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[arturobrzut]

@adrianludwin
It works when I add annotations in parent namespace resources

but I want to add PR which exclude this 3 RoleBinding
I will prepare it

[adrianludwin]

What's the criteria you'll use to exclude these? Is it a well-known label? If so, please include documentation here: https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/master/docs/user-guide/concepts.md#built-in-exceptions Thanks!

…

On Tue, Feb 1, 2022 at 10:39 AM Artur Obrzut ***@***.***> wrote: @adrianludwin <https://github.com/adrianludwin> It works when I add annotations in parent namespace resources but I want to add PR which exclude this 3 RoleBinding I will prepare it — Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE43PZDDGSJZEVR5YLZJLODUY75BVANCNFSM5NIRBU4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[arturobrzut]

Ok I will describe it in doc

https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/master/docs/user-guide/concepts.md#built-in-exceptions

these 3 RoleBindings are always created by Openshift

[erikgb]

Could it make sense to skip all "system" roles (system:.*) by default? Or would that be too generic?

[adrianludwin]

This might be the right time to turn this into a CLI since this list keeps getting longer. e.g.: --exclude-propagation-by-name="group/version:Kind:nameregex" --exclude-propagation-by-label="labelkey:labelvalue"

…

On Tue, Feb 1, 2022 at 11:19 AM Erik Godding Boye ***@***.***> wrote: Could it make sense to skip all "system" roles (system:.*) by default? Or would that be too generic? — Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE43PZHD27DOHHFNTLXEWULUZABZDANCNFSM5NIRBU4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[arturobrzut]

and now maybe exclude by annotations
e.g.
if openshift annotation exists with any value - do not propagate
Annotations: openshift.io/description:

[erikgb]

As already suggested above, I think it would make more sense to exclude HNC propagation of roles/rolebindings with names that have a system: prefix. And not do something tailored for Openshift to resolve this issue. IMO the Kubernetes documentation could be used to support this point of view: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings. The note addresses clusterroles/clusterrolebindings, but I think it could be argued that the same principle should/could be applied to roles/rolebindings in HNC.

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

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

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

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:

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

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

/close

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.