Skip to content
This repository has been archived by the owner on Jun 26, 2023. It is now read-only.

HNC: namespace admin cannot manage hierarchy #1341

Closed
JimBugwadia opened this issue Jan 13, 2021 · 3 comments · Fixed by #1490
Closed

HNC: namespace admin cannot manage hierarchy #1341

JimBugwadia opened this issue Jan 13, 2021 · 3 comments · Fixed by #1490
Milestone

Comments

@JimBugwadia
Copy link
Contributor

I created a namespace test-sm with an admin user nancy:

➜  multitenancy kubectl -n test-sm describe rolebinding
Name:         nancy-admin-binding
Labels:       app.kubernetes.io/managed-by=kyverno
              kyverno.io/generated-by=Namespace--test-sm
              policy.kyverno.io/gr-name=gr-qjljr
              policy.kyverno.io/policy-name=add-ns-access-controls
              policy.kyverno.io/synchronize=enable
Annotations:  kyverno.io/user: nancy
Role:
  Kind:  ClusterRole
  Name:  admin
Subjects:
  Kind  Name   Namespace
  ----  ----   ---------
  User  nancy

I am able to create a subns as a cluster-admin but not as the namespace admin:

➜  multitenancy kubectl create ns test-sm --as nancy
namespace/test-sm created
➜  multitenancy kubectl -n test-sm get rolebinding
NAME                  ROLE                AGE
nancy-admin-binding   ClusterRole/admin   6s
➜  multitenancy kubectl hns create s1 -n test-sm
Successfully created "s1" subnamespace anchor in "test-sm" namespace
➜  multitenancy kubectl hns tree test-sm
test-sm
└── [s] s1

[s] indicates subnamespaces
➜  multitenancy kubectl hns tree test-sm  --as nancy
Error reading hierarchy for test-sm: hierarchyconfigurations.hnc.x-k8s.io "hierarchy" is forbidden: User "nancy" cannot get resource "hierarchyconfigurations" in API group "hnc.x-k8s.io" in the namespace "test-sm"
➜  multitenancy kubectl hns create s2 -n test-sm --as nancy

Could not create subnamespace anchor.
Reason: subnamespaceanchors.hnc.x-k8s.io "s2" is forbidden: User "nancy" cannot create resource "subnamespaceanchors" in API group "hnc.x-k8s.io" in the namespace "test-sm"
@JimBugwadia
Copy link
Contributor Author

JimBugwadia commented Jan 13, 2021

A solution would be to install role aggregation rules that extend the standard admin, edit, and view roles with the appropriate permissions to manage the HNC objects.

This way a user who is assigned the standard RBAC admin role in a namespace can manage the hierarchy object in that namespace.

See: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles

@adrianludwin
Copy link
Contributor

This is weird, the builtin admin role should give you permission to edit any object in any namespace, correct? I thought that was what I saw.

@adrianludwin adrianludwin added this to the hnc-v0.8 milestone Feb 3, 2021
@adrianludwin
Copy link
Contributor

Per discussion on Slack:

The admin ClusterRole will not handle permissions for CRDs automatically. When installing a CRD, you can use role aggregation to extend the cluster role and add permissions for the custom resources.
See: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles

So we need to add a new ClusterRole called something like HNCAdmin, and add the following label to that role:

rbac.authorization.k8s.io/aggregate-to-admin: "true"

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants