Provision developer namespaces in Namespace Provisioner

This topic tells you how to use Namespace Provisioner to provision developer namespaces in Tanzu Application Platform (commonly known as TAP).

Prerequisite

  • The Namespace Provisioner package is installed and reconciled.
  • The registry-credential secret referenced by the supply chain components for pulling and pushing images is added to tap-install and exported to all namespaces.

Example secret creation, exported to all namespaces:

tanzu secret registry add registry-credentials --server REGISTRY-SERVER --username REGISTRY-USERNAME --password REGISTRY-PASSWORD --export-to-all-namespaces --yes --namespace tap-install
Important

Namespace Provisioner creates a secret called registries-credentials in each managed namespace which is a placeholder secret filled indirectly by secretgen-controller with all the registry credentials exported for that managed namespace.

Manage a list of developer namespaces

There are two ways to manage the list of developer namespaces that are managed by Namespace Provisioner.

Using Namespace Provisioner Controller
tap-values.yaml configuration example:
namespace_provisioner:
  controller: true

The imperative way is to create the namespace using kubectl or using other means and label it using the default selector.

  1. Create a namespace using kubectl or any other means

    kubectl create namespace YOUR-NEW-DEVELOPER-NAMESPACE
    
  2. Label your new developer namespace with the default namespace_selector apps.tanzu.vmware.com/tap-ns="".

    kubectl label namespaces YOUR-NEW-DEVELOPER-NAMESPACE apps.tanzu.vmware.com/tap-ns=""
    
  3. Run the following command to verify the default resources have been created in the namespace:

    kubectl get secrets,serviceaccount,rolebinding,pods,workload,configmap,limitrange -n YOUR-NEW-DEVELOPER-NAMESPACE
    

    For example:

    NAME                            TYPE                             DATA   AGE
    secret/app-tls-cert             kubernetes.io/tls                3      19s
    secret/registries-credentials   kubernetes.io/dockerconfigjson   1      26s
    secret/scanner-secret-ref       kubernetes.io/dockerconfigjson   1      20s
    
    NAME                           SECRETS   AGE
    serviceaccount/default         1         4h7m
    serviceaccount/grype-scanner   2         20s
    
    NAME                                                               ROLE                      AGE
    rolebinding.rbac.authorization.k8s.io/default-permit-deliverable   ClusterRole/deliverable   26s
    rolebinding.rbac.authorization.k8s.io/default-permit-workload      ClusterRole/workload      26s
    
    NAME                         DATA   AGE
    configmap/kube-root-ca.crt   1      38h
    
    NAME                            CREATED AT
    limitrange/dev-lr   2023-03-08T04:18:58Z
    
    
Using GitOps
The GitOps approach provides a fully declarative way to create developer namespaces managed by Namespace Provisioner.

tap-values.yaml configuration example:

namespace_provisioner:
  controller: false
  gitops_install:
    ref: origin/main
    subPath: ns-provisioner-samples/gitops-install
    url: https://github.com/vmware-tanzu/application-accelerator-samples.git

This GitOps configuration does the following things:

controller: false - the Namespace Provisioner package does not install the controller. The list of namespaces is managed in a GitOps repository instead.

The gitops-install directory specified as the subPath value includes two files:

If you have another tool like Tanzu Mission Control or some other process that is taking care of creating namespaces for you, and you don’t want a Namespace Provisioner to create the namespaces, you can delete this file from your GitOps install repository.

The tap-values.yaml configuration example above creates the following two namespaces: dev and qa. If these namespaces already exist in your cluster, remove them or rename the namespaces in your GitOps repository so they do not conflict with existing resources.

Run the following command to verify the default resources are created in the namespace:

kubectl get secrets,serviceaccount,rolebinding,pods,workload,configmap,limitrange -n dev

For example:

NAME                            TYPE                             DATA   AGE
secret/app-tls-cert             kubernetes.io/tls                3      52s
secret/registries-credentials   kubernetes.io/dockerconfigjson   1      59s
secret/scanner-secret-ref       kubernetes.io/dockerconfigjson   1      53s

NAME                           SECRETS   AGE
serviceaccount/default         1         59s
serviceaccount/grype-scanner   2         53s

NAME                                                               ROLE                      AGE
rolebinding.rbac.authorization.k8s.io/default-permit-deliverable   ClusterRole/deliverable   59s
rolebinding.rbac.authorization.k8s.io/default-permit-workload      ClusterRole/workload      59s

NAME                         DATA   AGE
configmap/kube-root-ca.crt   1      59s

NAME                CREATED AT
limitrange/dev-lr   2023-03-08T04:22:20Z

For more information, see the GitOps section of Customize Installation of Namespace Provisioner.

Enable additional users with Kubernetes RBAC

Namespace Provisioner does not support enabling additional users with Kubernetes RBAC. Support is planned for an upcoming release. Until Namespace Provisioner support is provided, follow the instructions in Enable additional users with Kubernetes RBAC.

check-circle-line exclamation-circle-line close-line
Scroll to top icon