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
[View graph on Kroki](https://kroki.io/mermaid/svg/eNqFkkFLw0AQhe_-iqVeKlg9FnIQ2gZ7UShV8BCLTDbTZOk2s-5uiPXXO9lEadoUcxrmfTu8eZPcginEa3wl-HMerB-v8bNC52-iKOKGRzGZPIg9qPIDtE_uqURB2_cNy2TDs18tgAAGkpmu4eDETGuqxQp8wXXli80Qnp_gS0uVucjXkLxhWhDtLhGWBzYrKItZf1hgG3-By1Aqp6gcx13xt3DH5X0udOuTXhtbleYhxtF6PluMQs92r2vJhsnunAGJYkGlx9IfWWc9cE7aDJKXg_O4F4t1HBCy6httCwagPYXhhJ_h606s0O6Va4yIFWklD8eLNhjzk1BcPF2nhcGa5z6RBN2fdsblzC01pf-CKYNzIu88x3POYpm1VrUZiDofaqZm6ABSg3MxbkX7v0rSZKPrx-m0r5IVW6V1VHIOt-yJdhjqH2Oz8iY=)
49
+
50
+
### Always Allow Paths Authorizer
51
+
52
+
Like in vanilla Kubernetes, this authorizer always grants access to the configured URL paths. This is
53
+
used for the health and liveness checks of kcp.
54
+
55
+
### Always Allow Groups Authorizer
56
+
57
+
This authorizer always permits access if the user is in one of the configured groups. By default this
58
+
only includes the `system:masters` group.
59
+
60
+
### RBAC Chain
61
+
62
+
The primary authorization flow is handled by a sequence of RBAC-based authorizers that a request must
63
+
satisfy all in order to be granted access.
64
+
65
+
The following authorizers work together to implement RBAC in kcp:
| Workspace content authorizer | validates that the user has `access` permission to the workspace |
70
+
| Required groups authorizer | validates that the user is in the annotation-based list of groups required for a workspace |
71
+
| System CRD authorizer | prevents undesired updates to certain core resources, like the status subresource on APIBindings |
72
+
| Maximal permission policy authorizer | validates the maximal permission policy RBAC policy in the API exporter workspace |
73
+
| Local Policy authorizer | validates the RBAC policy in the workspace that is accessed |
74
+
| Global Policy authorizer | validates the RBAC policy in the workspace that is accessed across shards |
75
+
| Kubernetes Bootstrap Policy authorizer | validates the RBAC Kubernetes standard policy |
44
76
45
-
###Workspace Content Authorizer
77
+
#### Required Groups Authorizer
46
78
47
-
The workspace content authorizer checks whether the user is granted access to the workspace.
79
+
A `authorization.kcp.io/required-groups` annotation can be added to a LogicalCluster
80
+
to specify additional groups that are required to access a workspace for a user to be member of.
81
+
The syntax is a disjunction (separator `,`) of conjunctions (separator `;`).
82
+
83
+
For example, `<group1>;<group2>,<group3>` means that a user must be member of `<group1>` AND `<group2>`, OR of `<group3>`.
84
+
85
+
The annotation is copied onto sub-workspaces during workspace creation, but is then not updated
86
+
automatically if it's changed.
87
+
88
+
#### Workspace Content Authorizer
89
+
90
+
The workspace content authorizer checks whether the user is granted access to the workspace.
48
91
Access is granted access through `verb=access` non-resource permission to `/` inside of the workspace.
49
92
50
93
The ClusterRole `system:kcp:workspace:access` is pre-defined which makes it easy
@@ -86,39 +129,30 @@ A service-account defined in a workspace implicitly is granted access to it.
86
129
87
130
A service-account defined in a different workspace is NOT given access to it.
88
131
89
-
### Required Groups Authorizer
90
-
91
-
A `authorization.kcp.io/required-groups` annotation can be added to a LogicalCluster
92
-
to specify additional groups that are required to access a workspace for a user to be member of.
93
-
The syntax is a disjunction (separator `,`) of conjunctions (separator `;`).
94
-
95
-
For example, `<group1>;<group2>,<group3>` means that a user must be member of `<group1>` AND `<group2>`, OR of `<group3>`.
96
-
97
-
The annotation is copied onto sub-workspaces during scheduling.
132
+
!!! note
133
+
By default, workspaces are only accessible to a user if they are in `Ready` phase. Workspaces that are initializing
134
+
can be accessed only by users that are granted `admin` verb on the `workspaces/content` resource in the
135
+
parent workspace.
98
136
99
-
#### Initializing Workspaces
137
+
Service accounts declared within a workspace don't have access to initializing workspaces.
100
138
101
-
By default, workspaces are only accessible to a user if they are in `Ready` phase. Workspaces that are initializing
102
-
can be access only by users that are granted `admin` verb on the `workspaces/content` resource in the
103
-
parent workspace.
139
+
#### System CRD Authorizer
104
140
105
-
Service accounts declared within a workspace don't have access to initializing workspaces.
141
+
This small authorizer simply prevents updates to the `status` subresource on APIExports or APIBindings. Note that this authorizer does not validate changes to the CustomResourceDefitions themselves, but to objects from those CRDs instead.
106
142
107
-
### Maximal Permission Policy Authorizer
143
+
#### Maximal Permission Policy Authorizer
108
144
109
145
If the requested resource type is part of an API binding, then this authorizer verifies that
110
146
the request is not exceeding the maximum permission policy of the related API export.
111
147
Currently, the "local policy" maximum permission policy type is supported.
112
148
113
-
#### Local Policy
149
+
##### Local Policy
114
150
115
151
The local maximum permission policy delegates the decision to the RBAC of the related API export.
116
152
To distinguish between local RBAC role bindings in that workspace and those for this these maximum permission policy,
117
153
every name and group is prefixed with `apis.kcp.io:binding:`.
118
154
119
-
Example:
120
-
121
-
Given an API binding for type `foo` declared in workspace `consumer` that refers to an API export declared in workspace `provider`
155
+
**Example:** Given an APIBinding for type `foo` declared in workspace `consumer` that refers to an APIExport declared in workspace `provider`
122
156
and a user `user-1` having the group `group-1` requesting a `create` of `foo` in the `default` namespace in the `consumer` workspace,
123
157
this authorizer verifies that `user-1` is allowed to execute this request by delegating to `provider`'s RBAC using prefixed attributes.
124
158
@@ -128,13 +162,13 @@ Using prefixed attributes prevents RBAC collisions i.e. if `user-1` is granted t
128
162
For the given example RBAC request looks as follows:
129
163
130
164
- Username: `apis.kcp.io:binding:user-1`
131
-
- Group: `apis.kcp.io:binding:group-1`
165
+
- Groups: [`apis.kcp.io:binding:group-1`]
132
166
- Resource: `foo`
133
167
- Namespace: `default`
134
168
- Workspace: `provider`
135
169
- Verb: `create`
136
170
137
-
The following role and role binding declared within the `provider` workspace will grant access to the request:
171
+
The following Role and RoleBinding declared within the `provider` workspace will grant access to the request:
138
172
139
173
```yaml
140
174
apiVersion: rbac.authorization.k8s.io/v1
@@ -166,32 +200,81 @@ roleRef:
166
200
```
167
201
168
202
!!! note
169
-
The same authorization scheme is enforced when executing the request of a claimed resource via the virtual API Export API server,
203
+
The same authorization scheme is enforced when executing the request of a claimed resource via the virtual APIExport API server,
170
204
i.e. a claimed resource is bound to the same maximal permission policy. Only the actual owner of that resources can go beyond that policy.
171
205
172
206
TBD: Example
173
207
174
-
### Kubernetes Bootstrap Policy Authorizer
208
+
#### Local Policy Authorizer
175
209
176
-
The bootstrap policy authorizer works just like the local authorizer but references RBAC rules
177
-
defined in the `system:admin` system workspace.
210
+
This authorizer ensures that RBAC rules contained within a workspace are being applied
211
+
and work just like in a regular Kubernetes cluster.
178
212
179
-
### Local Policy Authorizer
213
+
It is possible to bind to Roles and ClusterRoles in the bootstrap policy from a local policy's
214
+
`RoleBinding`or `ClusterRoleBinding`, for example the `system:kcp:workspace:access` ClusterRole exists in the
215
+
`system:admin`logical cluster, but can still be bound from without any other logical cluster.
180
216
181
-
Once the top-level organization authorizer and the workspace content authorizer granted access to a
182
-
workspace, RBAC rules contained in the workspace derived from the request context are evaluated.
217
+
#### Global Policy Authorizer
183
218
184
-
This authorizer ensures that RBAC rules contained within a workspace are being applied
185
-
and work just like in a regular Kubernetes cluster.
219
+
This authorizer works identically to the Local Policy Authorizer, just with the difference
220
+
that it uses a global (i.e. across shards) getter for Roles and RoleBindings.
186
221
187
-
!!! note
188
-
Groups added by the workspace content authorizer can be used for role bindings in that workspace.
222
+
#### Bootstrap Policy Authorizer
223
+
224
+
The bootstrap policy authorizer works just like the local authorizer but references RBAC rules
225
+
defined in the `system:admin` system workspace. This workspace is where the classic Kubernetes
226
+
RBAC like the `cluster-admin` ClusterRole is being defined and the policy defined in this workspace
227
+
applies to every workspace in a kcp shard.
189
228
190
-
It is possible to bind to roles and cluster roles in the bootstrap policy from a local policy `RoleBinding` or `ClusterRoleBinding`.
229
+
### Webhook Authorizer
191
230
192
-
### Service Accounts
231
+
This authorizer can be enabled by providing the `--authorization-webhook-config-file` flag to the kcp process
232
+
and works identically to [how it works in vanilla Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/).
193
233
194
-
Kubernetes service accounts are granted access to the workspaces they are defined in and that are ready.
234
+
The given configuration file must be of the kubeconfg format and point to an HTTPS server, potentially including certificate information as needed:
195
235
196
-
E.g. a service account "default" in `root:org:ws:ws` is granted access to `root:org:ws:ws`, and through the
197
-
workspace content authorizer it gains the `system:kcp:clusterworkspace:access` group membership.
236
+
```yaml
237
+
apiVersion: v1
238
+
kind: Config
239
+
clusters:
240
+
- name: webhook
241
+
cluster:
242
+
server: https://localhost:8080/
243
+
current-context: webhook
244
+
contexts:
245
+
- name: webhook
246
+
context:
247
+
cluster: webhook
248
+
```
249
+
250
+
The webhook will receive every authorization request made in kcp, including internal ones. This means if the webhook
251
+
is badly configured, it can even prevent kcp from starting up successfully, but on the other hand this allows
252
+
a lot of influence over the authorization in kcp.
253
+
254
+
The webhook will receive JSON-marshalled `SubjectAccessReview` objects, that (compared to vanilla Kubernetes) include the name of target logical cluster as an `extra` field, like so:
The extra field will contain the logical cluster _name_ (e.g. o43u2gh528rtfg721rg92), not the human-readable path. Webhooks need to resolve the name to a path themselves if necessary.
0 commit comments