mirror of
https://github.com/gravitational/teleport.git
synced 2026-09-24 16:17:11 +08:00
Add documentation for moderated sessions (#9425)
This commit is contained in:
Joel
+2
-1
@@ -238,7 +238,8 @@
|
||||
{ "title": "Second Factor - WebAuthn", "slug": "/access-controls/guides/webauthn/" },
|
||||
{ "title": "Per-session MFA", "slug": "/access-controls/guides/per-session-mfa/" },
|
||||
{ "title": "Dual Authorization", "slug": "/access-controls/guides/dual-authz/" },
|
||||
{ "title": "Impersonation", "slug": "/access-controls/guides/impersonation/" }
|
||||
{ "title": "Impersonation", "slug": "/access-controls/guides/impersonation/" },
|
||||
{ "title": "Moderated Sessions", "slug": "/access-controls/guides/moderated-sessions/" }
|
||||
]
|
||||
},
|
||||
{ "title": "Reference", "slug": "/access-controls/reference/" },
|
||||
|
||||
@@ -122,7 +122,7 @@ Save this role as `interns.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: interns
|
||||
spec:
|
||||
|
||||
@@ -23,4 +23,7 @@ layout: tocless-doc
|
||||
<li>
|
||||
[Locking](./guides/locking.mdx). Lock access to active user sessions or hosts.
|
||||
</li>
|
||||
<li>
|
||||
[Moderated Sessions](./guides/moderated-sessions.mdx). Require session auditors and allow fine-grained live session access.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
@@ -80,7 +80,7 @@ spec:
|
||||
version: v2
|
||||
---
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: access-plugin
|
||||
spec:
|
||||
@@ -162,7 +162,7 @@ Create `dbadmin`, `reviewer` and `devops` roles:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: reviewer
|
||||
spec:
|
||||
@@ -171,7 +171,7 @@ spec:
|
||||
roles: ['dbadmin']
|
||||
---
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: devops
|
||||
spec:
|
||||
@@ -183,7 +183,7 @@ spec:
|
||||
deny: 1
|
||||
---
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: dbadmin
|
||||
spec:
|
||||
|
||||
@@ -32,7 +32,7 @@ Save this file as `jenkins.yaml` to create the user and role:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: jenkins
|
||||
spec:
|
||||
@@ -77,7 +77,7 @@ Save this role definition as `impersonator.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: impersonator
|
||||
spec:
|
||||
@@ -179,7 +179,7 @@ allowed the impersonation of any users or roles with the label
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: security-impersonator
|
||||
spec:
|
||||
@@ -214,7 +214,7 @@ Create a user and a role `security-scanner` using the following template:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: security-scanner
|
||||
labels:
|
||||
@@ -256,7 +256,7 @@ as the label on the role and/or user to impersonate:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: security-impersonator
|
||||
spec:
|
||||
|
||||
@@ -106,7 +106,7 @@ Create a role `locksmith`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: locksmith
|
||||
spec:
|
||||
@@ -232,7 +232,7 @@ It is also possible to configure the locking mode for a particular role:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: example-role-with-strict-locking
|
||||
spec:
|
||||
|
||||
@@ -0,0 +1,182 @@
|
||||
---
|
||||
title: Moderated Sessions
|
||||
description: Moderated Sessions
|
||||
h1: Moderated Sessions
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
Moderated Sessions allows Teleport administrators to
|
||||
define requirements for other users to be present in a Server or Kubernetes Access session. Depending on the requirements, these users can observe the session in real time, participate in the session, and terminate the session at will.
|
||||
|
||||
### Use cases
|
||||
|
||||
Moderated Sessions are useful in the following scenarios:
|
||||
- When you have stringent security requirements and need to have people watching over user-initiated sessions on a set of servers.
|
||||
- When you want to share a terminal with someone else to be able to instruct or collaborate.
|
||||
|
||||
## Policies
|
||||
|
||||
Moderated Sessions makes use of RBAC policies to allow for fine grained control over
|
||||
who can join a session and who is required to be present to start one.
|
||||
|
||||
The system is based around **require policies** and **allow policies**.
|
||||
|
||||
Require policies define a set of conditions that must be a met for a session to start or run.
|
||||
A minimum of one policy from each relevant role the user has must match for the session to start.
|
||||
|
||||
Allow policies are used to define what sessions a user can join
|
||||
and under what conditions they may join a session.
|
||||
|
||||
## Configuring Moderated Sessions
|
||||
|
||||
### `require_session_join`
|
||||
|
||||
#### Options
|
||||
|
||||
The following are required options for `require_session_join`:
|
||||
|
||||
|Option|Type|Description|
|
||||
|---|---|---|
|
||||
|`name`|String|The name of the require policy|
|
||||
|`filter`|[Filter](#filters)|An expression that, if it evaluates to true for a given user, enables the user to be present in a Moderated Session|
|
||||
|`kinds`|`[]`[Session kind](#session-kinds)|The kind of session that the policy applies to|
|
||||
|`modes`|`[]`[Participant mode](#participant-modes)|The participant mode that applies to the user joining the Moderated Session under this policy|
|
||||
|`count`|Integer|The number of users that need to match the filter expression to satisfy the policy|
|
||||
|
||||
#### Example
|
||||
|
||||
The policy below specifies that the `prod-access` role
|
||||
must have a minimum of two users with the role `auditor` and the mode `moderator` present in the session
|
||||
to start it. The policy applies to SSH and Kubernetes sessions only.
|
||||
|
||||
When a user with this require policy starts a session, it will be pending
|
||||
until the policy is fulfilled.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
metadata:
|
||||
name: prod-access
|
||||
spec:
|
||||
allow:
|
||||
require_session_join:
|
||||
- name: Auditor oversight
|
||||
filter: 'contains(user.roles, "auditor")'
|
||||
kinds: ['k8s', 'ssh']
|
||||
modes: ['moderator']
|
||||
count: 2
|
||||
```
|
||||
|
||||
### `join_sessions`
|
||||
|
||||
#### Options
|
||||
|
||||
The following are required options for `join_sessions`:
|
||||
|
||||
|Option|Type|Description|
|
||||
|---|---|---|
|
||||
|`name`|String|The name of the allow policy|
|
||||
|`roles`|[]String|A list of names for Teleport roles that this policy applies to. Users with this role are eligible to join a Moderated Session under this policy.|
|
||||
|`kinds`|`[]`[Session kind](#session-kinds)|The kind of session that the policy applies to|
|
||||
|`modes`|`[]`[Participant mode](#participant-modes)|The participant mode that applies to the user joining the Moderated Session under this policy|
|
||||
|
||||
#### Example
|
||||
|
||||
The following allow policy attaches to the role `auditor` and allows one to join
|
||||
SSH and Kubernetes sessions started by a user with the role `prod-access` as a moderator or observer.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
metadata:
|
||||
name: auditor
|
||||
spec:
|
||||
allow:
|
||||
join_sessions:
|
||||
- name: Auditor oversight
|
||||
roles : ['prod-access']
|
||||
kinds: ['k8s', 'ssh']
|
||||
modes: ['moderator', 'observer']
|
||||
```
|
||||
|
||||
### Filters
|
||||
|
||||
Filter expressions allow for more detailed control over the scope of an allow policy or require policy.
|
||||
|
||||
Require policies can specify which users they consider as valid with a filter expression.
|
||||
The filter context has a `user` object defined with the set fields `roles` and `name`.
|
||||
|
||||
Here is an example of a filter expression that evaluates to true if the user is Adam or if the user has the trait `cs-observe`:
|
||||
|
||||
```
|
||||
equals(user.name, "adam") || contains(user.roles, "cs-observe")
|
||||
```
|
||||
|
||||
A filter expression is a string statement used to define logic based on a set of input variables.
|
||||
The filter expressions follow a restricted subset of Go syntax and supports
|
||||
the following functions and operators:
|
||||
- `contains(set, item)`: Returns true if the item is in the set, otherwise false. The set can be a string or an array.
|
||||
- `equals(a, b)`: Returns true if the two values are equal, otherwise returns false.
|
||||
- `![expr]`: Negates a boolean expression.
|
||||
- `[expr] && [expr]`: Performs a logical AND on two boolean expressions.
|
||||
- `[expr] || [expr]`: Performs a logical OR on two boolean expressions.
|
||||
|
||||
### Session kinds
|
||||
|
||||
Require and allow policies have to specify which sessions they apply to. Valid options are `ssh` and `k8s`.
|
||||
|
||||
- `ssh` policies apply to all SSH sessions on a node running the Teleport SSH server.
|
||||
- `k8s` policies apply to all Kubernetes sessions on clusters connected to Teleport.
|
||||
|
||||
### Participant modes
|
||||
A participant joining a session will always have one of three modes:
|
||||
|
||||
- `peer`: Can join and collaborate in a session. They can view output and send input.
|
||||
- `moderator`: Can join and watch a session. They can view output and forcefully terminate the session at will.
|
||||
- `observer`: Can join and watch a session. They cannot control the session in any way.
|
||||
|
||||
When joining a session with `tsh join` or `tsh kube join`, a user can specify a mode with the `--mode <mode>` flag
|
||||
, where the mode is one of `peer`, `moderator` or `observer`. By default, the mode is `peer` for SSH and
|
||||
`moderator` for Kubernetes sessions.
|
||||
|
||||
A participant may leave a session with the shortcut `c` while in observer or moderator mode.
|
||||
When in moderator mode, a participant may also forcefully terminate the session at any point in time
|
||||
with the shortcut `t`.
|
||||
|
||||
### Require policy count
|
||||
|
||||
Require policies can have a variable amount of users that need to match the filter expression
|
||||
in order to satisfy the policy. The `count` field of a require policy is a positive integer
|
||||
value that specifies the minimum amount of users this policy requires.
|
||||
|
||||
## Backwards compatibility with Server Access
|
||||
|
||||
Previously, Server Access did not include controls over which users can join a session.
|
||||
To work around this, RBAC rules are ignored for users that only have V4 roles (`version: v4` in the role specification).
|
||||
New roles are created as V5. V4 roles are upgraded when they are modified in the UI.
|
||||
If a user has any attached V5 roles (`version: v5` in the role specification), the new RBAC access checks will be enforced.
|
||||
|
||||
## MFA-based presence
|
||||
|
||||
When `per_session_mfa` is set to `true` via [role or cluster settings](../../access-controls/guides/per-session-mfa.mdx), Teleport enforces
|
||||
MFA-based presence checks for moderators.
|
||||
This requires that all moderators wishing to join have a configured U2F or WebAuthn MFA token.
|
||||
|
||||
Every 30 seconds, Teleport will issue a prompt to the user in the terminal, asking them
|
||||
to press their MFA token in the next 15 seconds. This will happen continously during the session
|
||||
and exists so that moderators are always present and watching a given session.
|
||||
|
||||
If no MFA input is received within 60 seconds, the user is kicked
|
||||
from the session which may pause it, if RBAC policies are no longer met.
|
||||
|
||||
## Session invites
|
||||
|
||||
When starting an interactive SSH or Kubernetes session using `tsh ssh` or `tsh kube exec` respectively,
|
||||
one may supply a `--reason <reason>` and/or an `--invited <users>` flag where `<reason>`
|
||||
is a string and `<users>` is a comma-separated list of usernames.
|
||||
|
||||
This information can be picked up by a third party integration and may for example be used to
|
||||
enable notifications over some external communication system.
|
||||
|
||||
## RFD
|
||||
|
||||
- [Moderated Sessions](https://github.com/gravitational/teleport/blob/master/rfd/0043-kubeaccess-multiparty.md)
|
||||
@@ -92,7 +92,7 @@ Olga defines two Teleport roles: `access-dev` and `access-prod`:
|
||||
```yaml
|
||||
# access-dev.yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: access-dev
|
||||
spec:
|
||||
@@ -111,7 +111,7 @@ spec:
|
||||
---
|
||||
# access-prod.yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: access-prod
|
||||
spec:
|
||||
|
||||
@@ -36,7 +36,7 @@ We can create two roles, one for each user in file `roles.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: alice
|
||||
spec:
|
||||
@@ -49,7 +49,7 @@ spec:
|
||||
'*': '*'
|
||||
---
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: bob
|
||||
spec:
|
||||
@@ -78,7 +78,7 @@ Let's create a role template `devs.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: devs
|
||||
spec:
|
||||
@@ -173,7 +173,7 @@ to be set by identity provider. Save this role as `sso-users.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: sso-users
|
||||
spec:
|
||||
@@ -255,7 +255,7 @@ Let's see how these variables are used with role template `interpolation`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: interpolation
|
||||
spec:
|
||||
@@ -288,7 +288,7 @@ behave as the following role:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: interpolation
|
||||
spec:
|
||||
|
||||
@@ -43,7 +43,7 @@ A role definition looks like this:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: example
|
||||
spec:
|
||||
@@ -143,6 +143,35 @@ spec:
|
||||
- resources: [token]
|
||||
verbs: [list,create,read,update,delete]
|
||||
|
||||
# Moderated Sessions policy that dictates requirements for starting a session.
|
||||
require_session_join:
|
||||
# Defines the name of the policy. The name serves only as an
|
||||
# identifier in logs and for organisation/categorisation.
|
||||
- name: Auditor oversight
|
||||
# Specifies an RBAC predicate that is used to define
|
||||
# which users count against the required user count of the policy.
|
||||
filter: 'contains(user.roles, "auditor")'
|
||||
# The different session kinds this policy applies to.
|
||||
kinds: ['k8s', 'ssh']
|
||||
# A list of session participant modes that a participant must have
|
||||
# one of in order to count against the policy.
|
||||
modes: ['moderator']
|
||||
# The minimum amount of users that need to match the filter expression
|
||||
# in order to satisfy the policy.
|
||||
count: 1
|
||||
|
||||
# Moderated Sessions policy that dictates the ability to join sessions
|
||||
join_sessions:
|
||||
# Defines the name of the policy. The name serves only as an
|
||||
# identifier in logs and for organisation/categorisation.
|
||||
- name: Auditor oversight
|
||||
# Allows one to join sessions created by other users with these roles
|
||||
roles : ['prod-access']
|
||||
# The different session kinds this policy applies to.
|
||||
kinds: ['k8s', 'ssh']
|
||||
# The list of session participant modes the role may join the session as.
|
||||
modes: ['moderator', 'observer']
|
||||
|
||||
# The deny section uses the identical format as the 'allow' section.
|
||||
# The deny rules always override allow rules.
|
||||
deny: {}
|
||||
@@ -214,12 +243,12 @@ that are more appropriately scoped.
|
||||
|
||||
### Role versions
|
||||
|
||||
There are currently two supported role versions: `v3` and `v4`. `v4` roles are
|
||||
There are currently two supported role versions: `v3` and `v5`. `v5` roles are
|
||||
completely backwards-compatible with `v3`, the only difference lies in the
|
||||
default allow labels which will be applied to the role if they are not
|
||||
explicitly set.
|
||||
|
||||
Label | `v3` Default | `v4` Default
|
||||
Label | `v3` Default | `v5` Default
|
||||
------------------ | -------------- | ---------------
|
||||
`node_labels` | `[{"*": "*"}]` if the role has any logins, else `[]` | `[]`
|
||||
`app_labels` | `[{"*": "*"}]` | `[]`
|
||||
@@ -247,7 +276,7 @@ Access to any other nodes will be denied.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: example-role
|
||||
spec:
|
||||
@@ -278,7 +307,7 @@ Below are a few examples for more complex filtering using various regexes.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: example-role
|
||||
spec:
|
||||
@@ -355,7 +384,7 @@ downgrade they will become invalid.
|
||||
Role for restricted access to session recordings:
|
||||
|
||||
```yaml
|
||||
version: v4
|
||||
version: v5
|
||||
kind: role
|
||||
metadata:
|
||||
name: only-own-sessions
|
||||
@@ -372,7 +401,7 @@ spec:
|
||||
Role for restricted access to active sessions:
|
||||
|
||||
```yaml
|
||||
version: v4
|
||||
version: v5
|
||||
kind: role
|
||||
metadata:
|
||||
name: only-own-ssh-sessions
|
||||
|
||||
@@ -36,7 +36,7 @@ spec:
|
||||
deny:
|
||||
node_labels:
|
||||
'*': '*'
|
||||
version: v4
|
||||
version: v5
|
||||
EOF
|
||||
# Create role
|
||||
tctl create -f api-role.yaml
|
||||
|
||||
@@ -41,7 +41,7 @@ For example, this role will grant access to all applications from the group
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: dev
|
||||
spec:
|
||||
|
||||
@@ -141,7 +141,7 @@ role ARNs this particular role permits its users to assume:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: aws-console-access
|
||||
spec:
|
||||
|
||||
@@ -90,7 +90,7 @@ database account:
|
||||
```bash
|
||||
tctl --config=/path/to/teleport-db-role.yaml create <<EOF
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: db
|
||||
spec:
|
||||
|
||||
@@ -70,7 +70,7 @@ database account:
|
||||
```bash
|
||||
tctl --config=/path/to/teleport.yaml create <<EOF
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: db
|
||||
spec:
|
||||
|
||||
@@ -23,7 +23,7 @@ database access:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: developer
|
||||
spec:
|
||||
@@ -55,7 +55,7 @@ production database except for the internal "postgres" database/user:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: developer
|
||||
spec:
|
||||
|
||||
@@ -418,7 +418,7 @@ that gives its users access to all Windows desktop labels and the
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: windows-desktop-admins
|
||||
spec:
|
||||
|
||||
@@ -60,7 +60,7 @@ desktop access:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: developer
|
||||
spec:
|
||||
|
||||
@@ -126,7 +126,7 @@ connect to Teleport nodes. To support this:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: sso_user
|
||||
spec:
|
||||
@@ -165,7 +165,7 @@ Here's how this looks in a Teleport role:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: sso_user
|
||||
spec:
|
||||
|
||||
@@ -146,7 +146,7 @@ obtain admin access to Teleport.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: dev
|
||||
spec:
|
||||
|
||||
@@ -110,7 +110,7 @@ root and is capable of administrating the cluster and non-privileged dev.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: admin
|
||||
spec:
|
||||
@@ -129,7 +129,7 @@ The developer role:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: dev
|
||||
spec:
|
||||
|
||||
@@ -124,7 +124,7 @@ and just have the username prefix.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: dev
|
||||
spec:
|
||||
|
||||
@@ -133,7 +133,7 @@ obtain admin access to Teleport.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: dev
|
||||
spec:
|
||||
|
||||
@@ -24,7 +24,7 @@ This role allows the contractor to request the role DBA.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: contractor
|
||||
spec:
|
||||
@@ -43,7 +43,7 @@ This role allows the contractor to request the role DBA.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: dba
|
||||
spec:
|
||||
@@ -62,7 +62,7 @@ This role allows the admin to approve the contractor's request.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: admin
|
||||
spec:
|
||||
@@ -131,7 +131,7 @@ the permission of the `dba`.
|
||||
# Example role that explicitly denies a contractor from requesting the admin
|
||||
# role.
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: contractor
|
||||
spec:
|
||||
|
||||
@@ -46,7 +46,7 @@ spec:
|
||||
# teleport currently refuses to issue certs for a user with 0 logins,
|
||||
# this restriction may be lifted in future versions.
|
||||
logins: ['access-plugin-jira']
|
||||
version: v4
|
||||
version: v5
|
||||
EOF
|
||||
|
||||
# ...
|
||||
|
||||
@@ -64,7 +64,7 @@ spec:
|
||||
# teleport currently refuses to issue certs for a user with 0 logins,
|
||||
# this restriction may be lifted in future versions.
|
||||
logins: ['access-plugin-jira']
|
||||
version: v4
|
||||
version: v5
|
||||
EOF
|
||||
|
||||
# ...
|
||||
|
||||
@@ -88,7 +88,7 @@ spec:
|
||||
# teleport currently refuses to issue certs for a user with 0 logins,
|
||||
# this restriction may be lifted in future versions.
|
||||
logins: ['access-plugin-mattermost']
|
||||
version: v4
|
||||
version: v5
|
||||
EOF
|
||||
|
||||
# Run this to create the user and role in Teleport.
|
||||
|
||||
@@ -51,7 +51,7 @@ spec:
|
||||
# teleport currently refuses to issue certs for a user with 0 logins,
|
||||
# this restriction may be lifted in future versions.
|
||||
logins: ['access-plugin-pagerduty']
|
||||
version: v4
|
||||
version: v5
|
||||
EOF
|
||||
|
||||
# Run this to create the user and role in Teleport.
|
||||
|
||||
@@ -50,7 +50,7 @@ The Teleport Cloud requires authenticating with a role that has [`impersonation`
|
||||
Login in with `tsh` with a user that has this role or has a role with these allows.
|
||||
```
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: plugin-admin
|
||||
spec:
|
||||
@@ -83,7 +83,7 @@ spec:
|
||||
version: v2
|
||||
---
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: access-plugin
|
||||
spec:
|
||||
|
||||
@@ -170,7 +170,7 @@ Teleport's user and role for used for bot access:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: bot
|
||||
spec:
|
||||
@@ -215,4 +215,4 @@ tctl auth sign --host=mars.openssh.teleport --format=openssh --overwrite --out=m
|
||||
|
||||
# Adds generated certs to SSH agent on start
|
||||
cd /mnt/shared/certs && /usr/bin/ssh-add bot;
|
||||
```
|
||||
```
|
||||
|
||||
@@ -105,7 +105,7 @@ be substituted to the users' group list in the role definition.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: group-member
|
||||
spec:
|
||||
@@ -229,7 +229,7 @@ Limit access to cluster based on the label:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: group-member
|
||||
spec:
|
||||
|
||||
@@ -166,7 +166,7 @@ Save this role as `member.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: member
|
||||
spec:
|
||||
|
||||
@@ -14,7 +14,7 @@ to create credentials.
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: robot
|
||||
spec:
|
||||
|
||||
@@ -343,7 +343,7 @@ First, set the set of Kubernetes labels a user can access on their roles:
|
||||
```yaml
|
||||
# role-admin.yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: admin
|
||||
spec:
|
||||
|
||||
@@ -88,7 +88,7 @@ Create a file `netpolicy.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: network_restrictions
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: network-restrictions
|
||||
spec:
|
||||
|
||||
@@ -238,7 +238,7 @@ First, we need to create a special role for root users on "leaf":
|
||||
# Save this into root-user-role.yaml on the leaf cluster and execute:
|
||||
# tctl create root-user-role.yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: local-admin
|
||||
spec:
|
||||
|
||||
@@ -107,7 +107,7 @@ Now you have a label on the instance which you can use inside a Teleport role. H
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: test-tag-role
|
||||
spec:
|
||||
|
||||
@@ -117,7 +117,7 @@ spec:
|
||||
rules:
|
||||
- resources: ['event']
|
||||
verbs: ['list','read']
|
||||
version: v4
|
||||
version: v5
|
||||
```
|
||||
|
||||
Use `tctl` to create the role and the user:
|
||||
@@ -151,7 +151,7 @@ Create the following file with role: `teleport-event-handler-impersonator.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: teleport-event-handler-impersonator
|
||||
spec:
|
||||
|
||||
@@ -64,7 +64,7 @@ spec:
|
||||
rules:
|
||||
- resources: ['user', 'role', 'token', 'trusted_cluster', 'github', 'oidc', 'saml']
|
||||
verbs: ['list','create','read','update','delete']
|
||||
version: v4
|
||||
version: v5
|
||||
---
|
||||
kind: user
|
||||
metadata:
|
||||
@@ -93,7 +93,7 @@ Create the following file with role: `terraform-impersonator.yaml`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: terraform-impersonator
|
||||
spec:
|
||||
|
||||
@@ -166,7 +166,7 @@ Roles govern access to databases, SSH servers, kubernetes clusters, and web apps
|
||||
```yaml
|
||||
---
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: example
|
||||
spec:
|
||||
|
||||
@@ -112,7 +112,7 @@ You can enable some users to review other users' role escalation requests by app
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: reviewer
|
||||
spec:
|
||||
@@ -128,7 +128,7 @@ You can require a user to request access from reviewers by applying a dynamic re
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: reviewee
|
||||
spec:
|
||||
@@ -152,7 +152,7 @@ As an illustration, we have assigned user `myuser` to the `user` role, which we
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: user
|
||||
spec:
|
||||
@@ -202,7 +202,7 @@ you can prevent analysts who are *not* in the `admins` group from requesting acc
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: analyst
|
||||
spec:
|
||||
@@ -230,7 +230,7 @@ First, define a role with privileged but limited access. In the following exampl
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: editor
|
||||
spec:
|
||||
@@ -244,7 +244,7 @@ Next, we define the general `user` role. Users with this role can review other u
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
version: v4
|
||||
version: v5
|
||||
metadata:
|
||||
name: user
|
||||
spec:
|
||||
|
||||
Reference in New Issue
Block a user