Skip to content
Merged
Show file tree
Hide file tree
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
Original file line number Diff line number Diff line change
Expand Up @@ -29,20 +29,23 @@ Requests in the Proxy or Auth Service.

## Step 2/8. Install the Teleport Mattermost plugin

<ScopedBlock scope={["enterprise", "oss"]}>
<Tabs>
<TabItem scope={["enterprise", "oss"]} label="Self-Hosted">

We recommend installing Teleport plugins on the same host as the Teleport Proxy
Service. This is an ideal location as plugins have a low memory footprint, and
will require both public internet access and Teleport Auth Service access.

</ScopedBlock>
</TabItem>

<ScopedBlock scope="cloud">
<TabItem scope="cloud" label="Teleport Enterprise Cloud">

Install the Teleport Mattermost plugin on a host that can access both your
Teleport Proxy Service and your Mattermost deployment.

</ScopedBlock>
</TabItem>

</Tabs>

(!docs/pages/includes/plugins/install-access-request.mdx name="mattermost"!)

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -13,16 +13,12 @@ under the hood.
The Access Request API makes it easy to dynamically approve or deny these
requests.

<ScopedBlock scope={["oss"]}>

Just-in-time Access Requests are a feature of Teleport Enterprise.
Open-source Teleport users can get a preview of how Access Requests work by
requesting a role via the Teleport CLI. Full Access Request functionality,
including Resource Access Requests and an intuitive and searchable UI are
available in Teleport Enterprise.

</ScopedBlock>

## Prerequisites

(!docs/pages/includes/commercial-prereqs-tabs.mdx!)
Expand Down
34 changes: 22 additions & 12 deletions docs/pages/access-controls/getting-started.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -33,57 +33,66 @@ Teleport Enterprise contains two additional preset roles: `reviewer` and `reques
- The `requester` role authorizes users to request resources.
</Details>

<ScopedBlock scope={["oss"]}>
<Tabs>
<TabItem scope={["oss"]} label="Teleport Community Edition">
Invite the local user Alice as cluster `editor`:

```code
$ tctl users add alice --roles=editor
```
</ScopedBlock>
<ScopedBlock scope={["enterprise", "cloud"]}>
</TabItem>
<TabItem scope={["enterprise", "cloud"]} label="Commercial">
Invite the local user Alice as cluster `editor` and `reviewer`:

```code
$ tctl users add alice --roles=editor,reviewer
```
</ScopedBlock>
</TabItem>

</Tabs>

Once Alice signs up, she will be able to edit cluster configuration. You can list
users and their roles using `tctl users ls`.

<ScopedBlock scope={"oss"}>
<Tabs>
<TabItem scope={"oss"} label="Teleport Community Edition">
```code
$ tctl users ls

# User Roles
# -------------------- --------------
# alice editor
```
</ScopedBlock>
<ScopedBlock scope={["enterprise", "cloud"]}>
</TabItem>
<TabItem scope={["enterprise", "cloud"]} label="Commercial">
```code
$ tctl users ls

# User Roles
# -------------------- --------------
# alice editor, reviewer
```
</ScopedBlock>
</TabItem>

</Tabs>

You can update the user's roles using the `tctl users update` command:

<ScopedBlock scope={"oss"}>
<Tabs>
<TabItem scope={"oss"} label="Teleport Community Edition">
```code
# Once Alice logs back in, she will be able to view audit logs
$ tctl users update alice --set-roles=editor,auditor
```
</ScopedBlock>
<ScopedBlock scope={["enterprise", "cloud"]}>
</TabItem>
<TabItem scope={["enterprise", "cloud"]} label="Commercial">
```code
# Once Alice logs back in, she will be able to view audit logs
$ tctl users update alice --set-roles=editor,reviewer,auditor
```
</ScopedBlock>
</TabItem>

</Tabs>

Because Alice has two or more roles, permissions from those roles create a union. She
will be able to act as a system administrator and auditor at the same time.
Expand Down Expand Up @@ -252,3 +261,4 @@ $ tctl get roles --format text

- [Mapping SSO and local users traits with role templates](./guides/role-templates.mdx)
- [Create certs for CI/CD using impersonation](./guides/impersonation.mdx)

7 changes: 1 addition & 6 deletions docs/pages/access-controls/guides/dual-authz.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -208,13 +208,10 @@ Bob can also assume granted Access Request roles using Web UI:

![Teleport Assume](../../../img/access-controls/dual-authz/teleport-7-bob-assume.png)

{/* TODO: This H2 will show up in the table of contents when this section is invisible.
We need a way to hide invisible H2s from the TOC. */}
<ScopedBlock scope={["enterprise"]}>

## Troubleshooting

### Cert errors in self-hosted deployments
### Certificate errors in self-hosted deployments

You may be getting certificate errors if Teleport's Auth Service is missing an address in the server certificate:

Expand All @@ -232,5 +229,3 @@ To fix the problem, update the Auth Service with a public address, and restart T
auth_service:
public_addr: ['localhost:3025', 'example.com:3025']
```

