Teleport

Teleport Kubernetes Access for CI/CD

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: v4
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

The examples below may include the use of the sudo keyword, token UUIDs, and users with elevated privileges to make following each step easier.

We recommend you follow the best practices to avoid security incidents:

Avoid using sudo in production environments unless it's necessary.
Create new, non-root, users and use test instances for experimenting with Teleport.
You can run many Teleport's services as a non root. For example, auth, proxy, application access, kubernetes access, and database access services can run as a non-root user. Only the SSH/node service requires root access. 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) and "Zero Admin" best practices. Don't give users permissive roles when giving them more restrictive access,editor roles will do instead.
Save tokens into a file rather than sharing tokens directly as strings.

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

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
The 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