Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add documentation about deny-wildcard annotation #433

Merged
merged 2 commits into from
Sep 23, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions docs/operator/use-cases/deny-wildcard-hostnames.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Deny Wildcard Hostnames

Bill, the cluster admin, can deny the use of wildcard hostnames.

Let's assume that we had a big organization, having a domain `bigorg.com` and there are two tenants, `gas` and `oil`.

As a tenant-owner of `gas`, Alice create ingress with the host like `- host: "*.bigorg.com"`. That can lead to big problems for the `oil` tenant because Alice can deliberately create ingress with host: `oil.bigorg.com`.

To avoid this kind of problems, Bill can deny the use of wildcard hostnames in the following way:

```yaml
kubectl apply -f - << EOF
apiVersion: capsule.clastix.io/v1beta1
kind: Tenant
metadata:
name: gas
annotations:
capsule.clastix.io/deny-wildcard: true
spec:
owners:
- name: alice
kind: User
EOF
```

Doing this, Alice will not be able to use `oil.bigorg.com`, being the tenant-owner of `gas`.

# What’s next

This ends 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!
4 changes: 1 addition & 3 deletions docs/operator/use-cases/namespace-labels-and-annotations.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,4 @@ EOF
```

# What’s next
This ends 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!
Let's check it out how to restore Tenants after a Velero Backup. [Velero Backup Restoration](./velero-backup-restoration.md).
1 change: 1 addition & 0 deletions docs/operator/use-cases/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,7 @@ Use Capsule to address any of the following scenarios:
* [Taint Services](./taint-services.md)
* [Allow adding labels and annotations on namespaces](./namespace-labels-and-annotations.md)
* [Velero Backup Restoration](./velero-backup-restoration.md)
* [Deny Wildcard Hostnames](./deny-wildcard-hostnames.md)

> NB: as we improve Capsule, more use cases about multi-tenancy and cluster governance will be covered.

Expand Down
6 changes: 5 additions & 1 deletion docs/operator/use-cases/velero-backup-restoration.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,4 +20,8 @@ Additionally, you can also specify a selected range of tenants to be restored:
./velero-restore.sh --tenant "gas oil" restore
```

In this way, only the tenants **gas** and **oil** will be restored.
In this way, only the tenants **gas** and **oil** will be restored.

# What's next

See how Bill, the cluster admin, can deny wildcard hostnames to a Tenant. [Deny Wildcard Hostnames](./deny-wildcard-hostnames.md)