Using the InfisicalDynamicSecret CRD
Learn how to generate dynamic secret leases in Infisical and sync them to your Kubernetes cluster.
Overview
The InfisicalDynamicSecret CRD allows you to easily create and manage dynamic secret leases in Infisical and automatically sync them to your Kubernetes cluster as native Kubernetes Secret resources. This means any Pod, Deployment, or other Kubernetes resource can make use of dynamic secrets from Infisical just like any other K8s secret.
This CRD offers the following features:
- Generate a dynamic secret lease in Infisical and track its lifecycle.
- Write the dynamic secret from Infisical to your cluster as native Kubernetes secret.
- Automatically rotate the dynamic secret value before it expires to make sure your cluster always has valid credentials.
- Optionally trigger redeployments of any workloads that consume the secret if you enable auto-reload.
Prerequisites
- A project within Infisical.
- A machine identity ready for use in Infisical that has permissions to create dynamic secret leases in the project.
- You have already configured a dynamic secret in Infisical.
- The operator is installed on to your Kubernetes cluster.
Configure Dynamic Secret CRD
The example below shows a sample InfisicalDynamicSecret CRD that creates a dynamic secret lease in Infisical, and syncs the lease to your Kubernetes cluster.
Apply the InfisicalDynamicSecret CRD to your cluster.
After applying the InfisicalDynamicSecret CRD, you should notice that the dynamic secret lease has been created in Infisical and synced to your Kubernetes cluster. You can verify that the lease has been created by doing:
After getting the secret, you should should see that the secret has data that contains the lease credentials.
InfisicalDynamicSecret CRD properties
hostAPI
hostAPI
If you are fetching secrets from a self-hosted instance of Infisical set the value of hostAPI
to
https://your-self-hosted-instace.com/api
When hostAPI
is not defined the operator fetches secrets from Infisical Cloud.
Advanced use case
Advanced use case
If you have installed your Infisical instance within the same cluster as the Infisical operator, you can optionally access the Infisical backend’s service directly without having to route through the public internet. To achieve this, use the following address for the hostAPI field:
Make sure to replace <backend-svc-name>
and <namespace>
with the appropriate values for your backend service and namespace.
leaseTTL
leaseTTL
The leaseTTL
is a string-formatted duration that defines the time the lease should last for the dynamic secret.
The format of the field is [duration][unit]
where duration
is a number and unit
is a string representing the unit of time.
The following units are supported:
s
for seconds (must be at least 5 seconds)m
for minutesh
for hoursd
for days
The lease duration at most be 1 day (24 hours). And the TTL must be less than the max TTL defined on the dynamic secret.
managedSecretReference
managedSecretReference
The managedSecretReference
field is used to define the Kubernetes secret where the dynamic secret lease should be stored. The required fields are secretName
and secretNamespace
.
managedSecretReference.secretName
managedSecretReference.secretName
The name of the Kubernetes secret where the dynamic secret lease should be stored.
managedSecretReference.secretNamespace
managedSecretReference.secretNamespace
The namespace of the Kubernetes secret where the dynamic secret lease should be stored.
managedSecretReference.creationPolicy
managedSecretReference.creationPolicy
Creation policies allow you to control whether or not owner references should be added to the managed Kubernetes secret that is generated by the Infisical operator. This is useful for tools such as ArgoCD, where every resource requires an owner reference; otherwise, it will be pruned automatically.
Available options
Orphan
(default)Owner
When creation policy is set to Owner
, the InfisicalSecret
CRD must be in
the same namespace as where the managed kubernetes secret.
This field is optional.
managedSecretReference.secretType
managedSecretReference.secretType
Override the default Opaque type for managed secrets with this field. Useful for creating kubernetes.io/dockerconfigjson secrets.
This field is optional.
leaseRevocationPolicy
leaseRevocationPolicy
The field is optional and will default to None
if not defined.
The lease revocation policy defines what the operator should do with the leases created by the operator, when the InfisicalDynamicSecret CRD is deleted.
Valid values are None
and Revoke
.
Behavior of each policy:
None
: The operator will not override existing secrets in Infisical. If a secret with the same key already exists, the operator will skip pushing that secret, and the secret will not be managed by the operator.Revoke
: The operator will revoke the leases created by the operator when the InfisicalDynamicSecret CRD is deleted.
dynamicSecret
dynamicSecret
The dynamicSecret
field is used to specify which dynamic secret to create leases for. The required fields are secretName
, projectId
, secretsPath
, and environmentSlug
.
dynamicSecret.secretName
dynamicSecret.secretName
The name of the dynamic secret.
dynamicSecret.projectId
dynamicSecret.projectId
The project ID of where the dynamic secret is stored in Infisical.
dynamicSecret.environmentSlug
dynamicSecret.environmentSlug
The environment slug of where the dynamic secret is stored in Infisical.
dynamicSecret.secretsPath
dynamicSecret.secretsPath
The path of where the dynamic secret is stored in Infisical. The root path is
/
.
authentication
authentication
The authentication
field dictates which authentication method to use when pushing secrets to Infisical.
The available authentication methods are universalAuth
, kubernetesAuth
, awsIamAuth
, azureAuth
, gcpIdTokenAuth
, and gcpIamAuth
.
universalAuth
universalAuth
The universal authentication method is one of the easiest ways to get started with Infisical. Universal Auth works anywhere and is not tied to any specific cloud provider. Read more about Universal Auth.
Valid fields:
identityId
: The identity ID of the machine identity you created.credentialsRef
: The name and namespace of the Kubernetes secret that stores the service token.credentialsRef.secretName
: The name of the Kubernetes secret.credentialsRef.secretNamespace
: The namespace of the Kubernetes secret.
Example:
kubernetesAuth
kubernetesAuth
The Kubernetes machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used within a Kubernetes environment. Read more about Kubernetes Auth. Valid fields:
identityId
: The identity ID of the machine identity you created.serviceAccountRef
: The name and namespace of the service account that will be used to authenticate with Infisical.serviceAccountRef.name
: The name of the service account.serviceAccountRef.namespace
: The namespace of the service account.autoCreateServiceAccountToken
: If set totrue
, the operator will automatically create a short-lived service account token on-demand for the service account. Defaults tofalse
.serviceAccountTokenAudiences
: Optionally specify audience for the service account token. This field is only relevant if you have setautoCreateServiceAccountToken
totrue
. No audience is specified by default.
Example:
awsIamAuth
awsIamAuth
The AWS IAM machine identity authentication method is used to authenticate with Infisical. Read more about AWS IAM Auth.
Valid fields:
identityId
: The identity ID of the machine identity you created.
Example:
azureAuth
azureAuth
The AWS IAM machine identity authentication method is used to authenticate with Infisical. Azure Auth can only be used from within an Azure environment. Read more about Azure Auth.
Valid fields:
identityId
: The identity ID of the machine identity you created.
Example:
gcpIamAuth
gcpIamAuth
The GCP IAM machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used both within and outside GCP environments. Read more about Azure Auth.
Valid fields:
identityId
: The identity ID of the machine identity you created.serviceAccountKeyFilePath
: The path to the GCP service account key file.
Example:
gcpIdTokenAuth
gcpIdTokenAuth
The GCP ID Token machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used within GCP environments. Read more about Azure Auth.
Valid fields:
identityId
: The identity ID of the machine identity you created.
Example:
tls
tls
This block defines the TLS settings to use for connecting to the Infisical instance.
Fields:
caRef
caRef
This block defines the reference to the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
Valid fields:
secretName
: The name of the Kubernetes secret containing the CA certificate to use for connecting to the Infisical instance with SSL/TLS.secretNamespace
: The namespace of the Kubernetes secret containing the CA certificate to use for connecting to the Infisical instance with SSL/TLS.key
: The name of the key in the Kubernetes secret which contains the value of the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
Example:
Applying the InfisicalDynamicSecret CRD to your cluster
Once you have configured the InfisicalDynamicSecret
CRD with the required fields, you can apply it to your cluster. After applying, you should notice that a lease has been created in Infisical and synced to your Kubernetes cluster.
Auto redeployment
Deployments referring to Kubernetes secrets containing Infisical dynamic secrets don’t automatically reload when the dynamic secret lease expires. This means your deployment may use expired dynamic secrets unless manually redeployed. To address this, we’ve added functionality to automatically redeploy your deployment when the associated Kubernetes secret containing your Infisical dynamic secret updates.
Enabling auto redeploy
To enable auto redeployment you simply have to add the following annotation to the deployment, statefulset, or daemonset that consumes a managed secret.
Deployment example with auto redeploy enabled
Deployment example with auto redeploy enabled
How it works
When the lease changes, the operator will check to see which deployments are using the operator-managed Kubernetes secret that received the update. Then, for each deployment that has this annotation present, a rolling update will be triggered. A redeployment won’t happen if the lease is renewed, only if it’s recreated.