</ScopedBlock>
15 changes: 9 additions & 6 deletions docs/pages/access-controls/guides/hardware-key-support.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -127,7 +127,8 @@ role or to that cluster must use their hardware key for all Teleport requests.
Affected users will be prompted to connect and touch their YubiKey to sign in.
The first time users sign in with their hardware key they might be required to immediately sign in again.

<ScopedBlock scope={["oss"]}>
<Tabs>
<TabItem scope={["oss"]} label="Teleport Community Edition">

```code
$ tsh login --user=dev --proxy=proxy.example.com:3080
Expand All @@ -143,9 +144,9 @@ $ tsh login --user=dev --proxy=proxy.example.com:3080

```

</ScopedBlock>
</TabItem>

<ScopedBlock scope={["enterprise"]}>
<TabItem scope={["enterprise"]} label="Teleport Enterprise">

```code
$ tsh login --user=dev --proxy=proxy.example.com:3080
Expand All @@ -160,9 +161,9 @@ $ tsh login --user=dev --proxy=proxy.example.com:3080
# ...
```

</ScopedBlock>
</TabItem>

<ScopedBlock scope={["cloud"]}>
<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">

```code
$ tsh login --user=dev --proxy=proxy.example.com:3080
Expand All @@ -177,7 +178,9 @@ $ tsh login --user=dev --proxy=proxy.example.com:3080
# ...
```

</ScopedBlock>
</TabItem>

</Tabs>

Affected users with existing sessions that aren't backed by a hardware key are prompted to sign in again
on their next request. For example:
Expand Down
23 changes: 15 additions & 8 deletions docs/pages/access-controls/guides/impersonation.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -118,22 +118,25 @@ $ tctl users add alice --roles=impersonator,access

Alice can log in using `tsh` and issue a cert for `jenkins`:

<ScopedBlock scope={["oss", "enterprise"]}>
<Tabs>
<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">

```code
$ tsh login --proxy=proxy.example.com --user=alice --auth=local
$ tctl auth sign --user=jenkins --format=openssh --out=jenkins --ttl=240h
```

</ScopedBlock>
<ScopedBlock scope={["cloud"]}>
</TabItem>
<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">

```code
$ tsh login --proxy=mytenant.teleport.sh --user=alice --auth=local
$ tctl auth sign --user=jenkins --format=openssh --out=jenkins --ttl=240h
```

</ScopedBlock>
</TabItem>

</Tabs>

Here is an example of how Alice can use the keys:

Expand Down Expand Up @@ -310,7 +313,8 @@ scanner.

Alice will need to log in again to receive the newly updated traits:

<ScopedBlock scope={["oss", "enterprise"]}>
<Tabs>
<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">

```code
# Once Alice logs in again, she will receive a new certificate with updated roles.
Expand All @@ -319,8 +323,8 @@ $ tsh login --proxy=teleport.example.com --user=alice --auth=local
$ tctl auth sign --user=security-scanner --format=openssh --out=security-scanner --ttl=10h
```

</ScopedBlock>
<ScopedBlock scope={["cloud"]}>
</TabItem>
<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">

```code
# Once Alice logs in again, she will receive a new certificate with updated roles.
Expand All @@ -329,7 +333,9 @@ $ tsh login --proxy=mytenant.teleport.sh --user=alice --auth=local
$ tctl auth sign --user=security-scanner --format=openssh --out=security-scanner --ttl=10h
```

</ScopedBlock>
</TabItem>

</Tabs>

### Filter fields

Expand All @@ -343,3 +349,4 @@ Here is an explanation of the fields used in the `where` conditions within this

