docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd.mdx
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:
The example below shows a sample InfisicalDynamicSecret CRD that creates a dynamic secret lease in Infisical, and syncs the lease to your Kubernetes cluster.
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalDynamicSecret
metadata:
name: infisicaldynamicsecret
spec:
hostAPI: https://app.infisical.com/api # Optional, defaults to https://app.infisical.com/api
dynamicSecret:
secretName: <dynamic-secret-name>
projectId: <project-id>
secretsPath: <path/to/dynamic-secret> # Root directory is /
environmentSlug: <env-slug>
# Lease revocation policy defines what should happen to leases created by the operator if the CRD is deleted.
# If set to "Revoke", leases will be revoked when the InfisicalDynamicSecret CRD is deleted.
leaseRevocationPolicy: Revoke
# Lease TTL defines how long the lease should last for the dynamic secret.
# This value must be less than 1 day, and if a max TTL is defined on the dynamic secret, it must be below the max TTL.
leaseTTL: 1m
# A reference to the secret that the dynamic secret lease should be stored in.
# If the secret doesn't exist, it will automatically be created.
managedSecretReference:
secretName: <secret-name>
secretNamespace: default # Must be the same namespace as the InfisicalDynamicSecret CRD.
creationPolicy: Orphan
# Only have one authentication method defined or you are likely to run into authentication issues.
# Remove all except one authentication method.
authentication:
awsIamAuth:
identityId: <machine-identity-id>
azureAuth:
identityId: <machine-identity-id>
gcpIamAuth:
identityId: <machine-identity-id>
serviceAccountKeyFilePath: </path-to-service-account-key-file.json>
gcpIdTokenAuth:
identityId: <machine-identity-id>
ldapAuth:
identityId: <machine-identity-id>
credentialsRef:
secretName: <secret-name> # ldap-auth-credentials
secretNamespace: <secret-namespace> # default
kubernetesAuth:
identityId: <machine-identity-id>
serviceAccountRef:
name: <secret-name>
namespace: <secret-namespace>
universalAuth:
credentialsRef:
secretName: <secret-name> # universal-auth-credentials
secretNamespace: <secret-namespace> # default
Apply the InfisicalDynamicSecret CRD to your cluster.
kubectl apply -f dynamic-secret-crd.yaml
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:
kubectl get secret <managed-secret-name> -o yaml
After getting the secret, you should should see that the secret has data that contains the lease credentials.
apiVersion: v1
data:
DB_PASSWORD: VHhETjZ4c2xsTXpOSWdPYW5LLlRyNEc2alVKYml6WiQjQS0tNTdodyREM3ZLZWtYSi4hTkdyS0F+TVFsLU9CSA==
DB_USERNAME: cHg4Z0dJTUVBcHdtTW1aYnV3ZWRsekJRRll6cW4wFEE=
kind: Secret
# .....
When hostAPI is not defined the operator fetches secrets from Infisical Cloud.
``` bash
http://<backend-svc-name>.<namespace>.svc.cluster.local:4000/api
```
Make sure to replace `<backend-svc-name>` and `<namespace>` with the appropriate values for your backend service and namespace.
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 minutes
h for hours
d for days
<Note>
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.
spec:
managedSecretReference:
secretName: <secret-name>
secretNamespace: default
{" "}
<Accordion title="managedSecretReference.secretName"> The name of the Kubernetes secret where the dynamic secret lease should be stored. </Accordion>{" "}
<Accordion title="managedSecretReference.secretNamespace"> The namespace of the Kubernetes secret where the dynamic secret lease should be stored. </Accordion> <Accordion title="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`
<Tip>
When creation policy is set to `Owner`, the `InfisicalSecret` CRD must be in
the same namespace as where the managed kubernetes secret.
</Tip>
This field is optional.
This field is optional.
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.spec:
leaseRevocationPolicy: Revoke
spec:
dynamicSecret:
secretName: <dynamic-secret-name>
# Use either projectId OR projectSlug, not both
projectId: <project-id> # Either projectId or projectSlug is required
# projectSlug: <project-slug>
environmentSlug: <env-slug>
secretsPath: <secrets-path>
{" "}
<Accordion title="dynamicSecret.secretName"> The name of the dynamic secret. </Accordion>{" "}
<Accordion title="dynamicSecret.projectId"> The project ID of where the dynamic secret is stored in Infisical. <Note> Please note that you can only use either `projectId` or `projectSlug` in the `dynamicSecret` field. </Note> </Accordion> <Accordion title="dynamicSecret.projectSlug"> The project slug of where the dynamic secret is stored in Infisical. <Note> Please note that you can only use either `projectId` or `projectSlug` in the `dynamicSecret` field. </Note> </Accordion>{" "}
<Accordion title="dynamicSecret.environmentSlug"> The environment slug of where the dynamic secret is stored in Infisical. </Accordion>{" "}
<Accordion title="dynamicSecret.secretsPath"> The path of where the dynamic secret is stored in Infisical. The root path is `/`. </Accordion> </Accordion> <Accordion title="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.
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:
```yaml
# infisical-push-secret.yaml
spec:
universalAuth:
credentialsRef:
secretName: <secret-name>
secretNamespace: <secret-namespace>
```
```yaml
# machine-identity-credentials.yaml
apiVersion: v1
kind: Secret
metadata:
name: universal-auth-credentials
type: Opaque
stringData:
clientId: <machine-identity-client-id>
clientSecret: <machine-identity-client-secret>
```
Example:
```yaml
spec:
kubernetesAuth:
identityId: <machine-identity-id>
autoCreateServiceAccountToken: true # Automatically creates short-lived service account tokens for the service account.
serviceAccountTokenAudiences:
- <audience> # Optionally specify audience for the service account token. No audience is specified by default.
serviceAccountRef:
name: <secret-name>
namespace: <secret-namespace>
```
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
- `credentialsRef`: The name and namespace of the Kubernetes secret that stores the LDAP credentials.
- `credentialsRef.secretName`: The name of the Kubernetes secret.
- `credentialsRef.secretNamespace`: The namespace of the Kubernetes secret.
Example:
```yaml
# infisical-push-secret.yaml
spec:
ldapAuth:
identityId: <machine-identity-id>
credentialsRef:
secretName: <secret-name>
secretNamespace: <secret-namespace>
```
```yaml
# machine-identity-credentials.yaml
apiVersion: v1
kind: Secret
metadata:
name: ldap-auth-credentials
type: Opaque
stringData:
username: <ldap-username>
password: <ldap-password>
```
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
Example:
```yaml
spec:
authentication:
awsIamAuth:
identityId: <machine-identity-id>
```
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
Example:
```yaml
spec:
authentication:
azureAuth:
identityId: <machine-identity-id>
```
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
- `serviceAccountKeyFilePath`: The path to the GCP service account key file.
Example:
```yaml
spec:
gcpIamAuth:
identityId: <machine-identity-id>
serviceAccountKeyFilePath: </path-to-service-account-key-file.json>
```
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
Example:
```yaml
spec:
gcpIdTokenAuth:
identityId: <machine-identity-id>
```
Fields: <Accordion title="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:
```yaml
tls:
caRef:
secretName: custom-ca-certificate
secretNamespace: default
key: ca.crt
```
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.
kubectl apply -f dynamic-secret-crd.yaml
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.
To enable auto redeployment you simply have to add the following annotation to the deployment, statefulset, or daemonset that consumes a managed secret.
secrets.infisical.com/auto-reload: "true"