Skip to content

Namespaces

HNC

Hierarchical Namespace Controller (HNC) is included in Welkin. It allows the Application Developer to manage namespaces as subnamespaces and delegates access automatically. From the perspective of Kubernetes these are regular namespaces, but these can be modified via a namespaced resource by the user. Building a good namespace structure will enable you to apply namespace-scoped RBAC resources to multiple namespaces at once.

Namespace Management

Creating a subnamespace:

kubectl apply -f - <<EOF
apiVersion: hnc.x-k8s.io/v1alpha2
kind: SubnamespaceAnchor
metadata:
  name: <descendant-namespace>
  namespace: <parent-namespace>
EOF

Verify that it gets created:

kubectl get ns <descendant-namespace>

Verify that it gets configured:

$ kubectl get subns -n <parent-namespace> <descendant-namespace> -o yaml
apiVersion: hnc.x-k8s.io/v1alpha2
kind: SubnamespaceAnchor
metadata:
  ...
  name: <descendant-namespace>
  namespace: <parent-namespace>
...
status:
  status: Ok

If the status is Ok then the subnamespace is ready to go.

Tip

HNC also comes with the HNS kubectl plugin.

Using this plugin creating subnamespaces is as easy as: 

kubectl hns create -n <parent-namespace> <descendant-namespace>

And provides more detailed information using: 

kubectl hns describe <namespace>

kubectl hns tree <namespace>

If you decide a subnamespace is no longer needed, then you can't delete it using kubectl delete namespace <descendant-namespace>. As you will get the following error:

Error from server (Forbidden): namespaces <descendant-namespace> is forbidden: User <your user> cannot delete resource "namespaces" in API group "" in the namespace <descendant-namespace>: RBAC: [clusterrole.rbac.authorization.k8s.io "user-crds" not found, clusterrole.rbac.authorization.k8s.io "user-crds-resourcename-limit" not found]

Instead you will have to delete it using either of these commands:

kubectl delete subns -n <parent-namespace> <descendant-namespace>
# or
kubectl hns delete -n <parent-namespace> <descendant-namespace> # with the plugin installed

Resource Propagation

When a subnamespace is created all Roles, RoleBindings and NetworkPolicies will propagate from the parent namespace to the descendant namespace to ensure that correct access is set. This is what lets you apply namespace-scoped RBAC resources to multiple namespaces at once. Propagated copies cannot be modified, these types of resources cannot be created in a parent namespace if it conflicts with a resource in a descendant namespace. To put an exception, annotate the Role, RoleBinding or NetworkPolicy with propagate.hnc.x-k8s.io/none: "true" to prevent it from being propagated at all. Another option is to only propagate to selected descendant namespaces use propagate.hnc.x-k8s.io/treeSelect: ..., include descendant namespaces with <descendant-namespace> or exclude namespaces with !<descendant-namespace>.

Opt-in Propagation

HNC has the option to enable opt-in propagation for additional resources such as Secrets. This allows you to specify additional resources that you want propagated, but only if the object has a valid selector annotation set, while ignoring others. If you want to enable this feature, you can file a service ticket or contact your Platform Administrator with a list of resources that you want it enabled for.

Further Reading