
Teleport
Manage Dynamic Configuration Resources with Spacelift
- Version 15.x
- Version 14.x
- Version 13.x
- Version 12.x
- Older Versions
- Available for:
- OpenSource
- Team
- Cloud
- Enterprise
You can use Spacelift with Teleport's Terraform provider to manage dynamic configuration resources via GitOps and infrastructure as code. This gives you an audit trail of changes to your Teleport configuration and a single source of truth for operators to examine.
This guide will show you how to set up the GitOps platform Spacelift with the Teleport Terraform provider. While following this guide, you will create a Teleport user and role with no privileges in order to demonstrate using Spacelift to create dynamic resources.
If you are using another GitOps platform, the setup should be similar:
- Create a Teleport user and role for the GitOps platform with permissions to manage configuration resources.
- Upload a Teleport identify file to the GitOps platform that it will use to authenticate as the Teleport user and role you created.
- Configure the GitOps platform to read from a GitHub repository with a Terraform configuration that tells the Teleport provider where to find your identity file and Teleport Proxy Service.
- Define Teleport configuration resources as Terraform resources within the GitHub repository, prompting the GitOps platform to apply your Terraform configuration.
Prerequisites
-
A running Teleport cluster. For details on how to set this up, see the Getting Started guide.
-
The
tctl
admin tool andtsh
client tool version >= 14.2.0.See Installation for details.
To check version information, run the tctl version
and tsh version
commands.
For example:
tctl versionTeleport v14.2.0 git:api/14.0.0-gd1e081e go1.21
tsh versionTeleport v14.2.0 go1.21
Proxy version: 14.2.0Proxy: teleport.example.com
-
A Teleport Team account. If you don't have an account, sign up to begin your free trial.
-
The Enterprise
tctl
admin tool andtsh
client tool, version >= 14.1.3.You can download these tools from the Cloud Downloads page.
To check version information, run the tctl version
and tsh version
commands.
For example:
tctl versionTeleport Enterprise v14.1.3 git:api/14.0.0-gd1e081e go1.21
tsh versionTeleport v14.1.3 go1.21
Proxy version: 14.1.3Proxy: teleport.example.com
-
A running Teleport Enterprise cluster. For details on how to set this up, see the Enterprise Getting Started guide.
-
The Enterprise
tctl
admin tool andtsh
client tool version >= 14.2.0.You can download these tools by visiting your Teleport account workspace.
To check version information, run the tctl version
and tsh version
commands.
For example:
tctl versionTeleport Enterprise v14.2.0 git:api/14.0.0-gd1e081e go1.21
tsh versionTeleport v14.2.0 go1.21
Proxy version: 14.2.0Proxy: teleport.example.com
-
A Teleport Enterprise Cloud account. If you don't have an account, sign up to begin a free trial of Teleport Team and upgrade to Teleport Enterprise Cloud.
-
The Enterprise
tctl
admin tool andtsh
client tool version >= 14.1.3.You can download these tools from the Cloud Downloads page.
To check version information, run the tctl version
and tsh version
commands.
For example:
tctl versionTeleport Enterprise v14.1.3 git:api/14.0.0-gd1e081e go1.21
tsh versionTeleport v14.1.3 go1.21
Proxy version: 14.1.3Proxy: teleport.example.com
- A Spacelift account with permissions to create stacks.
- A GitHub repository where you will store your Terraform configuration. For the purpose of the demo project we show in this guide, the repository should be empty, though you can use an existing repository connected to Spacelift as well.
- The GitHub app for Spacelift installed for your GitHub repository. Install this app by visiting its page on GitHub.
- 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.tctl
is supported on macOS and Linux machines. For example:If you can connect to the cluster and run thetsh login --proxy=teleport.example.com --user=[email protected]tctl statusCluster teleport.example.com
Version 14.2.0
CA pin sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
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.
For simplicity, the identify file we will export in this guide will have a long time to live. In a production environment, you will want to provision short-lived identify files via Machine ID.
After getting familiar with this guide, read our Machine ID Getting Started
Guide to get started with Machine ID. You
will need to run your own compute workload to upload Teleport identity files to
Spacelift using the spacectl stack environment mount
command of the
spacectl
CLI (or another method
that takes advantage of Spacelift's GraphQL API).
Step 1/4. Add a Terraform configuration to your repository
Clone your GitHub repository. Add the following to a file called main.tf
,
which configures the Teleport Terraform provider:
terraform {
required_providers {
teleport = {
source = "terraform.releases.teleport.dev/gravitational/teleport"
version = ">= 14.2.0"
}
}
}
provider "teleport" {
addr = "proxy.example.com:443"
identity_file_path = "/mnt/workspace/auth.pem"
}
Change proxy.example.com:443
to the host and HTTPS port of your Teleport Proxy
Service.
Commit the change, merge it to your main
branch, and push to your remote
repository (or use a pull request).
Step 2/4. Create a Spacelift stack
From the Spacelift web UI, click Stacks > Add stack.
In the NAME STACK tab, for "Name", use "Teleport" and click CONTINUE.
In the INTEGRATE VCS tab, make sure the Repository field points to the repository you chose for this guide. Select your GitHub repository and the branch you plan to use as the base branch for pull requests. Click CONTINUE.
In the CONFIGURE BACKEND tab, leave all settings at their defaults and click CONTINUE. Do the same with the DEFINE BEHAVIOR tab and click SAVE STACK.
Your new stack should resemble the following:
Step 3/4. Grant Teleport permissions to Spacelift
In this section, you will create a Teleport user and role for Spacelift, plus a role that can impersonate the Spacelift user in order to export an identity file. You will then export an identity file and upload it to Spacelift.
Since Teleport manages RBAC permissions via configuration resources, and you have not set up Spacelift yet, you must create the resources in this section outside of Spacelift. After that, Spacelift can manage all of your Teleport configuration resources.
Create a Spacelift user and role
Create a local Teleport user named spacelift
and a matching role granting the
necessary permissions for Terraform to manage resources in your cluster.
On your workstation, outside the git repository you connected to Spacelift,
add the following content to a file called spacelift.yaml
:
kind: role
metadata:
name: spacelift
spec:
allow:
rules:
- resources:
- role
- user
verbs: ['list','create','read','update','delete']
version: v6
---
kind: user
metadata:
name: spacelift
spec:
roles: ['spacelift']
version: v2
This is a minimal version of the configuration you will need to provide to Spacelift, and is only permitted to manage Teleport roles.
Create the spacelift
user and role.
tctl create spacelift.yamlrole 'spacelift' has been createduser "spacelift" has been created
Enable impersonation
The spacelift
user cannot log in to Teleport to retrieve credentials, so
another user must impersonate this user in order to request credentials on
spacelift
's behalf.
Create a role that enables your user to impersonate the Terraform user. Paste
the following YAML document into a file called spacelift-impersonator.yaml
:
kind: role
version: v6
metadata:
name: spacelift-impersonator
spec:
allow:
impersonate:
users: ['spacelift']
roles: ['spacelift']
Next, create the role:
tctl create spacelift-impersonator.yaml
Assign the spacelift-impersonator
role to your Teleport user by running the appropriate
commands for your authentication provider:
-
Retrieve your local user's configuration resource:
tctl get users/$(tsh status -f json | jq -r '.active.username') > out.yaml -
Edit
out.yaml
, addingspacelift-impersonator
to the list of existing roles:roles: - access - auditor - editor + - spacelift-impersonator
-
Apply your changes:
tctl create -f out.yaml -
Sign out of the Teleport cluster and sign in again to assume the new role.
-
Retrieve your
github
authentication connector:tctl get github/github --with-secrets > github.yamlNote that the
--with-secrets
flag adds the value ofspec.signing_key_pair.private_key
to thegithub.yaml
file. Because this key contains a sensitive value, you should remove the github.yaml file immediately after updating the resource. -
Edit
github.yaml
, addingspacelift-impersonator
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 + - spacelift-impersonator
-
Apply your changes:
tctl create -f github.yaml -
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
, addingspacelift-impersonator
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 + - spacelift-impersonator
-
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
, addingspacelift-impersonator
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 + - spacelift-impersonator
-
Apply your changes:
tctl create -f oidc.yaml -
Sign out of the Teleport cluster and sign in again to assume the new role.
Export an identity file
Like all Teleport users, spacelift
needs signed credentials in order to
connect to your Teleport cluster. You will use the tctl auth sign
command to
request these credentials.
The following tctl auth sign
command impersonates the spacelift
user,
generates signed credentials, and writes an identity file to the local
directory:
tctl auth sign --user=spacelift --out=auth.pem
Spacelift connects to the Teleport Auth Service's gRPC endpoint over TLS.
The identity file, auth.pem
, includes both TLS and SSH credentials. Spacelift
uses the SSH credentials to connect to the Proxy Service, which establishes a
reverse tunnel connection to the Auth Service. Spacelift uses this reverse
tunnel, along with your TLS credentials, to connect to the Auth Service's gRPC
endpoint.
By default, tctl auth sign
produces certificates with a relatively short
lifetime. For production deployments, we suggest using Machine
ID to programmatically issue and renew
certificates for your plugin. See our Machine ID getting started
guide to learn more.
Note that you cannot issue certificates that are valid longer than your existing credentials.
For example, to issue certificates with a 1000-hour TTL, you must be logged in with a session that is
valid for at least 1000 hours. This means your user must have a role allowing
a max_session_ttl
of at least 1000 hours (60000 minutes), and you must specify a --ttl
when logging in:
tsh login --proxy=teleport.example.com --ttl=60060
Provide an identity file to Spacelift
In the Spacelift web UI, click Stacks > Teleport. Click the Environment
tab, then Edit. Set the dropdown menu that follows to Mounted file, and
the path to /mnt/workspace/auth.pem
.
Click Upload file and select the file called auth.pem
that you exported
earlier.
Make sure you click Secret next to the entry for the mounted file:
Step 4/4. Declare configuration resources
In a clone of your GitHub repository, check out a branch from your main branch
and add the following to main.tf
:
resource "teleport_role" "terraform_test" {
metadata = {
name = "terraform-test"
description = "Terraform test role"
labels = {
example = "yes"
}
}
}
resource "teleport_user" "terraform-test" {
metadata = {
name = "terraform-test"
description = "Terraform test user"
labels = {
test = "true"
}
}
spec = {
roles = [teleport_role.terraform_test.id]
}
}
Commit your changes and push the branch to GitHub, then open a pull request
against the main
branch. (Do not merge it just yet.)
In the Spacelift UI, click Stacks > Teleport > PRs, then click the name of the PR you opened.
You should see a Terraform plan that includes the user and role you defined above:
When running terraform plan
, Spacelift uses the identity file you mounted
earlier to authenticate to Teleport.
Merge the PR, then click Stacks > Teleport > Runs. Click the status of the first run, which corresponds to merging your PR, to visit the page for the run. Click Confirm to begin applying your Terraform plan.
You should see output indicating success:
Verify that Spacelift has created the new user and role by running the following commands, which should return YAML data for each resource:
tctl get roles/terraform-testtctl get users/terraform-test
Next steps
- If you plan to configure Spacelift to manage dynamic configuration resources besides users and roles, you will need to grant additional permissions to the Teleport role you assigned to Spacelift. See the Teleport Role Reference for the resources you can allow access to in a Teleport role.
- Now that you know how to manage Teleport configuration resources with Terraform and Spacelift, read our Terraform resource reference so you can flesh out your configuration.
- The Teleport Terraform provider is an example of a Teleport API client. Other API clients include Teleport's Access Request plugins and the Event Handler. Learn how to build your own API client so you can manage Teleport configuration resources via your organization's unique workflows.