Kubernetes
Learn how to dynamically generate Kubernetes service account tokens.
The Infisical Kubernetes dynamic secret allows you to generate short-lived service account tokens on demand.
Overview
The Kubernetes dynamic secret feature enables you to generate short-lived service account tokens for your Kubernetes clusters. This is particularly useful for:
- Secure Access Management: Instead of using long-lived service account tokens, you can generate short-lived tokens that automatically expire, reducing the risk of token exposure.
- Temporary Access: Generate tokens with specific TTLs (Time To Live) for temporary access to your Kubernetes clusters.
- Audit Trail: Each token generation is tracked, providing better visibility into who accessed your cluster and when.
- Integration with Private Clusters: Seamlessly work with private Kubernetes clusters using Infisical’s Gateway feature.
Kubernetes service account tokens cannot be revoked once issued. This is why it’s important to use short TTLs and carefully manage token generation. The tokens will automatically expire after their TTL period.
Kubernetes service account tokens are JWTs (JSON Web Tokens) with a fixed expiration time. Once a token is generated, its lifetime cannot be extended. If you need longer access, you’ll need to generate a new token.
This feature is ideal for scenarios where you need to:
- Provide temporary access to developers or CI/CD pipelines
- Rotate service account tokens frequently
- Maintain a secure audit trail of cluster access
- Manage access to multiple Kubernetes clusters
Prerequisites
- A Kubernetes cluster with a service account
- Cluster access token with permissions to create service account tokens
- (Optional) Gateway for private cluster access
RBAC Configuration
Before you can start generating dynamic service account tokens, you’ll need to configure the appropriate permissions in your Kubernetes cluster. This involves setting up Role-Based Access Control (RBAC) to allow the creation and management of service account tokens.
The RBAC configuration serves a crucial security purpose: it creates a dedicated service account with minimal permissions that can only create and manage service account tokens. This follows the principle of least privilege, ensuring that the token generation process is secure and controlled.
The following RBAC configuration creates the necessary permissions for generating service account tokens:
This configuration:
- Creates a
ClusterRole
namedtokenrequest
that allows:- Creating and getting service account tokens
- Getting service account information
- Creates a
ClusterRoleBinding
that binds the role to a service account namedinfisical-token-requester
in thedefault
namespace
You can customize the service account name and namespace according to your needs.
Obtaining the Cluster Token
After setting up the RBAC configuration, you need to obtain a token for the service account that will be used to create dynamic secrets. Here’s how to get the token:
- Create a service account in your Kubernetes cluster that will be used to create service account tokens:
- Create a long-lived service account token using this configuration file:
- Link the secret to the service account:
- Retrieve the token:
This token will be used as the “Cluster Token” in the dynamic secret configuration.
Obtaining the Cluster URL
The cluster URL is the address of your Kubernetes API server. The simplest way to find it is to use the kubectl cluster-info
command:
This command works for all Kubernetes environments (managed services like GKE, EKS, AKS, or self-hosted clusters) and will show you the Kubernetes control plane address, which is your cluster URL.
Make sure the cluster URL is accessible from where you’re running Infisical. If you’re using a private cluster, you’ll need to configure a Gateway to access it.
Set up Dynamic Secrets with Kubernetes
Open Secret Overview Dashboard
Open the Secret Overview dashboard and select the environment in which you would like to add a dynamic secret.
Click on the 'Add Dynamic Secret' button
Select Kubernetes
Provide the inputs for dynamic secret parameters
Name by which you want the secret to be referenced
Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)
Maximum time-to-live for a generated secret
Select a gateway for private cluster access. If not specified, the Internet Gateway will be used.
Kubernetes API server URL (e.g., https://kubernetes.default.svc)
Whether to enable SSL verification for the Kubernetes API server connection.
Custom CA certificate for the Kubernetes API server. Leave blank to use the system/public CA.
Token with permissions to create service account tokens
Name of the service account to generate tokens for
Kubernetes namespace where the service account exists
Optional list of audiences to include in the generated token
Click 'Submit'
After submitting the form, you will see a dynamic secret created in the dashboard.
Generate dynamic secrets
Once you’ve successfully configured the dynamic secret, you’re ready to generate on-demand service account tokens. To do this, simply click on the ‘Generate’ button which appears when hovering over the dynamic secret item. Alternatively, you can initiate the creation of a new lease by selecting ‘New Lease’ from the dynamic secret lease list section.
When generating these secrets, it’s important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
Ensure that the TTL for the lease fall within the maximum TTL defined when configuring the dynamic secret.
Once you click the Submit
button, a new secret lease will be generated and the service account token will be shown to you.
Audit or Revoke Leases
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard. This will allow you to see the lease details and delete the lease ahead of its expiration time.
While you can delete the lease from Infisical, the actual Kubernetes service account token cannot be revoked. The token will remain valid until its TTL expires. This is why it’s crucial to use appropriate TTL values when generating tokens.