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

📖 change the order of authorizers in the docs #3286

Merged
merged 1 commit into from
Feb 7, 2025
Merged
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
38 changes: 19 additions & 19 deletions docs/content/concepts/authorization/authorizers.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,13 +17,13 @@ They are related in the following way:
``` mermaid
graph TD
start(Request):::state --> main_alt[/one of\]:::or
main_alt --> aapa[Always Allow Paths Auth]
main_alt --> aaga[Always Allow Groups Auth]
main_alt --> aapa[Always Allow Paths Auth]
main_alt --> wa[Webhook Auth]
main_alt --> rga[Required Groups Auth]

aapa --> decision(Decision):::state
aaga --> decision
aaga --> decision(Decision):::state
aapa --> decision
wa --> decision

subgraph "RBAC"
Expand Down Expand Up @@ -281,55 +281,55 @@ The webhook will receive JSON-marshalled `SubjectAccessReview` objects, that (co

### Scopes

Scopes are a way to limit the access of a user to a specific logical cluster.
Scopes are (optionally) attached to the user identity by setting the
Scopes are a way to limit the access of a user to a specific logical cluster.
Scopes are (optionally) attached to the user identity by setting the
`authentication.kcp.io/scopes: cluster:<logical-cluster>,...` extra field. The
scope is then checked by the authorizers. For example:

```yaml
user: user1
groups: ["group1"]
extra:
authentication.kcp.io/scopes:
authentication.kcp.io/scopes:
- cluster:logical-cluster-1
```
This user will only be allowed to access resources in `logical-cluster-1`,
falling back to be considered as user `system:anonymous` with group
This user will only be allowed to access resources in `logical-cluster-1`,
falling back to be considered as user `system:anonymous` with group
`system:authenticated` in all other logical clusters.

Each extra field can contain multiple scopes, separated by a comma:
```yaml
user: user1
groups: ["group1"]
extra:
authentication.kcp.io/scopes:
authentication.kcp.io/scopes:
- cluster:logical-cluster-1,cluster:logical-cluster-2
```
This user is allowed to operate in both `logical-cluster-1` and
`logical-cluster-2`, falling back to be considered as user `system:anonymous`
This user is allowed to operate in both `logical-cluster-1` and
`logical-cluster-2`, falling back to be considered as user `system:anonymous`
with group `system:authenticated` in all other logical clusters.

If multiple `authentication.kcp.io/scopes` values are set, the intersection is
If multiple `authentication.kcp.io/scopes` values are set, the intersection is
taken:
```yaml
user: user1
groups: ["group1"]
extra:
authentication.kcp.io/scopes:
authentication.kcp.io/scopes:
- cluster:logical-cluster-1,cluster:logical-cluster-2
- cluster:logical-cluster-2,cluster:logical-cluster-3
```
This user is only allowed to operate in `logical-cluster-2`, falling back to be
considered as user `system:anonymous` with group `system:authenticated` in all
considered as user `system:anonymous` with group `system:authenticated` in all
other logical clusters.

The intersection can be empty, in which case it falls back in every logical
The intersection can be empty, in which case it falls back in every logical
cluster.

When impersonating a user in a logical cluster, the resulting user identity is
When impersonating a user in a logical cluster, the resulting user identity is
scoped to the logical cluster the impersonation is happening in.

A scope mismatch does not invalidate the warrants (see next section) of a user.
A scope mismatch does not invalidate the warrants (see next section) of a user.

### Warrants

Expand All @@ -353,10 +353,10 @@ extra:
}
```

This warrant allows `user1` to act under the permissions of `user2` in
This warrant allows `user1` to act under the permissions of `user2` in
`logical-cluster-1` if `user1` is not allowed to act as `user2` in the first place.

Note that a warrant only allow to act under the permissions of the warrant user,
Note that a warrant only allow to act under the permissions of the warrant user,
but not to act as the warrant user itself. E.g. in auditing or admission control,
the primary user is still the one that is acting.

Expand Down
Loading