mirror of
https://github.com/projectcapsule/capsule.git
synced 2026-08-25 16:07:24 +00:00
* Update README.md Proof Read the README.md * Update index.md Proof Read index.md * Update overview.md Proof Read overview.md * Update onboarding.md Proof Read onboarding.md * Update create-namespaces.md Proof Read create-namespaces.md * Update permissions.md Proof Read permissons.md * Update resources-quota-limits.md Proof Read resources-quota-limits.md * Update nodes-pool.md Proof Read nodes-pool.md * Update ingress-classes.md Proof Read ingress-classes.md * Update ingress-hostnames.md Proof Read ingress-hostnames.md * Update storage-classes.md Proof Read storage-classes.md * Update images-registries.md Proof Read images-registries.md * Update custom-resources.md Proof Read custom-resources.md * Update multiple-tenants.md Proof Read multiple-tenants.md * Update README.md Updated the Suggested text * Update README.md Made the correction * Update docs/operator/use-cases/images-registries.md Co-authored-by: Don High <donghigh@yahoo.com> Co-authored-by: Dario Tranchitella <dario@tranchitella.eu>
111 lines
3.4 KiB
Markdown
111 lines
3.4 KiB
Markdown
# Assign multiple tenants to an owner
|
||
In some scenarios, it's likely that a single team is responsible for multiple lines of business. For example, in our sample organization Acme Corp., Alice is responsible for both the Oil and Gas lines of business. It's more likely that Alice requires two different tenants, for example `oil` and `gas` to keep things isolated.
|
||
|
||
By design, the Capsule operator does not permit hierarchy of tenants, since all tenants are at the same levels. However, we can assign the ownership of multiple tenants to the same user or group of users.
|
||
|
||
Bill, the cluster admin, creates multiple tenants having `alice` as owner:
|
||
|
||
```yaml
|
||
apiVersion: capsule.clastix.io/v1alpha1
|
||
kind: Tenant
|
||
metadata:
|
||
name: oil
|
||
spec:
|
||
owner:
|
||
name: alice
|
||
kind: User
|
||
namespaceQuota: 3
|
||
```
|
||
|
||
and
|
||
|
||
```yaml
|
||
apiVersion: capsule.clastix.io/v1alpha1
|
||
kind: Tenant
|
||
metadata:
|
||
name: gas
|
||
spec:
|
||
owner:
|
||
name: alice
|
||
kind: User
|
||
namespaceQuota: 9
|
||
```
|
||
|
||
So that
|
||
|
||
```
|
||
bill@caas# kubectl get tenants
|
||
NAME NAMESPACE QUOTA NAMESPACE COUNT OWNER NAME OWNER KIND NODE SELECTOR AGE
|
||
oil 3 3 alice User 3h
|
||
gas 9 0 alice User 1m
|
||
```
|
||
|
||
Alternatively, the ownership can be assigned to a group called `oil-and-gas`:
|
||
|
||
```yaml
|
||
apiVersion: capsule.clastix.io/v1alpha1
|
||
kind: Tenant
|
||
metadata:
|
||
name: oil
|
||
spec:
|
||
owner:
|
||
name: oil-and-gas
|
||
kind: Group
|
||
namespaceQuota: 3
|
||
```
|
||
|
||
and
|
||
|
||
```yaml
|
||
apiVersion: capsule.clastix.io/v1alpha1
|
||
kind: Tenant
|
||
metadata:
|
||
name: gas
|
||
spec:
|
||
owner:
|
||
name: oil-and-gas
|
||
kind: Group
|
||
namespaceQuota: 9
|
||
```
|
||
|
||
So that
|
||
|
||
```
|
||
bill@caas# kubectl get tenants
|
||
NAME NAMESPACE QUOTA NAMESPACE COUNT OWNER NAME OWNER KIND NODE SELECTOR AGE
|
||
oil 3 3 oil-and-gas Group 3h
|
||
gas 9 0 oil-and-gas Group 1m
|
||
```
|
||
|
||
The two tenants still remain isolated each other in terms of resources assignments, e.g. _ResourceQuota_, _Nodes Pool_, _Storage Calsses_ and _Ingress Classes_, and in terms of governance, e.g. _NetworkPolicies_, _PodSecurityPolicies_, _Trusted Registries_, etc.
|
||
|
||
|
||
When Alice logs in CaaS platform, she has access to all namespaces belonging to both the `oil` and `gas` tenants.
|
||
|
||
```
|
||
alice@caas# kubectl create ns oil-production
|
||
alice@caas# kubectl create ns gas-production
|
||
```
|
||
|
||
When the enforcement of the naming convention with the `--force-tenant-prefix` option, is enabled, the namespaces are automatically assigned to the right tenant by Capsule because the operator does a lookups on the tenant names. If the `--force-tenant-prefix` option, is not set, Alice needs to specify the tenant name as a label `capsule.clastix.io/tenant=<desired_tenant>` in the namespace manifest:
|
||
|
||
```yaml
|
||
cat <<EOF > gas-production-ns.yaml
|
||
kind: Namespace
|
||
apiVersion: v1
|
||
metadata:
|
||
name: gas-production
|
||
labels:
|
||
capsule.clastix.io/tenant: gas
|
||
EOF
|
||
|
||
kubectl create -f gas-production-ns.yaml
|
||
```
|
||
|
||
> If not specified, Capsule will deny with the following message:
|
||
>
|
||
>`Unable to assign namespace to tenant. Please use capsule.clastix.io/tenant label when creating a namespace.`
|
||
|
||
# What’s next
|
||
This end our tour in Capsule use cases. As we improve Capsule, more use cases about multi-tenancy, policy admission control, and cluster governance will be covered in the future. Stay tuned!
|