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
# HELP capsule_tenant_status Tenant cordon state indicating if tenant operations are restricted (1) or allowed (0) for resource creation and modification
Copy file name to clipboardExpand all lines: content/en/docs/operating/setup/configuration.md
+89-15Lines changed: 89 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,57 +7,131 @@ description: >
7
7
8
8
The configuration for the capsule controller is done via it's dedicated configration Custom Resource. You can explain the configuration options and how to use them:
9
9
10
-
11
-
12
10
## CapsuleConfiguration
13
11
14
12
The configuration for Capsule is done via it's dedicated configration Custom Resource. You can explain the configuration options and how to use them:
15
13
16
-
```bash
14
+
```shell
17
15
kubectl explain capsuleConfiguration.spec
18
16
```
19
17
20
-
### enableTLSReconciler
18
+
### `enableTLSReconciler`
21
19
Toggles the TLS reconciler, the controller that is able to generate CA and certificates for the webhooks when not using an already provided CA and certificate, or when these are managed externally with Vault, or cert-manager.
22
20
23
-
### forceTenantPrefix
21
+
```yaml
22
+
tls:
23
+
enableController: true
24
+
```
25
+
26
+
### `forceTenantPrefix`
24
27
Enforces the Tenant owner, during Namespace creation, to name it using the selected Tenant name as prefix, separated by a dash. This is useful to avoid Namespace name collision in a public CaaS environment.
25
28
26
-
### nodeMetadata
29
+
```yaml
30
+
manager:
31
+
options:
32
+
forceTenantPrefix: true
33
+
```
34
+
35
+
### `nodeMetadata`
27
36
Allows to set the forbidden metadata for the worker nodes that could be patched by a Tenant. This applies only if the Tenant has an active NodeSelector, and the Owner have right to patch their nodes.
28
37
29
-
### overrides
38
+
```yaml
39
+
manager:
40
+
options:
41
+
nodeMetadata:
42
+
forbiddenLabels:
43
+
denied:
44
+
- "node-role.kubernetes.io/*"
45
+
deniedRegex: ""
46
+
forbiddenAnnotations:
47
+
denied:
48
+
- "node.alpha.kubernetes.io/*"
49
+
deniedRegex: ""
50
+
```
51
+
52
+
[Read More](/docs/tenants/enforcement/#nodes)
53
+
54
+
55
+
### `overrides`
30
56
Allows to set different name rather than the canonical one for the Capsule configuration objects, such as webhook secret or configurations.
31
57
32
-
### protectedNamespaceRegex
58
+
### `protectedNamespaceRegex`
33
59
Disallow creation of namespaces, whose name matches this regexp
Names of the groups for Capsule users. Users must have this group to be considered for the Capsule tenancy. If a user does not have any group mentioned here, they are not recognized as a Capsule user.
37
69
38
-
### userNames
70
+
```yaml
71
+
manager:
72
+
options:
73
+
capsuleUserGroups:
74
+
- system:serviceaccounts:tenants-gitops
75
+
- company:org:users
76
+
```
77
+
78
+
### `userNames`
39
79
Names of the users for Capsule users. Users must have this name to be considered for the Capsule tenancy. If userGroups are set, the properties are ORed, meaning that a user can be recognized as a Capsule user if they have one of the groups or one of the names.
Define groups which when found in the request of a user will be ignored by the Capsule. This might be useful if you have one group where all the users are in, but you want to separate administrators from normal users with additional groups.
43
90
91
+
```yaml
92
+
manager:
93
+
options:
94
+
ignoreUserWithGroups:
95
+
- company:org:administrators
96
+
```
97
+
98
+
### `allowServiceAccountPromotion`
99
+
100
+
ServiceAccounts within tenant namespaces can be promoted to owners of the given tenant this can be achieved by labeling the serviceaccount and then they are considered owners. This can only be done by other owners of the tenant. However ServiceAccounts which have been promoted to owner can not promote further serviceAccounts.
Depending on the version of the Capsule Controller, the configuration options may vary. You can view the options for the latest version of the Capsule Controller or by executing the controller locally:
47
113
48
114
```bash
49
-
$ docker run ghcr.io/projectcapsule/capsule:v0.6.0-rc0 -h
50
-
2024/02/25 13:21:21 maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined
51
-
Usage of /ko-app/capsule:
115
+
$ go run ./cmd/. --zap-log-level 7 -h
116
+
2025/09/13 23:50:30 maxprocs: Leaving GOMAXPROCS=8: CPU quota undefined
117
+
Usage of /var/folders/ts/43yg7sk56ls3r3xjf66npgpm0000gn/T/go-build2624543463/b001/exe/cmd:
52
118
--configuration-name string The CapsuleConfiguration resource name to use (default "default")
53
119
--enable-leader-election Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.
54
120
--metrics-addr string The address the metric endpoint binds to. (default ":8080")
55
121
--version Print the Capsule version and exit
56
122
--webhook-port int The port the webhook server binds to. (default 9443)
57
123
--zap-devel Development Mode defaults(encoder=consoleEncoder,logLevel=Debug,stackTraceLevel=Warn). Production Mode defaults(encoder=jsonEncoder,logLevel=Info,stackTraceLevel=Error)
58
124
--zap-encoder encoder Zap log encoding (one of 'json' or 'console')
59
-
--zap-log-level level Zap Level to configure the verbosity of logging. Can be one of 'debug', 'info', 'error', or any integer value > 0 which corresponds to custom debug levels of increasing verbosity
125
+
--zap-log-level level Zap Level to configure the verbosity of logging. Can be one of 'debug', 'info', 'error', 'panic'or any integer value > 0 which corresponds to custom debug levels of increasing verbosity
60
126
--zap-stacktrace-level level Zap Level at and above which stacktraces are captured (one of 'info', 'error', 'panic').
61
127
--zap-time-encoding time-encoding Zap time encoding (one of 'epoch', 'millis', 'nano', 'iso8601', 'rfc3339' or 'rfc3339nano'). Defaults to 'epoch'.
62
128
```
63
129
130
+
Define additional options in the `values.yaml` when installing via Helm:
Copy file name to clipboardExpand all lines: content/en/docs/operating/setup/installation.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -58,6 +58,12 @@ Perform the following steps to install the capsule Operator:
58
58
59
59
Here are some key considerations to keep in mind when installing Capsule. Also check out the **[Best Practices](/docs/operating/best-practices)** for more information.
60
60
61
+
### Admission Policies
62
+
63
+
While Capsule provides a robust framework for managing multi-tenancy in Kubernetes, it does not include built-in admission policies for enforcing specific security or operational standards for all possible aspects of a Kubernetes cluster. Therefore, it is recommended to use additional tools like [Kyverno](https://kyverno.io/) to enforce admission policies that align with your organization's requirements.
64
+
65
+
[We provide policy recommendations for Kyverno here](/ecosystem/integrations/kyverno/#recommended-policies).
66
+
61
67
### Certificate Management
62
68
63
69
We recommend using [cert-manager](https://cert-manager.io/) to manage the TLS certificates for Capsule. This will ensure that your Capsule installation is secure and that the certificates are automatically renewed. Capsule requires a valid TLS certificate for it's Admission Webserver. By default Capsule reconciles it's own TLS certificate. To use cert-manager, you can set the following values:
You have to add `system:serviceaccounts:{service-account-namespace}` to the CapsuleConfiguration [Group Scope](#group-scope) to make it work.
166
166
167
+
### ServiceAccount Promotion
168
+
169
+
Within a tenant, a ServiceAccount can be promoted to a Tenant Owner. For example, Alice can create a ServiceAccount called robot in the solar tenant and promote it to be a Tenant Owner (This requires Alice to be an owner of the tenant as well):
170
+
171
+
```yaml
172
+
kubectl label sa gitops-reconcile -n green-test owner.projectcapsule.dev/promote=true --as alice --as-group projectcapsule.dev
173
+
```
174
+
175
+
Now the ServiceAccount robot can create namespaces in the solar tenant:
Copy file name to clipboardExpand all lines: content/en/docs/whats-new.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,22 +5,21 @@ description: >
5
5
weight: 1
6
6
---
7
7
8
-
9
8
## Features
10
9
11
-
* includes a new approach to how Resources (ResourceQuotas) should be handled across multiple namespaces. With this release, we are introducing the concept of ResourcePools and ResourcePoolClaims. Essentially, you can now define Resources and the audience (namespaces) that can claim these Resources from a ResourcePool. This introduces a shift-left in resource management, where Tenant Owners themselves are responsible for organizing their resources. Comes with a Queuing-Mechanism already in place. This new feature works with all namespaces — not just exclusive Capsule namespaces. [Read More](/docs/resourcepools/)
12
-
13
-
* Added support for GatewayAPI v1 (Gateway-Class control). [Read More](/docs/tenants/enforcement/#gatewayclasses)
10
+
* Owners can promote ServiceAccounts from their Tenant namespaces to Owners of the Tenant [Read More](/docs/tenants/permissions/#serviceaccount-promotion)
14
11
15
-
- Added a more sophisticated way to control metadata for namespaces within a tenant. This allows you to distribute labels and annotations to namespaces based on more specific conditions. It's now also possible so use simple templating to assign metadata. [Read More](/docs/tenants/enforcement/#namespaces)
12
+
* Reworked Metrics based on improved Tenant state management via Conditions. [Read More](/docs/operating/monitoring/#metrics-1)
16
13
14
+
* Includes a new approach to how Resources (ResourceQuotas) should be handled across multiple namespaces. With this release, we are introducing the concept of ResourcePools and ResourcePoolClaims. Essentially, you can now define Resources and the audience (namespaces) that can claim these Resources from a ResourcePool. This introduces a shift-left in resource management, where Tenant Owners themselves are responsible for organizing their resources. Comes with a Queuing-Mechanism already in place. This new feature works with all namespaces — not just exclusive Capsule namespaces. [Read More](/docs/resourcepools/)
17
15
18
16
## Documentation
19
17
20
18
We have added new documentation for a better experience. See the following Topics:
0 commit comments