How to configure expiry (TTL) on kubeconfig tokens in Rancher v2.4.6+
This document (000020021) is provided subject to the disclaimer at the end of this document.
In Rancher v2.4.6 and higher, it is possible to configure an expiry (TTL) on Rancher-generated kubeconfig tokens for Rancher managed Kubernetes clusters. This article details how to configure kubeconfig token expiry as a Rancher administrator and how users can authenticate via
kubectl when this is configured.
- A Rancher v2.x instance, from v2.4.6 and higher
Rancher CLIinstalled locally
Disable automatic kubeconfig token generation and configure TTL
As a Rancher global admin, disable automatic kubeconfig token generation and configure the expiry time (TTL) for kubeconfig tokens, per the steps in the Rancher documentation here.
Authenticating via the Rancher CLI with kubectl
Once the kubeconfig TTL has been configured by an admin, users will need to download the Rancher CLI in order to authenticate against Rancher when using Rancher-generated kubeconfig files to connect to Rancher-managed clusters.
- Download the required Rancher CLI binary per the Rancher documentation.
- Ensure the
rancherCLI binary is executable and in your PATH.
- Download a copy of the kubeconfig file for a cluster from the Rancher UI and add it to the default ~/.kube/config file or source it with
kubectl get nodesand observe you will be prompted for your Rancher username and password. If you are using an authentication provider you will also be prompted to select this versus local authentication. You can prevent this prompt by adding the
--auth-provider=<provider>argument in the kubeconfig file, per the following example:
args: - token - --auth-provider=openLdapProvider - --server=rancher.example.com
- After providing the username and password, the kubeconfig token will be generated and valid for the TTL (
kubeconfig-token-ttl-minutes) configured in Rancher.
- You can verify the configured expiry time of the kubeconfig token within the Rancher UI, under
API & Keys.
- Once the token expires, you will be prompted to log in again upon executing
kubectlcommands against the cluster, per step 4.
N.B. By default the generated kubeconfig token is cached within the directory
.cachein the working directory from which you invoke
kubectl, when you are prompted to log in. As a result executing
kubectlfrom a different directory, will re-prompt for authentication and generate a fresh token cache under
.cache. In Rancher CLI v2.4.10+ you can set the token cache location with the environment variable
export RANCHER_CONFIG_DIR=~/.rancherto avoid being prompted for authentication when you change the working directory.
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:000020021
- Creation Date: 06-May-2021
- Modified Date:06-May-2021
- SUSE Rancher
For questions or concerns with the SUSE Knowledgebase please contact: firstname.lastname@example.org