You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Often when working in multi-tenant environments, you want to ensure that tenants are not using `ClusterIssuers` to issue certificates, but rather use namespaced `Issuers` within their own namespace. This policy enforces that `cert-manager.io/v1/Certificate` resources do not reference `ClusterIssuers` and that the `Issuer` referenced is in the same namespace as the `Certificate`.
755
+
756
+
{{% tabpane lang="yaml" %}}
757
+
{{% tab header="**Engines**:" disabled=true /%}}
758
+
{{< tab header="Kyverno" >}}
759
+
---
760
+
apiVersion: kyverno.io/v1
761
+
kind: ClusterPolicy
762
+
metadata:
763
+
name: certificates-only-local-issuer
764
+
spec:
765
+
validationFailureAction: Enforce
766
+
background: true
767
+
rules:
768
+
- name: deny-clusterissuer-in-certificates
769
+
match:
770
+
any:
771
+
- resources:
772
+
kinds:
773
+
- cert-manager.io/v1/Certificate
774
+
namespaceSelector:
775
+
matchExpressions:
776
+
- key: capsule.clastix.io/tenant
777
+
operator: Exists
778
+
validate:
779
+
message: "Certificates must not reference ClusterIssuers; use a namespaced Issuer in the same namespace."
Deny to usage of ClusterIssuers in Gateways by checking for the `cert-manager.io/cluster-issuer` annotation. This ensures that tenants use namespaced issuer mechanisms instead.
811
+
812
+
This requires extra permissions to allow Kyverno to read Gateway resources:
Copy file name to clipboardExpand all lines: content/en/docs/operating/architecture.md
+28-6Lines changed: 28 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,32 +30,56 @@ In Capsule, we introduce a new persona called the `Tenant Owner`. The goal is to
30
30
31
31
### Capsule Administrators
32
32
33
+
[Configure Capsule Administrators](/docs/operating/setup/configuration/#administrators). The ClusterRoles assigned to Administrators can be configured in the [CapsuleConfiguration](/docs/operating/setup/configuration/#rbac) as well.
34
+
33
35
They are promoted to [Tenant-Owners](#tenant-owners) for all available tenants. Effectively granting them the ability to manage all namespaces within the cluster, across all tenants.
34
36
35
37
**Note**: Granting Capsule Administrator rights should be done with caution, as it provides extensive control over the cluster's multi-tenant environment. **When granting Capsule Administrator rights, the entity gets the privileges to create any namespace (also not part of capsule tenants) and the privileges to delete any tenant namespaces.**
36
38
37
39
Capsule Administrators can:
40
+
38
41
- Create and manage [namespaces via labels in any tenant](/docs/tenants/namespaces/#label).
39
42
- Create namespaces outside of tenants.
40
43
- Delete namespaces in any tenant.
41
44
42
45
Administrators come in handy in bootstrap scenarios or GitOps scenarios where certain users/serviceaccounts need to be able to manage namespaces for all tenants.
Any entity which needs to interact with tenants and their namespaces must be defined as a **Capsule User**. This is where the flexibility of Capsule comes into play. You can define users or groups as Capsule Users, allowing them to create and manage namespaces within any tenant they have access to. If they are not defined as Capsule Users, any interactions will be ignored by Capsule. Often a best practice is to define a single group which identifies all your tenant users. This way you can have one generic group for all your users and then use additional groups to separate responsibilities (e.g. administrators vs normal users).
49
52
50
53
**Only one entry is needed to identify a Capsule User. This is only important for Namespace Admission.**.
You can always verify the effective Capsule Users by checking the Configuration Status. As this is variable with [Tenant Owners](#tenant-owners), the status will always show the effective users:
58
+
59
+
```bash
60
+
kubectl get capsuleconfiguration default -o jsonpath='{.status.users}'| jq
61
+
62
+
[
63
+
{
64
+
"kind": "Group",
65
+
"name": "oidc:kubernetes:admin"
66
+
},
67
+
{
68
+
"kind": "Group",
69
+
"name": "projectcapsule.dev"
70
+
},
71
+
{
72
+
"kind": "User",
73
+
"name": "test-user"
74
+
}
75
+
]
76
+
```
55
77
56
78
### Tenant Owners
57
79
58
-
**Every Tenant Owner must be a [Capsule User](#capsule-users)**
**Every Tenant Owner must be a [Capsule User](#capsule-users). By using the [TenantOwner CRD](/docs/tenants/permissions/#tenant-owners) this is automatically handeled.**
59
83
60
84
61
85
They manage the namespaces within their tenants and perform administrative tasks confined to their tenant boundaries. This delegation allows teams to operate more autonomously while still adhering to organizational policies. Tenant Owners can be used to shift reposnsability of one tenant towards this user group. promoting them to the SPOC of all namespaces within the tenant.
@@ -67,8 +91,6 @@ Tenant Owners can:
67
91
68
92
Capsule provides robust tools to strictly enforce tenant boundaries, ensuring that each tenant operates within its defined limits. This separation of duties promotes both security and efficient resource management.
Let's dicuss different Tenant Layouts which could be used . These are just approaches we have seen, however you might also find a combination of these which fits your use-case.
Copy file name to clipboardExpand all lines: content/en/docs/operating/best-practices/_index.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
---
2
2
title: Best Practices
3
3
weight: 2
4
-
description: Best Practices when running Capsule in production
4
+
description: Best Practices when running Capsule in production
5
5
---
6
6
7
7
@@ -30,7 +30,7 @@ Instead, a centralized secrets management system should be established — such
30
30
To integrate these external secret stores with Kubernetes, the [External Secrets Operator (ESO)](https://external-secrets.io/latest/) is a recommended solution. It automatically syncs defined secrets from external sources as Kubernetes secrets, and supports dynamic rotation, access control, and auditing.
31
31
32
32
If no external secret store is available, there should at least be a secure way to store sensitive data in Git.
33
-
In our ecosystem, we provide a solution based on SOPS (Secrets OPerationS) for this use case.
33
+
In our ecosystem, we provide a solution based on SOPS (Secrets OPerationS) for this use case; called the [sops-operator](https://github.com/peak-scale/sops-operator).
0 commit comments