Teleport Kubernetes Access for 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
admin privileges to make following each step easier when creating resources from scratch.
- We discourage using
sudoin production environments unless it's needed.
- We encourage creating new, non-root, users or new test instances for experimenting with Teleport.
- We encourage adherence to the Principle of Least Privilege (PoLP) and Zero Admin best practices. Don't give users the
adminrole when giving them the more restrictive
access,editorroles will do instead.
- Saving tokens into a file rather than sharing tokens directly as strings.
Learn more about Teleport Role-Based Access Control best practices.
kubeconfig using the
jenkins user and its roles using
tctl auth sign:
Create a new local user for Jenkinstctl users add jenkins --roles=robot
Creates a token for 25hrstctl auth sign --user=jenkins --format=kubernetes --out=kubeconfig --ttl=25h
The credentials have been written to kubeconfigcat kubeconfig
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