Create a Tenant

Bill, a cluster admin, has been tasked by the CTO of Nordmart to set up a new tenant for Anna's team. Following the request, Bill proceeds to create a new tenant named bluesky in the Kubernetes cluster.

Setting Up the Tenant

To establish the tenant, Bill crafts a Tenant Custom Resource (CR) with the necessary specifications:

kubectl create -f - << EOF
apiVersion: tenantoperator.stakater.com/v1beta3
kind: Tenant
metadata:
  name: bluesky
spec:
  quota: small
  accessControl:
    owners:
      users:
        - anna@aurora.org
    editors:
      users:
        - john@aurora.org
      groups:
        - alpha
  namespaces:
    sandboxes:
      enabled: false
EOF

Note

This basic tenant configuration does not specify storageClasses, ingressClasses, or podPriorityClasses. Due to the deny-by-default security model, tenants will not have access to these cluster resources until explicitly configured. See the Tenant Overview for details on enabling these features.

In this configuration, Bill specifies anna@aurora.org as the owner, giving her full administrative rights over the tenant. The editor role is assigned to john@aurora.org and the group alpha, providing them with editing capabilities within the tenant's scope.

Verifying the Tenant Creation

After creating the tenant, Bill checks its status to confirm it's active and operational:

kubectl get tenants.tenantoperator.stakater.com bluesky
NAME       STATE    AGE
bluesky    Active   3m

This output indicates that the tenant bluesky is successfully created and in an active state.

Checking User Permissions

To ensure the roles and permissions are correctly assigned, Anna logs into the cluster to verify her capabilities:

Namespace Creation:

kubectl auth can-i create namespaces
yes

Anna is confirmed to have the ability to create namespaces within the tenant's scope.

Cluster Resources Access:

kubectl auth can-i get namespaces
no

kubectl auth can-i get persistentvolumes
no

As expected, Anna does not have access to broader cluster resources outside the tenant's confines.

Tenant Resource Access:

kubectl auth can-i get tenants.tenantoperator.stakater.com
no

Access to the Tenant resource itself is also restricted, aligning with the principle of least privilege.

Adding Multiple Owners to a Tenant

Later, if there's a need to grant administrative privileges to another user, such as Anthony, Bill can easily update the tenant's configuration to include multiple owners:

kubectl apply -f - << EOF
apiVersion: tenantoperator.stakater.com/v1beta3
kind: Tenant
metadata:
  name: bluesky
spec:
  quota: small
  accessControl:
    owners:
      users:
        - anna@aurora.org
        - anthony@aurora.org
    editors:
      users:
        - john@aurora.org
      groups:
        - alpha
  namespaces:
    sandboxes:
      enabled: false
EOF

With this update, both Anna and Anthony can administer the tenant bluesky, including the creation of namespaces:

kubectl auth can-i create namespaces
yes

This flexible approach allows Bill to manage tenant access control efficiently, ensuring that the team's operational needs are met while maintaining security and governance standards.