Teleport Access Requests
You can set up Teleport to require require the approval of multiple team members to perform some critical actions. Here are the most common scenarios:
- Improve security of your system and prevent one successful phishing attack from compromizing your system.
- Satisfy FedRamp AC-3 Dual authorization control that requires approval of two authorized individuals.
Let's set up Teleport's access requests to require approval of
two team members for a privileged role
- Installed Teleport Enterprise or Teleport Cloud >= 7.1.3
- Tctl enterprise admin tool >= 7.1.3
- Mattermost installed.
docker run --name mattermost-preview -d --publish 8065:8065 --add-host dockerhost:127.0.0.1 mattermost/mattermost-preview
Verify that your Teleport client is connected:
$ tctl status # Cluster tele.example.com # Version 7.1.3 # CA pin sha256:sha-hash-here
To try this flow in the cloud, login into your cluster using tsh, then use tctl remotely:
$ tsh login --proxy=myinstance.teleport.sh $ tctl status
Enable bot account creation in "System Console -> Integrations".
Enable Bot Account Creation.
Go back to your team settings, navigate to "Integrations -> Bot Accounts". Press "Add Bot Account".
Add the "Post All" permission on the new account.
Create the bot and save the access token.
Create a non-interactive bot
access-plugin user and role.
kind: user metadata: name: access-plugin spec: roles: ['access-plugin'] version: v2 kind: role version: v4 metadata: name: access-plugin spec: allow: rules: - resources: ['access_request'] verbs: ['list', 'read'] - resources: ['access_plugin_data'] verbs: ['update'] # teleport currently refuses to issue certs for a user with 0 logins, # this restriction may be lifted in future versions. logins: ['access-plugin-not-used']
Here and below follow along and create yaml resources using
tctl create -f:
tctl create -f access.yaml
Export access-plugin cert
Teleport Plugin uses the
access-plugin role and user to perform the approval.
We export the identify files, using
tctl auth sign.
tctl auth sign --format=tls --user=access-plugin --out=auth --ttl=720h
Teleport will generate
auth.cas - a certificate, a private key, and a set of CA certs respectively.
Install the plugin
curl -L https://get.gravitational.com/teleport-access-mattermost-v7.1.3-linux-amd64-bin.tar.gztar -xzf teleport-access-mattermost-v7.1.3-linux-amd64-bin.tar.gzcd teleport-access-mattermost./install
teleport-mattermost configure > /etc/teleport-mattermost.toml
Update the config with Teleport address, Mattermost URL, and a bot token.
# example mattermost configuration TOML file [teleport] auth_server = "example.com:3025" # Teleport Auth Server GRPC API address client_key = "/var/lib/teleport/plugins/mattermost/auth.key" # Teleport GRPC client secret key client_crt = "/var/lib/teleport/plugins/mattermost/auth.crt" # Teleport GRPC client certificate root_cas = "/var/lib/teleport/plugins/mattermost/auth.cas" # Teleport cluster CA certs [mattermost] url = "https://mattermost.example.com" # Mattermost Server URL team = "team-name" # Mattermsot team in which the channel resides. channel = "channel-name" # Mattermost Channel name to post requests to token = "api-token" # Mattermost Bot OAuth token secret = "signing-secret-value" # Mattermost API signing Secret [http] public_addr = "example.com" # URL on which callback server is accessible externally, e.g. [https://]teleport-mattermost.example.com # listen_addr = ":8081" # Network address in format [addr]:port on which callback server listens, e.g. 0.0.0.0:443 https_key_file = "/var/lib/teleport/plugins/mattermost/server.key" # TLS private key https_cert_file = "/var/lib/teleport/plugins/mattermost/server.crt" # TLS certificate [log] output = "stderr" # Logger output. Could be "stdout", "stderr" or "/var/lib/teleport/mattermost.log" severity = "INFO" # Logger severity. Could be "INFO", "ERROR", "DEBUG" or "WARN".
Alice and Ivan are reviewers - they can approve requests for assuming role
Bob is a devops and can assume
dbadmin role if two members of the
approved the request.
kind: role version: v4 metadata: name: reviewer spec: allow: review_requests: roles: ['dbadmin'] kind: role version: v4 metadata: name: devops spec: allow: request: roles: ['dbadmin'] thresholds: - approve: 2 deny: 1 kind: role version: v4 metadata: name: dbadmin spec: allow: logins: ['root'] node_labels: 'env': 'prod' 'type': 'db'
Example below creates local users Alice, Ivan and Bob.
Bob does not have a role
dbadmin assigned to him, but can create an access request for it.
Bob can create an access request for the
dbadmin role in the Web UI or CLI:
Chatbot will notify both Alice and Ivan:
Alice and Ivan can review and approve request using Web UI or CLI:
If Bob has created a request using CLI, he will assume it once it has been approved. Bob can also assume granted access request roles using Web UI:
You may be getting certificate errors if Teleport's auth server is missing an address in the server certificate:
authentication handshake failed: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs
x509: certificate is valid for,*.teleport.cluster.local, teleport.cluster.local, not example.com
To fix the problem, update the auth service with a public address, and restart Teleport:
auth_service: public_addr: ['localhost:3025', 'example.com:3025']