Using the terminal, we will be able to perform all the CLI actions on the server.

Tctl status

We can check the status of the Teleport server by using the tctcl status command, it will give us the information on the Teleport server

The CA pin is needed while configuring the nodes.

Adding a node to teleport cluster

We configured a strong static token for nodes and apps in the teleport.yaml file. We are going to use this token in this step. First, install Teleport on the target node and configure SystemD in the same way we did for the Teleport server enabling and reloading the daemon. Configure the teleport.yaml file for the Teleport agent as below.

vim /etc/teleport.yaml

teleport:

auth_token: f7adb7ccdf0403745trg32ec6010fd6f0caec94ba190v135

# you can also use auth server’s IP, i.e. “10.1.1.10:3025”

auth_servers: [ “10.101.1.150:3025” ]

# Set the ca_pin value so it can verify the Teleport server

ca_pin:

sha256:78cdce6f5a99e8ff0283aa6adbe7b4fb87d60e11e561e60e65f385ce5951bbc2

# enable ssh service and disable auth and proxy:

ssh_service:

enabled: true

labels:

env: dev

auth_service:

enabled: false

proxy_service:

enabled: false

The ca_pin and the auth token is from the auth server / the Teleport server, which we  have configured previously.

Once the configuration is done, start the Teleport service, Teleport will run as a node and will be available in the Teleport server under servers section.

Users and Roles

Users and roles are listed under the team section in the Teleport UI. Here we have configured only Teleport local users and configured them with necessary roles. Roles are configured to give different levels of access to different resources. We use labels to control different resources. Labels can be env, team or anything based on the organization’s requirement.

Sample role is  given below.

dev role with only access to resources with label dev.

kind: role

metadata:

id: 1634021462483125720

name: dev

spec:

allow:

app_labels:

env: dev

db_labels:

env: dev

db_names:

– ‘{{internal.db_names}}’

db_users:

– ‘{{internal.db_users}}’

kubernetes_groups:

– ‘{{internal.kubernetes_groups}}’

kubernetes_labels:

env: dev

kubernetes_users:

– ‘{{internal.kubernetes_users}}’

logins:

– ‘{{internal.logins}}’

– ubuntu

– ec2-user

node_labels:

env: dev

rules:

– resources:

– role

verbs:

– list

– create

– read

– update

– delete

– resources:

– auth_connector

verbs:

– list

– create

– read

– update

– delete

– resources:

– session

verbs:

– list

– read

– resources:

– event

verbs:

– list

– read

– resources:

– user

verbs:

– list

– create

– read

– update

– delete

– resources:

– token

verbs:

– list

– create

– read

– update

– delete

– resources:

– lock

verbs:

– list

– create

– read

– update

– delete

deny: {}

options:

cert_format: standard

enhanced_recording:

– command

– network

forward_agent: true

max_session_ttl: 30h0m0s

port_forwarding: true

version: v3

This role gives access to the resources with label env:dev and the user will have a session ttl of 30h.

Access requests

Teleport has the ability for users to request additional roles. The Access Request API makes it easy to dynamically approve or deny these requests. A user can request or approve an access request once and only if the user has permission. For this, we have defined the following roles.

Access request role:

kind: role

metadata:

id: 1634021882267841227

name: access_request

spec:

allow:

request:

roles:

– editor

– qa

– dev

deny: {}

options:

cert_format: standard

enhanced_recording:

– command

– network

forward_agent: false

max_session_ttl: 30h0m0s

port_forwarding: true

version: v4

This role allows a user to request access for dev, editor and qa roles with a ttl of 30 hrs.

Access request approve role :

kind: role

metadata:

id: 1634021977059094158

name: ar_admin

spec:

allow:

app_labels:

‘*’: ‘*’

db_labels:

‘*’: ‘*’

kubernetes_labels:

‘*’: ‘*’

review_requests:

roles:

– dev

– qa

– editor

rules:

– resources:

– access_request

verbs:

– list

– read

– update

– delete

– resources:

– review

verbs:

– author

– review

deny: {}

options:

cert_format: standard

enhanced_recording:

– command

– network

forward_agent: false

max_session_ttl: 30h0m0s

port_forwarding: true

version: v3

This allows the user to approve access requests for qa, dev and editor. The user can raise an access request from the activity tab in the Teleport UI.

Once the request is raised, the admin/user with the access approves the role from the same activity tab.

Integrating Teleport with Slack

Teleport to Slack integration notifies individuals and channels of Access Requests. As a prerequisite, we need an app in Slack configured for Teleport and a channel which the Teleport bot can access. Check official documentation for configuring the app in Slack.

Export access-plugin certificate using tctl tool

tctl auth sign –format=tls –user=access-plugin –out=auth –ttl=2190h

The above sequence should result in three PEM encoded files being generated: auth.crt, auth.key, and auth.cas (certificate, private key, and CA certs respectively). We’ll reference the auth.crt, auth.key, and auth.cas files later when configuring the plugins.

Install the Teleport-Slack plugin

curl -L https://get.gravitational.com/teleport-access-slack-v7.3.0-linux-amd64-bin.tar.gz

tar -xzf teleport-access-slack-v7.3.0-linux-amd64-bin.tar.gz

cd teleport-access-slack

./install

teleport-slack configure > teleport-slack.toml

sudo mv teleport-slack.toml /etc

Edit the teleport-slack.toml file

vim /etc/teleport-slack.toml

# example Slack plugin configuration TOML file

[teleport]

addr = “auth.example.com:3025”           # Teleport Auth Server GRPC API address

client_key = “/var/lib/teleport/plugins/slack/auth.key” # Teleport GRPC client secret key

client_crt = “/var/lib/teleport/plugins/slack/auth.crt” # Teleport GRPC client certificate

root_cas = “/var/lib/teleport/plugins/slack/auth.cas”   # Teleport cluster CA certs

[slack]

token = “xoxb-11xx”             # Slack Bot OAuth token

# Optional Slack Rooms

recipients = [“team”,”devops”]

[log]

output = “stderr” # Logger output. Could be “stdout”, “stderr” or “/var/lib/teleport/slack.log”

severity = “INFO” # Logger severity. Could be “INFO”, “ERROR”, “DEBUG” or “WARN”.

Enable SystemD for Teleport-Slack

sudo vim /etc/systemd/system/teleport-slack.service

[Unit]

Description=Teleport Slack Plugin

After=network.target

[Service]

Type=simple

Restart=on-failure

ExecStart=/usr/local/bin/teleport-slack start –config=/etc/teleport-slack.toml

ExecReload=/bin/kill -HUP $MAINPID

PIDFile=/run/teleport-slack.pid

[Install]

WantedBy=multi-user.target

Enable and start the service

systemctl enable teleport-slack

systemctl start teleport-slack

Once we start the service, whenever an access request is raised, we will get a notification in our Slack channel.

We can click on the link to be redirected to the access request approval UI of the Teleport server. Once the request is approved or denied, we will get a reply in the thread from the Teleport bot.

Log in using TSH

TSH is a Teleport client tool. It helps us log into Teleport clusters and obtain short-lived credentials. It can also be used to list servers, applications, and Kubernetes clusters registered with Teleport.

Log in to receive short-lived certificates from Teleport

Teleport provides a secure login to its cluster using the TSH tool. Use the following command to login

tsh login –proxy=teleport.example.com –user=teleport-admin

This will prompt for the user password and OTP.

Once logged in, we can list the nodes in the Teleport cluster using the TSH LS command

Commands with TSH tool.

tsh status

tsh ls

tsh ssh root@node-name

Follow us on our LinkedIn Page. To explore our services, visit our website.