Getting Started with Namespace Provisioning

This guide will walk you through the standard process of provisioning a new, secure, and GitOps-ready Kubernetes namespace using the Namespace Provisioning service.

The service works by having you create a single custom resource called a ProjectBootstrap. This resource acts as a request to the platform's Namespace Operator, which then uses a pre-defined template (BootstrapConfig) to automatically perform all the complex setup tasks.

By the end of this guide, you will have created a new namespace with secure network policies, resource quotas, and GitOps integration already configured, simply by defining a single YAML file.

The Goal: From One File to a Complete Namespace

The power of this service is in its simplicity. You will define a single ProjectBootstrap manifest in your GitOps repository, and the operator will handle the rest.

Step 1: Define Your ProjectBootstrap Manifest

The core of the process is the ProjectBootstrap manifest. For most use cases, you will simply reference a pre-existing, shared BootstrapConfig (like default) and specify the details for your new project.

Create the following file in your GitOps repository. This manifest must be placed in a path that is already being reconciled by Flux (e.g., in a clusters/<cluster-name>/ directory).

# my-new-project.yaml
apiVersion: project.tcs.trifork.com/v1alpha1
kind: ProjectBootstrap
metadata:
  # The name of the bootstrap request itself
  name: my-awesome-app
  # This resource must be placed in the GitOps management namespace
  namespace: netic-gitops-system
spec:
  # This will be the name of the new namespace created for your application
  namespace: my-awesome-app

  # This section references a pre-defined template for namespaces
  config:
    # 'default' is the standard, recommended template
    ref: default
    # 'default' is the standard size for resource quotas
    size: default

  # This section configures the new GitOps source for your namespace
  git:
    branch: main
    # This is the path inside your Git repo where the manifests for this new
    # namespace will be located.
    path: ./apps/my-awesome-app

Step 2: Commit and Push

Commit this new ProjectBootstrap manifest to your GitOps repository and push the change.

What Happens Next?

Once Flux syncs this new resource to the cluster, the Namespace Operator will detect it and begin the automated provisioning process. It will perform the following actions:

1. Create the Namespace: A new namespace named my-awesome-app will be created.
2. Apply Security Policies: It will apply default deny-all network policies and other security configurations defined in the default template.
3. Set Resource Quotas: It will create ResourceQuota and LimitRange objects based on the default size to ensure fair resource allocation.
4. Configure GitOps Integration: It will create a new Flux Kustomization resource that tells Flux to start watching and reconciling the manifests located at the ./apps/my-awesome-app path in your repository.
5. Set Up Secrets Integration: It will configure the necessary resources to allow your new namespace to use the External Secrets service.
6. Configure Access Control: It will create the default roles and role bindings for your team.

After a few moments, you can verify that the new namespace exists and is ready for you to start adding your application's manifests into its designated GitOps path (./apps/my-awesome-app).

Customizing Your Namespace

While using the default template is the most common use case, the ProjectBootstrap resource allows for extensive customization, such as automatically creating databases or overriding specific network policies.

For a detailed list of all available fields and their functions, please see the ProjectBootstrap CRD Reference.