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

Improve access graph documentation #49314

Merged
merged 4 commits into from
Nov 25, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
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
8 changes: 8 additions & 0 deletions docs/pages/admin-guides/teleport-policy/crown-jewels.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,14 @@ Crown Jewels, and how to see permission changes for these resources.

## Prerequisites

<Notice type="tip">

For an improved experience, we recommend using Crown Jewels in conjunction with Teleport local users or integrating with
[Okta](../../enroll-resources/application-access/okta/okta.mdx) or [Microsoft Entra ID](./integrations/entra-id.mdx).
This setup helps mitigate the spam generated by highly privileged ephemeral users created by Teleport Auth Connectors.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "spam" mean in this case? To me, this sounds a little judgmental towards a Teleport feature, which seems out of place in documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spam refers to an excessive number of entries. When a user with access to all resources logs in using a standard connector, it generates N access path changes, where N is the number of resources they have access to.


</Notice>

- A running Teleport Enterprise cluster v16.2.0 or later.
- For self-hosted clusters, an updated `license.pem` with Teleport Policy enabled.
- For self-hosted clusters, a running Access Graph node v1.24.0 or later.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -152,6 +152,30 @@ Insecure paths are also visible in a user's access paths. To view them, click on
from the context menu. This will show the Teleport permissions granted to the user, the resources they can access,
and any detected insecure paths.

**Access Graph: Dedicated `ssh_keys` SQL View**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is a section heading, I would use header syntax (#+) instead of bold text.


Starting in version **v1.25.0**, Access Graph introduces a dedicated `ssh_keys` SQL view for managing SSH access paths.
This view excludes access paths granted through Teleport and focuses on:
- Displaying identified access paths between identities and SSH nodes.
- Listing existing SSH Authorized Keys configured for nodes, even if `tsh scan keys` fails to detect matching SSH private keys.
tigrato marked this conversation as resolved.
Show resolved Hide resolved

Below are a few example queries demonstrating how the `ssh_keys` view can be useful for identifying potential backdoors.

- List all SSH access paths for Teleport SSH nodes and users:
```sql
SELECT * FROM ssh_keys;
```

- View insecure access paths and SSH Authorized Keys for a specific node:
```sql
SELECT * FROM ssh_keys WHERE resource='<Var name="resource name" />';
```

- View insecure access paths and SSH Authorized Keys for a subset of nodes using labels:
```sql
SELECT * FROM ssh_keys WHERE resource_labels @> '{"env": "dev"}';
```


## Jamf Pro Integration

Expand Down
Loading