Teleport
Deploy Login Rules via Terraform
- Edge version
- Version 17.x
- Version 16.x
- Version 15.x
- Older Versions
This guide will explain how to:
- Use Teleport's Terraform Provider to deploy Login Rules to your Teleport cluster
- Edit deployed Login Rules via Terraform
Prerequisites
-
A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial.
-
The
tctl
admin tool andtsh
client tool.Visit Installation for instructions on downloading
tctl
andtsh
.
-
To check that you can connect to your Teleport cluster, sign in with
tsh login
, then verify that you can runtctl
commands using your current credentials.For example:
tsh login --proxy=teleport.example.com --user=[email protected]tctl statusCluster teleport.example.com
Version 16.4.8
CA pin sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
If you can connect to the cluster and run the
tctl status
command, you can use your current credentials to run subsequenttctl
commands from your workstation. If you host your own Teleport cluster, you can also runtctl
commands on the computer that hosts the Teleport Auth Service for full permissions. -
terraform version
Terraform v1.0.0
Step 1/4. Set up Teleport credentials for Terraform
For simplicity, this guide will configure the Terraform provider to use your
current logged-in user's Teleport credentials obtained from tsh login
.
The Terraform provider guide
includes instructions for configuring a dedicated terraform
user and role,
which is a better option when running Terraform in a non-interactive
environment.
If you are already using Terraform to manage other resources in your Teleport
cluster then you have probably already set up a terraform
user and role and
configured the associated credentials.
Make sure to use the terraform
role from the latest version of the guide,
which has list
, read
, create
, update
, and delete
verbs for
login_rule
resources.
First, ensure you are logged into Teleport as a user that has permissions to
read and modify login_rule
resources.
The preset editor
role has access to this already, but in case you are using a
more customized configuration, create a role called loginrule-manager.yaml
with the following contents:
kind: role
metadata:
name: loginrule-manager
spec:
allow:
rules:
- resources: [login_rule]
verbs: [list, read, create, update, delete]
version: v7
Create the role with tctl
:
tctl create loginrule-manager.yamlrole 'loginrule-manager' has been created
Assign the loginrule-manager
role to your Teleport user by running the appropriate
commands for your authentication provider:
-
Retrieve your local user's roles as a comma-separated list:
ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")') -
Edit your local user to add the new role:
tctl users update $(tsh status -f json | jq -r '.active.username') \ --set-roles "${ROLES?},loginrule-manager" -
Sign out of the Teleport cluster and sign in again to assume the new role.
-
Open your
github
authentication connector in a text editor:tctl edit github/github -
Edit the
github
connector, addingloginrule-manager
to theteams_to_roles
section.The team you should map to this role depends on how you have designed your organization's role-based access controls (RBAC). However, the team must include your user account and should be the smallest team possible within your organization.
Here is an example:
teams_to_roles: - organization: octocats team: admins roles: - access + - loginrule-manager
-
Apply your changes by saving closing the file in your editor.
-
Sign out of the Teleport cluster and sign in again to assume the new role.
-
Retrieve your
saml
configuration resource:tctl get --with-secrets saml/mysaml > saml.yamlNote that the
--with-secrets
flag adds the value ofspec.signing_key_pair.private_key
to thesaml.yaml
file. Because this key contains a sensitive value, you should remove the saml.yaml file immediately after updating the resource. -
Edit
saml.yaml
, addingloginrule-manager
to theattributes_to_roles
section.The attribute you should map to this role depends on how you have designed your organization's role-based access controls (RBAC). However, the group must include your user account and should be the smallest group possible within your organization.
Here is an example:
attributes_to_roles: - name: "groups" value: "my-group" roles: - access + - loginrule-manager
-
Apply your changes:
tctl create -f saml.yaml -
Sign out of the Teleport cluster and sign in again to assume the new role.
-
Retrieve your
oidc
configuration resource:tctl get oidc/myoidc --with-secrets > oidc.yamlNote that the
--with-secrets
flag adds the value ofspec.signing_key_pair.private_key
to theoidc.yaml
file. Because this key contains a sensitive value, you should remove the oidc.yaml file immediately after updating the resource. -
Edit
oidc.yaml
, addingloginrule-manager
to theclaims_to_roles
section.The claim you should map to this role depends on how you have designed your organization's role-based access controls (RBAC). However, the group must include your user account and should be the smallest group possible within your organization.
Here is an example:
claims_to_roles: - name: "groups" value: "my-group" roles: - access + - loginrule-manager
-
Apply your changes:
tctl create -f oidc.yaml -
Sign out of the Teleport cluster and sign in again to assume the new role.
Step 2/4. Create a Terraform configuration
Paste the following into a file called main.tf
to configure the Terraform
provider and create two example Login Rules.
Make sure to update the addr = "teleport.example.com:443"
field with the
public address of your Teleport Proxy.
terraform {
required_providers {
teleport = {
source = "terraform.releases.teleport.dev/gravitational/teleport"
version = "~> 16.0"
}
}
}
provider "teleport" {
# Update addr to point to your Teleport proxy
addr = "teleport.example.com:443"
# Setting profile_dir and profile_name to empty strings will cause the
# Terraform provider to authenticate using the current logged-in tsh profile
profile_dir = ""
profile_name = ""
}
resource "teleport_login_rule" "terraform-test-map-rule" {
metadata = {
name = "terraform-test-map-rule"
description = "Terraform test rule using traits_map"
labels = {
example = "yes"
}
}
version = "v1"
# The rule with the lowest priority will be evaluated first.
priority = 0
# traits_map holds a map of all desired trait keys to list ofexpressions to
# determine the trait values.
traits_map = {
# The "logins" traits will be set to the external "username" trait converted
# to lowercase, as well as any external "logins" trait.
"logins" = {
# The traits_map value must be an object holding the expressions list in a
# "values" field
values = [
"strings.lower(external.username)",
"external.logins",
]
}
# The external "groups" trait will be passed through unchanged, all other
# traits will be filtered out.
"groups" = {
values = [
"external.groups",
]
}
}
}
resource "teleport_login_rule" "terraform-test-expression-rule" {
metadata = {
name = "terraform-test-expression-rule"
description = "Terraform test rule using traits_expression"
labels = {
example = "yes"
}
}
version = "v1"
# This rule has a higher priority value, so it will be evaluated after the
# "terraform-test-map-rule".
priority = 1
# traits_expression is an alternative to traits_map, which returns all desired
# traits in a single expression. The EOT syntax is a way of writing a
# multiline string in Terraform, it is not part of the expression.
traits_expression = <<-EOT
external.put("groups",
choose(
option(external.groups.contains("admins"), external.groups.add("app-admins", "db-admins")),
option(external.groups.contains("ops"), external.groups.add("k8s-admins")),
option(true, external.groups)))
EOT
}
Step 3/4. Apply the configuration
Init Terraform and apply the configuration:
terraform initterraform apply
Step 4/4. Make sure everything worked
Double-check that the new Login Rules are now available in your cluster:
tctl get login_ruleskind: login_rulemetadata: description: Terraform test rule using traits_expression id: 1680190764978381000 labels: example: "yes" name: terraform-test-expression-rulespec: priority: 1 traits_expression: | external.put("groups", choose( option(external.groups.contains("admins"),external.groups.add("app-admins", "db-admins")), option(external.groups.contains("ops"),external.groups.add("k8s-admins")), option(true, external.groups)))version: v1---kind: login_rulemetadata: description: Terraform test rule using traits_map id: 1680193055097268000 labels: example: "yes" name: terraform-test-map-rulespec: priority: 0 traits_map: groups: - external.groups logins: - strings.lower(external.username) - external.loginsversion: v1
Test the Login Rules you just installed with the tctl login_rule test
command.
The --load-from-cluster
flag tells the command to load all Login Rules
currently installed in the cluster.
You can send example traits to the standard input of the command, and it will
print the final traits after transformation by the Login Rules.
echo '{"groups": ["admins", "ops"], "username": ["Alice"], "logins": ["user", "root"]}' | \ tctl login_rule test --load-from-clustergroups:- admins- ops- app-admins- db-adminslogins:- alice- user- root
Next Steps
- Read the Terraform Guide to learn more about configuring the Terraform provider.
- Read the Login Rules reference to learn mode about the Login Rule expression syntax.