Teleport

​

What Oleria discovers

• Users - every local user, and every SSO user that currently has a session, with their roles. A user is shown as disabled while a Teleport lock targets them or one of their roles, or after their account expires. A lock that only blocks one login, device, or desktop is shown in the user’s details instead. Oleria also shows:
  • whether the user has set a password, and when a pending invitation expires
  • their SSO connector, for users created by a SAML, OIDC, or GitHub connector
  • MFA status, from the cluster’s second factor setting. When the cluster requires a second factor, Teleport is the MFA authority and MFA is shown as enabled; a user with no MFA device enrolled is shown as enrollment required. When the second factor is optional or off, MFA is shown as not required. For SSO users without a Teleport MFA device, MFA is handled by the identity provider.
  • administrators: users who hold a role that can create or update users or roles
  • who created the user, and when
  • their last sign-in and last password change, from the audit log of the last 30 days
  • the users they can impersonate, from the impersonate rules of their roles. Machine ID bots are checked the same way. Rules with a where condition aren’t counted.
• Groups - each access list is shown as a group, with its user members, its nested access lists, and the access list owners. Membership expiry dates are shown on the membership.
• Roles - every Teleport role, marked as preset, system, or custom. Oleria shows the roles assigned directly to users and bots, and the roles each access list grants to its members.
• Non-human identities (NHIs):
  • Service accounts - Machine ID bots, with their roles, who created them, and when they last authenticated.
  • API tokens - join tokens that use the token join method. Oleria never shows the token value: the name is masked the same way Teleport masks it.
  • SSH keys - join tokens that use the bound_keypair join method, with the fingerprint of the registered public key.
  • Federated credentials - join tokens that use a cloud or CI identity, such as iam, github, or kubernetes.
  • System - Teleport’s own system users, such as @teleport-access-approval-bot, and the join tokens Teleport uses for its own infrastructure.
  Each join token is also shown as a credential with its expiry date, linked to the bot it lets join. When Teleport records it, Oleria also shows when the token was last used to join.
• Activity - events from the Teleport audit log, such as:
  • sign-ins and failed sign-ins, including the MFA device used and the client IP address
  • bot joins
  • SSH, application, and database session starts
  • user, role, bot, and access list changes
  • access list membership changes, access requests, and access request reviews
  • locks created and removed
  • join token creation, password changes and resets, and MFA enrollments
  • changes to the cluster’s authentication settings
  Oleria leaves out the join and certificate events of the bot this integration connects as. Changes that bot makes, including remediation actions, are shown.

​

Prerequisites

• A Teleport Enterprise Cloud tenant or a self-hosted Teleport cluster running version 18 or later.
• A Teleport user who can create roles, bots, and join tokens, with tctl and tbot installed.
• Admin access on the Oleria platform to add a new integration.

​

Permissions

​

Create a bot in Teleport

kind: role
version: v8
metadata:
  name: oleria-reader
spec:
  allow:
    rules:
    - resources: [user, role, access_list, bot, bot_instance, token, lock, event, cluster_auth_preference]
      verbs: [list, read]
---
kind: bot
version: v1
metadata:
  name: oleria
spec:
  roles: [oleria-reader]
---
kind: token
version: v2
metadata:
  name: oleria-bkp
spec:
  bot_name: oleria
  join_method: bound_keypair
  roles: [Bot]
  bound_keypair:
    onboarding:
      initial_public_key: ssh-ed25519 AAAA...
    recovery:
      limit: 0
      mode: insecure

​

Connect Teleport to Oleria

​

Edit the connection

​

Verify the integration

​

Remediation actions

• Disabling the bot this integration connects as, or deleting its join token.
• Disabling, deleting, or revoking the sessions of a Machine ID bot with a user action. Use Disable NHI accounts instead.
• Changing the roles of a Machine ID bot. Bot roles are managed on the bot.
• Changing the roles of an SSO user. The SSO connector sets their roles at every sign-in, so change the connector’s role mapping instead.
• Deleting an SSO user. The SSO connector creates the user again at every sign-in, so remove the person in your identity provider instead.
• Disabling, deleting, or changing the roles of Teleport’s system users, or revoking their sessions.
• Removing the bot this integration connects as from an access list.
• Enabling a user who is blocked by a lock on one of their roles, because that lock also blocks everyone else with the role. Remove the role lock in Teleport instead.
• Deleting the join tokens Teleport uses for its own proxy and auth services.
• Changing members of an access list that’s managed by SCIM.

• If the user is already in the requested state, or a user to delete no longer exists, the action succeeds without making a change, and there’s nothing to revert.
• A lock blocks new sessions and certificates for the user or bot. It doesn’t change their roles.
• Revoke user sessions signs the user out of the Web UI and applications, but certificates already issued to tsh or tbot stay valid until they expire. To block those too, use Disable user accounts.

​

Known limitations

• Last sign-in and password change look back 30 days. Teleport doesn’t store these dates on users, so Oleria reads them from the audit log of the last 30 days. Older ones are left empty. Sign-ins still appear as activity.
• Access lists need Teleport Enterprise. On a cluster without access lists, such as Community Edition, Oleria discovers no groups, and the group actions aren’t available.
• Teleport is the MFA authority for SSO users too. When the cluster requires a second factor, Teleport is listed as the MFA authority for every user, including SSO users whose MFA is handled by their identity provider.
• Infrastructure resources aren’t discovered. Nodes, applications, databases, Kubernetes clusters, and desktops enrolled in Teleport aren’t shown.
• Each sync creates a bot instance. The bot joins your cluster at the start of each sync and action, so Teleport lists a new bot instance for each join. Bot instances expire on their own.
• SSO users without a session aren’t listed. Teleport creates SSO users when they sign in and removes them when their session expires, so Oleria only sees SSO users with a current session. Your identity provider integration remains the source for those people.
• Login lockouts aren’t shown as disabled. A user temporarily locked out after failed sign-ins is still shown as enabled, with the lockout end time in their profile details.
• Self-hosted clusters need allowlisting. Oleria can connect to *.teleport.sh hosts. For a self-hosted proxy, contact support@oleria.com to add its host before you connect.

​

Contact us