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: 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
sudoin 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
CAP_NET_BIND_SERVICEcapability) to make Teleport listen on a port numbered <
- 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
- 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
teleportcommand that started the agent, e.g., via the
historycommand on a compromised system.
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 Jenkinstctl users add jenkins --roles=robot
Creates a token for 25hrstctl auth sign --user=jenkins --format=kubernetes --out=kubeconfig --ttl=25h
Verify that these credentials have been written to 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