Teleport

Teleport Kubernetes Access for CI/CD

OpenSource
Enterprise
Cloud

Short-Lived Certs for Kubernetes CI/CD

CI/CD tools like Jenkins can use short-lived certificates to talk to the Kubernetes API.

Create a non-interactive local Teleport user.

Non-interactive users don't have username or password defined and can't log in, but can be used to create credentials.

kind: role
version: v5
metadata:
  name: robot
spec:
  # The allow section declares a list of resource/verb combinations that are
  # allowed for the users of this role. By default, nothing is allowed.
  allow:
    # This field is used for SSH logins. You have to keep 'logins' as a non-empty random value
    # for Kubernetes to work until we fix it.
    logins: ['keep any value here']
    # A list of kubernetes groups to assign
    kubernetes_groups: ['system:masters']
---
kind: user
version: v2
metadata:
  name: jenkins
spec:
  roles:
  - robot

When running Teleport in production, we recommend that you follow the practices below to avoid security incidents. These practices may differ from the examples used in this guide, which are intended for demo environments:

Avoid using sudo in production environments unless it's necessary.
Create new, non-root, users and use test instances for experimenting with Teleport.
Run Teleport's services as a non-root user unless required. Only the SSH Service requires root access. Note that you will need root permissions (or the CAP_NET_BIND_SERVICE capability) to make Teleport listen on a port numbered < 1024 (e.g. 443).
Follow the "Principle of Least Privilege" (PoLP). Don't give users permissive roles when giving them more restrictive roles will do instead. For example, assign users the built-in access,editor roles.
When joining a Teleport resource service (e.g., the Database Service or Application Service) to a cluster, save the invitation token to a file. Otherwise, the token will be visible when examining the teleport command that started the agent, e.g., via the history command on a compromised system.

Generate a kubeconfig using the jenkins user and its roles using tctl auth sign:

Log in to your cluster with tsh so you can use tctl from your local machine.
You can also run tctl on your Auth Service host without running "tsh login"
first.
tsh login --proxy=teleport.example.com --user=myuser
Create a new local user for Jenkins
tctl users add jenkins --roles=robot
Creates a token for 25hrs
tctl auth sign --user=jenkins --format=kubernetes --out=kubeconfig --ttl=25h

Verify that these credentials have been written to kubeconfig:

cat kubeconfig
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZ....
This kubeconfig can now be exported and will provide access to the automation tooling.
Uses kubectl to get pods, using the provided kubeconfig.
kubectl --kubeconfig /path/to/kubeconfig get pods

Short-Lived Certs

Short-lived certificates expire in hours or minutes. You don't have to revoke them if the host gets compromised. Generate a new kubeconfig every hour using tctl or API and publish it to secret storage, like AWS or GCP secret managers.

Have a suggestion or can’t find something?

IMPROVE THE DOCS