Add your namespaces with HNS
Feature available with Babel 2.1+
Manage your namespaces
Customer's namespaces are managed with the concept of Hierarchical Namespaces. In its simplest form, a hierarchical namespace is a regular Kubernetes namespace that contains a small custom resource that identifies a single, optional, parent namespace. This establishes the concept of ownership across namespaces, not just within them. This concept of ownership enables the policy inheritance: if one namespace is a child of another, policy objects such as RBAC RoleBindings are copied from the parent to the child.
The cluster service owner has permission to create namespace under its own namespaces such as customer-namespaces in your case. The created namespaces wil have the exact same permission has the parent namespace.
Example of customer namespace structure
customer-namespaces
├── namespace-a
├── namespace-b
└── ...
Setup tools
Install hns kubectl plugin
-
Install krew macOS/Linux (Bash or ZSH shells). Reference
- Make sure that git is installed.
- Run this command to download and install krew:
(
set -x; cd "$(mktemp -d)" &&
OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
KREW="krew-${OS}_${ARCH}" &&
curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
tar zxvf "${KREW}.tar.gz" &&
./"${KREW}" install krew
) - Add the
$HOME/.krew/bin directory
to your PATH environment variable. To do this, update your .bashrc or .zshrc file and append the following line:export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"
and restart your shell. - Run kubectl krew to check the installation
-
Install hns plugin with krew
kubectl krew update && kubectl krew install hns
-
Test installation
kubectl hns
Output:
Manipulates hierarchical namespaces provided by HNC
Usage:
kubectl-hns [command]
Available Commands:
completion generate the autocompletion script for the specified shell
[...]
Manage your namespaces
-
Create namespace
kubectl hns create <my-new-namespace> -n customer-namespaces
-
List namespaces
kubectl get ns
Output:
cert-manager Active 6d
default Active 6d1h
[...]Note: All cluster namespaces. No distinction between regular namespace and hierarchical namespace
-
Show namespace structure
kubectl hns tree customer-namespaces
Output:
customer-namespaces
├── namespace-a
├── namespace-b
└── ... -
Detail namespace
kubectl describe ns <my-new-namespace>
Output:
Name: my-new-namespace
Labels: customer-namespaces.tree.hnc.x-k8s.io/depth=1
hnc.x-k8s.io/included-namespace=true
kubernetes.io/metadata.name=my-new-namespace
my-new-namespace.tree.hnc.x-k8s.io/depth=0
Annotations: hnc.x-k8s.io/subnamespace-of: customer-namespaces
Status: Active
No resource quota.
No LimitRange resource.Note: Labels and annotations contain information about the parent's namespace.
-
Delete namespace
kubectl delete subnamespaceanchor <my-namespace-to-delete> -n customer-namespaces
Output:
subnamespaceanchor.hnc.x-k8s.io "my-sub-namespace" deleted
Work with namespace
Use service account
For any subnamespaces of customer-namespaces or customer-namespaces use customer-namespaces
- Download kubeconfig script
- Set
k8saas-service-account-kubeconfig.sh
executable - Retrieve customer-namespaces kubeconfig
k8saas-service-account-kubeconfig.sh customer-namespaces
- Do your operations on customer-namespaces or its child
Some examples
kubectl get secret -n customer-namespaces --kubeconfig <customer-namespaces-sa-kubeconfig-file>
kubectl get pod -n customer-namespaces-child --kubeconfig <customer-namespaces-sa-kubeconfig-file>
...
Known limitations and troubleshooting
Service account permission issue while using child SA in child namespace
Current HNC version propagates SA from parent to child namespace however the secret associated to the SA is not propagated. Using the child SA for operations on cluster returns permission errors.
The workaround is to use the parent SA for all operations on sub-child. Using the parent SA for its child isn't a security concern because HNC is based on the assumption that if you have access to the parent, it's normal to have access to its childs.
In case where you are deploying in a customer-namespaces child a pod using SA permission, the SA in customer-namespaces(parent) is not accessible. Error creating: pods "..." is forbidden: error looking up service account <customer-namespaces child>/k8saas-generic-sa-cicd: serviceaccount "k8saas-generic-sa-cicd" not found
The solution is to create a new SA in the customer-namespaces child and use this new SA inside the deployed pod. Retrieve new SA kubeconfig
k8saas-service-account-kubeconfig.sh <service-account-namespace> <service-account-name>