Questions (add to docs?)

[andrewbaxter]

Hello! This looks really cool! It's terrible that HNC died, so I'm really happy to find a replacement.

I read through the docs but there were some gaps that would be really helpful to fill:

• How do you create a role that can create sub-namespaces? The RBAC section mentions the problem, but doesn't show the solution
• How do you create a sub-namespace? All I can find is the readme example which uses a custom CLI, but what if you want to do it via k8s apis?
• The documentation claims SubNamespace is deprecated. Is this correct? I assumed that was the answer to the previous question, but if it is deprecated what are you supposed to use instead? (quote: SubNamespace is the Schema for the subnamespaces API Deprecated: This type will be removed in one of the next releases.)
• Also, how secure is this? Or specifically, how is security handled? Does it use existing k8s mechanisms for security, or is security enforced by the controller itself? Maybe describing how it manages the namespaces itself would help.

Getting started only has installation notes. Usage only has specific actions, not the general usage.

A full example showing creating a namespace, a role, and a sub-namespace using the role with full YAML would be extremely helpful.

[erikgb]

Hey @andrewbaxter, and thanks for your interest in Accurate! We use it at scale in our clusters, and I would be happy to answer any questions you might have. 😸 If you can submit PRs to update our docs, that would be super helpful!

• How do you create a role that can create sub-namespaces? The RBAC section mentions the problem, but doesn't show the solution

It is pretty straightforward. We grant RBAC to manage subnamespaces to the Kubernetes user-facing aggregated cluster roles, which is also supported by the Helm chart installation:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
  name: accurate-subnamespace-editor-role
rules:
- apiGroups:
  - accurate.cybozu.com
  resources:
  - subnamespaces
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - accurate.cybozu.com
  resources:
  - subnamespaces/status
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: accurate-subnamespace-viewer-role
rules:
- apiGroups:
  - accurate.cybozu.com
  resources:
  - subnamespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - accurate.cybozu.com
  resources:
  - subnamespaces/status
  verbs:
  - get

• How do you create a sub-namespace? All I can find is the readme example which uses a custom CLI, but what if you want to do it via k8s apis?

As you would with any other Kubernetes resource:

kubectl apply -f - <<EOF
apiVersion: accurate.cybozu.com/v2
kind: SubNamespace
metadata:
  name: my-sub-namespace
  namespace: my-parent-namespace
EOF

• The documentation claims SubNamespace is deprecated. Is this correct? I assumed that was the answer to the previous question, but if it is deprecated what are you supposed to use instead? (quote: SubNamespace is the Schema for the subnamespaces API Deprecated: This type will be removed in one of the next releases.)

This is a bug in the documentation. The v1 (and v2alpha1) versions of the API are deprecated and will be removed. So please use v2 of the SubNamespace API. Related: #228

• Also, how secure is this? Or specifically, how is security handled? Does it use existing k8s mechanisms for security, or is security enforced by the controller itself? Maybe describing how it manages the namespaces itself would help.

This is not a simple question to answer. The controller is granted the additional RBAC that you decide to allow propagation of resources. Sub-namespace annotations/labels have to be allow-listed (we use this a lot). I would also advise you to configure a regex for sub-namespace naming. In that way, the cluster becomes kinda sharded - based on the tenant root namespace name.

Getting started only has installation notes. Usage only has specific actions, not the general usage.

There is some usage documentation, but as always, the documentation can be improved. 😆

A full example showing creating a namespace, a role, and a sub-namespace using the role with full YAML would be extremely helpful.

Yes, agreed.

[erikgb]

Compared to HNC, Accurate is an opt-in, while HNC was an opt-out. We tried to adopt HNC back in the days, but it attempted to "take over" our cluster.

Okay sorry, if I can bug you a bit more. IIUC those roles allow the principal to do subnamespace operations anywhere, but is it possible to make a role for a namespace, that allows it to only create subnamespaces within its own namespace? Maybe this is where my mental model wasn't matching and confusing me. Or is that what you were getting at with the regex thing? (Do you have an example of regexes?

For the RBAC, you can always create normal namespaced roles, equivalent to the aggregating cluster role above. But it's a lot more convenient to use the user-facing roles IMO.

We use the following naming polices, as an example:

root: ^(?P<root>.*)
match: ^${root}-.*

This means that when we grant a root namespace to a tenant in namespace team-a, all their subnamespaces must start with team-a-. Examples: team-a-foo and team-a-bar. But as a cluster admin, you can decide this.

What we want to do is make a namespace where a team can fully self manage (including creating subnamespaces). Are the subnamespace functionalities here more strictly about hierarchical resource propagation?

You decide which resources you want to support namespace propagation for. So yes, it's a lot more restrictive than HNC.

[andrewbaxter]

Ah! Okay, got it. I was expecting it to be a custom role resource or something, but that's configuration located centrally on the controller using the namingPolicies property.

So security is done in two ways:

• Subnamespace management is limited by name regexes (parent name, child name)
• Resource access is limited by resource propagation (e.g. secrets)

Thanks!

[andrewbaxter]

Hey sorry, I think I'm still not entirely getting it - I feel like I'm missing something simple. So re: roles, let's say a team has a service they're running in namespace A and they create subnamespace B. They want to run a deployment in B.

How can this be done? IIUC

• ClusterRole, ClusterBinding - they could run the deployment in B or in any other namespace (bad)
• ClusterRole, Binding - the binding only applies to A, so they can't do anything in B. Or if the admin creates it in B, then it can't be bound to the service account in A
• Role, Binding - same

Using replication, the service could make a deployment in A, which would be copied into B... but we don't want two copies of the deployment running. Maybe templates could be used, but I think that has the same issue. And if the team wanted to do stuff like check pod status (i.e. non resource-create actions) I'm not sure how that could be done.

Is the only cross-namespace action the service in A can do is create subnamespaces?

[erikgb]

Now I've lost you. 😆 Why do you want to replicate a service? We typically use propagation to fix cross-cutting concerns. Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tenant-editors
  namespace: foo
  annotations:
    accurate.cybozu.com/propagate: update
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
  - kind: Group
    name: team-foo

This role binding will ensure all users in the team-foo group have access to the whole foo namespace hierarchy.

And the same goes for GitOps service accounts and role bindings. If you omit the namespace from the service account role binding subject, you will use the SA in the same namespace as the role binding.

[andrewbaxter]

No, that's perfect, thanks! I was just getting confused about how to do stuff.

So basically:

1. Admin creates a namespace
2. Admin gives tenant service account to do anything in that namespace
3. Tenant creates a subnamespace
4. Tenant creates a role + role binding, propagated into subnamespace. Subnamespace binding binds cross-namespace to their service account
5. Tenant can then launch deployments or whatever into the subnamespace

IIUC you end up with a useless role/binding in the root tenant namespace which is kind of unintuitive, but that seems simple enough

Edit: I guess for the typical use case you'd just use a clusterrole and the admin would add the propagate label to their role binding, so the tenant wouldn't need to do anything to get subnamespace access. So idiomatic usage would probably be:

1. Admin creates a namespace
2. Admin creates tenant service account, clusterrole for admin access, role binding for service account in tenant namespace w/ propagate label
3. Tenant creates a subnamespace
4. Tenant can launch deployments into the subnamespace