Check out our [predicate language](../../reference/predicate-language.mdx#scoping-allowdeny-rules-in-role-resources)
guide for a more in depth explanation of the language.

12 changes: 8 additions & 4 deletions docs/pages/access-controls/guides/locking.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -199,7 +199,8 @@ the last known locks. This decision strategy is encoded as one of the two modes:
guaranteed to be up to date
- `best_effort` mode keeps relying on the most recent locks

<ScopedBlock scope={["oss", "enterprise"]}>
<Tabs>
<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">

The cluster-wide mode defaults to `best_effort`. You can set up the default
locking mode via API or CLI using a `cluster_auth_preference` resource or static
Expand Down Expand Up @@ -240,8 +241,8 @@ configuration file:
</TabItem>
</Tabs>

</ScopedBlock>
<ScopedBlock scope={["cloud"]}>
</TabItem>
<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">

The cluster-wide mode defaults to `best_effort`. You can set up the default
locking mode via API or CLI using a `cluster_auth_preference` resource:
Expand All @@ -265,7 +266,9 @@ $ tctl create -f cap.yaml
# cluster auth preference has been updated
```

</ScopedBlock>
</TabItem>

</Tabs>

It is also possible to configure the locking mode for a particular role:

Expand All @@ -285,3 +288,4 @@ there is no user involved, the mode is taken from the cluster-wide setting.
With multiple potentially conflicting locking modes (the cluster-wide default
and the individual per-role settings) a single occurrence of `strict` suffices
for the local lock view to become evaluated strictly.

34 changes: 22 additions & 12 deletions docs/pages/access-controls/guides/passwordless.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,8 @@ between `tsh`, the Teleport Web UI, and different computers.

Authenticate using your passwordless credential:

<ScopedBlock scope={["oss"]}>
<Tabs>
<TabItem scope={["oss"]} label="Teleport Community Edition">
```code
$ tsh login --proxy=example.com --auth=passwordless
# Tap your security key
Expand All @@ -82,8 +83,8 @@ $ tsh login --proxy=example.com --auth=passwordless
# Valid until: 2021-10-04 23:32:29 -0700 PDT [valid for 12h0m0s]
# Extensions: permit-agent-forwarding, permit-port-forwarding, permit-pty
```
</ScopedBlock>
<ScopedBlock scope={["enterprise", "cloud"]}>
</TabItem>
<TabItem scope={["enterprise", "cloud"]} label="Commercial">
```code
$ tsh login --proxy=example.com --auth=passwordless
# Tap your security key
Expand All @@ -96,7 +97,9 @@ $ tsh login --proxy=example.com --auth=passwordless
# Valid until: 2021-10-04 23:32:29 -0700 PDT [valid for 12h0m0s]
# Extensions: permit-agent-forwarding, permit-port-forwarding, permit-pty
```
</ScopedBlock>
</TabItem>

</Tabs>

A fully passwordless cluster defaults to passwordless logins, making
`--auth=passwordless` unnecessary. See the next section to learn how to enable
Expand All @@ -118,7 +121,8 @@ passwordless registration.
To enable passwordless by default, add `connector_name: passwordless` to your
cluster configuration:

<ScopedBlock scope={["oss", "enterprise"]}>
<Tabs>
<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
<Tabs>
<TabItem label="Static Config">
Auth Server `teleport.yaml` file:
Expand Down Expand Up @@ -158,9 +162,9 @@ cluster configuration:
```
</TabItem>
</Tabs>
</ScopedBlock>
</TabItem>

<ScopedBlock scope={["cloud"]}>
<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
Create a `cap.yaml` file or get the existing configuration using
`tctl get cluster_auth_preference`:

Expand All @@ -183,7 +187,9 @@ Update the configuration:
$ tctl create -f cap.yaml
# cluster auth preference has been updated
```
</ScopedBlock>
</TabItem>

</Tabs>

## Troubleshooting

Expand Down Expand Up @@ -257,7 +263,8 @@ $ tsh webauthnwin diag
If you want to forbid passwordless access to your cluster, add `passwordless:
false` to your configuration:

<ScopedBlock scope={["oss", "enterprise"]}>
<Tabs>
<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
<Tabs>
<TabItem label="Static Config">
Auth Server `teleport.yaml` file:
Expand Down Expand Up @@ -298,9 +305,9 @@ false` to your configuration:
```
</TabItem>
</Tabs>
</ScopedBlock>
</TabItem>

<ScopedBlock scope={["cloud"]}>
<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
Create a `cap.yaml` file or get the existing configuration using
`tctl get cluster_auth_preference`:

Expand All @@ -323,4 +330,7 @@ Update the configuration:
$ tctl create -f cap.yaml
# cluster auth preference has been updated
```
</ScopedBlock>
</TabItem>

</Tabs>

Loading