docs: ldap auth in operator

This commit is contained in:
=
2025-08-01 21:04:44 +05:30
parent d28d3449de
commit 71651f85fe
3 changed files with 426 additions and 336 deletions
@@ -68,6 +68,11 @@ spec:
serviceAccountKeyFilePath: </path-to-service-account-key-file.json> serviceAccountKeyFilePath: </path-to-service-account-key-file.json>
gcpIdTokenAuth: gcpIdTokenAuth:
identityId: <machine-identity-id> identityId: <machine-identity-id>
ldapAuth:
identityId: <machine-identity-id>
credentialsRef:
secretName: <secret-name> # ldap-auth-credentials
secretNamespace: <secret-namespace> # default
kubernetesAuth: kubernetesAuth:
identityId: <machine-identity-id> identityId: <machine-identity-id>
serviceAccountRef: serviceAccountRef:
@@ -126,17 +131,18 @@ When `hostAPI` is not defined the operator fetches secrets from Infisical Cloud.
<Accordion title="leaseTTL"> <Accordion title="leaseTTL">
The `leaseTTL` is a string-formatted duration that defines the time the lease should last for the dynamic secret. 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 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: The following units are supported:
- `s` for seconds (must be at least 5 seconds) - `s` for seconds (must be at least 5 seconds)
- `m` for minutes - `m` for minutes
- `h` for hours - `h` for hours
- `d` for days - `d` for days
<Note> <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. 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.
</Note> </Note>
</Accordion> </Accordion>
@@ -300,7 +306,6 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws
- `autoCreateServiceAccountToken`: If set to `true`, the operator will automatically create a short-lived service account token on-demand for the service account. Defaults to `false`. - `autoCreateServiceAccountToken`: If set to `true`, the operator will automatically create a short-lived service account token on-demand for the service account. Defaults to `false`.
- `serviceAccountTokenAudiences`: Optionally specify audience for the service account token. This field is only relevant if you have set `autoCreateServiceAccountToken` to `true`. No audience is specified by default. - `serviceAccountTokenAudiences`: Optionally specify audience for the service account token. This field is only relevant if you have set `autoCreateServiceAccountToken` to `true`. No audience is specified by default.
Example: Example:
```yaml ```yaml
@@ -316,7 +321,40 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws
``` ```
</Accordion> </Accordion>
<Accordion title="ldapAuth">
The ldap machine identity authentication method is used to authenticate with a configured LDAP directory. [Read more about LDAP Auth](/documentation/platform/identities/ldap-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 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>
```
</Accordion>
<Accordion title="awsIamAuth"> <Accordion title="awsIamAuth">
The AWS IAM machine identity authentication method is used to authenticate with Infisical. The AWS IAM machine identity authentication method is used to authenticate with Infisical.
[Read more about AWS IAM Auth](/documentation/platform/identities/aws-auth). [Read more about AWS IAM Auth](/documentation/platform/identities/aws-auth).
@@ -70,6 +70,11 @@ Before applying the InfisicalPushSecret CRD, you need to create a Kubernetes sec
serviceAccountRef: serviceAccountRef:
name: <secret-name> name: <secret-name>
namespace: <secret-namespace> namespace: <secret-namespace>
ldapAuth:
identityId: <machine-identity-id>
credentialsRef:
secretName: <secret-name> # ldap-auth-credentials
secretNamespace: <secret-namespace> # default
universalAuth: universalAuth:
credentialsRef: credentialsRef:
secretName: <secret-name> # universal-auth-credentials secretName: <secret-name> # universal-auth-credentials
@@ -324,7 +329,39 @@ After applying the InfisicalPushSecret CRD, you should notice that the secrets y
namespace: <secret-namespace> namespace: <secret-namespace>
``` ```
</Accordion> </Accordion>
<Accordion title="ldapAuth">
The ldap machine identity authentication method is used to authenticate with a configured LDAP directory. [Read more about LDAP Auth](/documentation/platform/identities/ldap-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 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>
```
</Accordion>
<Accordion title="awsIamAuth"> <Accordion title="awsIamAuth">
The AWS IAM machine identity authentication method is used to authenticate with Infisical. The AWS IAM machine identity authentication method is used to authenticate with Infisical.
[Read more about AWS IAM Auth](/documentation/platform/identities/aws-auth). [Read more about AWS IAM Auth](/documentation/platform/identities/aws-auth).
@@ -525,49 +525,6 @@ spec:
... ...
``` ```
</Tab> </Tab>
</Tabs> </Tabs>
@@ -747,6 +704,59 @@ spec:
</Accordion> </Accordion>
<Accordion title="authentication.ldapAuth">
The ldap machine identity authentication method is used to authenticate with Infisical using the configured LDAP directory. The username and password needs to be stored in a Kubernetes secret. This block defines the reference to the name and namespace of secret that stores these credentials.
<Steps>
<Step title="Create a machine identity">
You need to create a machine identity, and give it access to the project(s) you want to interact with. You can [read more about machine identities here](/documentation/platform/identities/universal-auth).
</Step>
<Step title="Create Kubernetes secret containing machine identity credentials">
Once you have created your machine identity and added it to your project(s), you will need to create a Kubernetes secret containing the identity credentials.
To quickly create a Kubernetes secret containing the identity credentials, you can run the command below.
Make sure you replace `<your-identity-ldap-username>` with the identity ldap username and `<your-identity-ldap-password>` with the identity ldap password.
``` bash
kubectl create secret generic ldap-auth-credentials --from-literal=username="<your-identity-ldap-username>" --from-literal=password="<your-identity-ldap-password>"
```
</Step>
<Step title="Add reference for the Kubernetes secret containing the identity credentials">
Once the secret is created, add the `secretName` and `secretNamespace` of the secret that was just created under `authentication.ldapAuth.credentialsRef` field in the InfisicalSecret resource.
</Step>
</Steps>
<Info>
Make sure to also populate the `secretsScope` field with the project slug
_`projectSlug`_, environment slug _`envSlug`_, and secrets path
_`secretsPath`_ that you want to fetch secrets from. Please see the example
below.
</Info>
## Example
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
name: infisicalsecret-sample-crd
spec:
authentication:
ldapAuth:
secretsScope:
projectSlug: <project-slug> # <-- project slug
envSlug: <env-slug> # "dev", "staging", "prod", etc..
secretsPath: "<secrets-path>" # Root is "/"
identityId: <machine-identity-id>
credentialsRef:
secretName: ldap-auth-credentials # <-- name of the Kubernetes secret that stores our machine identity credentials
secretNamespace: default # <-- namespace of the Kubernetes secret that stores our machine identity credentials
```
</Accordion>
<Accordion title="authentication.serviceToken"> <Accordion title="authentication.serviceToken">
The service token required to authenticate with Infisical needs to be stored in a Kubernetes secret. This block defines the reference to the name and namespace of secret that stores this service token. The service token required to authenticate with Infisical needs to be stored in a Kubernetes secret. This block defines the reference to the name and namespace of secret that stores this service token.
@@ -928,7 +938,9 @@ The properties includes defining the name and namespace of the Kubernetes config
The Infisical operator will automatically create the Kubernetes config map in the specified name/namespace and ensure it stays up-to-date. If a config map already exists in the specified namespace, the operator will update the existing config map with the new data. The Infisical operator will automatically create the Kubernetes config map in the specified name/namespace and ensure it stays up-to-date. If a config map already exists in the specified namespace, the operator will update the existing config map with the new data.
<Warning> <Warning>
The usage of config maps is only intended for storing non-sensitive data. If you are looking to store sensitive data, please use the [managed secret](#operator-managed-secrets) property instead. The usage of config maps is only intended for storing non-sensitive data. If
you are looking to store sensitive data, please use the [managed
secret](#operator-managed-secrets) property instead.
</Warning> </Warning>
<Accordion title="managedKubeConfigMapReferences"> <Accordion title="managedKubeConfigMapReferences">
@@ -943,19 +955,18 @@ The Infisical operator will automatically create the Kubernetes config map in th
Creation policies allow you to control whether or not owner references should be added to the managed Kubernetes config map that is generated by the Infisical operator. Creation policies allow you to control whether or not owner references should be added to the managed Kubernetes config map 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. This is useful for tools such as ArgoCD, where every resource requires an owner reference; otherwise, it will be pruned automatically.
#### Available options #### Available options
- `Orphan` (default) - `Orphan` (default)
- `Owner` - `Owner`
<Tip> <Tip>
When creation policy is set to `Owner`, the `InfisicalSecret` CRD must be in When creation policy is set to `Owner`, the `InfisicalSecret` CRD must be in
the same namespace as where the managed kubernetes config map. the same namespace as where the managed kubernetes config map.
</Tip> </Tip>
</Accordion> </Accordion>
#### Managed ConfigMap Templating #### Managed ConfigMap Templating
Fetching secrets from Infisical as is via the operator may not be enough. This is where templating functionality may be helpful. Fetching secrets from Infisical as is via the operator may not be enough. This is where templating functionality may be helpful.
@@ -968,27 +979,27 @@ Using Go templates, you can format, combine, and create new key-value pairs from
When set to `true`, all secrets fetched from your Infisical project will be added into your managed Kubernetes config map resource. When set to `true`, all secrets fetched from your Infisical project will be added into your managed Kubernetes config map resource.
**Use this option when you would like to sync all secrets from Infisical to Kubernetes but want to template a subset of them.** **Use this option when you would like to sync all secrets from Infisical to Kubernetes but want to template a subset of them.**
When set to `false`, only secrets defined in the `managedKubeConfigMapReferences[].template.data` field of the template will be included in the managed config map. When set to `false`, only secrets defined in the `managedKubeConfigMapReferences[].template.data` field of the template will be included in the managed config map.
Use this option when you would like to sync **only** a subset of secrets from Infisical to Kubernetes. Use this option when you would like to sync **only** a subset of secrets from Infisical to Kubernetes.
</Accordion> </Accordion>
<Accordion title="managedKubeConfigMapReferences[].template.data"> <Accordion title="managedKubeConfigMapReferences[].template.data">
Define secret keys and their corresponding templates. Define secret keys and their corresponding templates.
Each data value uses a Golang template with access to all secrets retrieved from the specified scope. Each data value uses a Golang template with access to all secrets retrieved from the specified scope.
Secrets are structured as follows: Secrets are structured as follows:
```golang ```golang
type TemplateSecret struct { type TemplateSecret struct {
Value string `json:"value"` Value string `json:"value"`
SecretPath string `json:"secretPath"` SecretPath string `json:"secretPath"`
} }
``` ```
#### Example template configuration: #### Example template configuration:
```yaml ```yaml
managedKubeConfigMapReferences: managedKubeConfigMapReferences:
- configMapName: managed-configmap - configMapName: managed-configmap
configMapNamespace: default configMapNamespace: default
template: template:
@@ -998,33 +1009,34 @@ Using Go templates, you can format, combine, and create new key-value pairs from
SITE_URL: "{{ .SITE_URL.Value }}" SITE_URL: "{{ .SITE_URL.Value }}"
# Override an existing key in Infisical project with a new value using values of other secrets # Override an existing key in Infisical project with a new value using values of other secrets
API_URL: "https://api.{{.SITE_URL.Value}}.{{.REGION.Value}}.com" API_URL: "https://api.{{.SITE_URL.Value}}.{{.REGION.Value}}.com"
``` ```
For this example, let's assume the following secrets exist in your Infisical project: For this example, let's assume the following secrets exist in your Infisical project:
``` ```
SITE_URL = "https://example.com" SITE_URL = "https://example.com"
REGION = "us-east-1" REGION = "us-east-1"
API_URL = "old-url" # This will be overridden API_URL = "old-url" # This will be overridden
``` ```
The resulting managed Kubernetes config map will then contain: The resulting managed Kubernetes config map will then contain:
``` ```
# Original config map data (from includeAllSecrets: true) # Original config map data (from includeAllSecrets: true)
SITE_URL = "https://example.com" SITE_URL = "https://example.com"
REGION = "us-east-1" REGION = "us-east-1"
# New and overridden config map data # New and overridden config map data
SITE_URL = "https://example.com" SITE_URL = "https://example.com"
API_URL = "https://api.example.com.us-east-1.com" # Existing secret overridden by template API_URL = "https://api.example.com.us-east-1.com" # Existing secret overridden by template
``` ```
To help transform your config map data further, the operator provides a set of built-in functions that you can use in your templates. To help transform your config map data further, the operator provides a set of built-in functions that you can use in your templates.
### Available templating functions ### Available templating functions
Please refer to the [templating functions documentation](/integrations/platforms/kubernetes/overview#available-helper-functions) for more information.
Please refer to the [templating functions documentation](/integrations/platforms/kubernetes/overview#available-helper-functions) for more information.
</Accordion> </Accordion>
## Applying CRD ## Applying CRD
@@ -1061,8 +1073,6 @@ To verify that the operator has successfully created the managed secret, you can
</Tab> </Tab>
</Tabs> </Tabs>
## Using Managed Secret In Your Deployment ## Using Managed Secret In Your Deployment
To make use of the managed secret created by the operator into your deployment can be achieved through several methods. To make use of the managed secret created by the operator into your deployment can be achieved through several methods.
@@ -1071,7 +1081,7 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
<Accordion title="envFrom"> <Accordion title="envFrom">
This will take all the secrets from your managed secret and expose them to your container This will take all the secrets from your managed secret and expose them to your container
````yaml ````yaml
envFrom: envFrom:
- secretRef: - secretRef:
name: managed-secret # managed secret name name: managed-secret # managed secret name
@@ -1080,12 +1090,12 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
Example usage in a deployment Example usage in a deployment
```yaml ```yaml
apiVersion: apps/v1 apiVersion: apps/v1
kind: Deployment kind: Deployment
metadata: metadata:
name: nginx-deployment name: nginx-deployment
labels: labels:
app: nginx app: nginx
spec: spec:
replicas: 1 replicas: 1
selector: selector:
matchLabels: matchLabels:
@@ -1103,7 +1113,7 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
name: managed-secret # <- name of managed secret name: managed-secret # <- name of managed secret
ports: ports:
- containerPort: 80 - containerPort: 80
```` ````
</Accordion> </Accordion>
@@ -1119,16 +1129,16 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
key: SOME_SECRET_KEY # The name of the key which exists in the managed secret key: SOME_SECRET_KEY # The name of the key which exists in the managed secret
``` ```
Example usage in a deployment Example usage in a deployment
```yaml ```yaml
apiVersion: apps/v1 apiVersion: apps/v1
kind: Deployment kind: Deployment
metadata: metadata:
name: nginx-deployment name: nginx-deployment
labels: labels:
app: nginx app: nginx
spec: spec:
replicas: 1 replicas: 1
selector: selector:
matchLabels: matchLabels:
@@ -1149,7 +1159,8 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
key: STRIPE_API_SECRET key: STRIPE_API_SECRET
ports: ports:
- containerPort: 80 - containerPort: 80
``` ```
</Accordion> </Accordion>
<Accordion title="volumes"> <Accordion title="volumes">
@@ -1161,25 +1172,25 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
secretName: managed-secret # managed secret name secretName: managed-secret # managed secret name
```` ````
You can then mount this volume to the container's filesystem so that your deployment can access the files containing the managed secrets You can then mount this volume to the container's filesystem so that your deployment can access the files containing the managed secrets
```yaml ```yaml
volumeMounts: volumeMounts:
- name: secrets-volume-name - name: secrets-volume-name
mountPath: /etc/secrets mountPath: /etc/secrets
readOnly: true readOnly: true
``` ```
Example usage in a deployment Example usage in a deployment
```yaml ```yaml
apiVersion: apps/v1 apiVersion: apps/v1
kind: Deployment kind: Deployment
metadata: metadata:
name: nginx-deployment name: nginx-deployment
labels: labels:
app: nginx app: nginx
spec: spec:
replicas: 1 replicas: 1
selector: selector:
matchLabels: matchLabels:
@@ -1202,7 +1213,7 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
- name: secrets-volume-name - name: secrets-volume-name
secret: secret:
secretName: managed-secret # <- managed secrets secretName: managed-secret # <- managed secrets
``` ```
</Accordion> </Accordion>
@@ -1339,9 +1350,11 @@ secrets.infisical.com/auto-reload: "true"
</Accordion> </Accordion>
<Info> <Info>
#### How it works #### How it works When a managed secret is updated, the operator checks for
When a managed secret is updated, the operator checks for any Deployments, DaemonSets, or StatefulSets that consume the updated secret and have the annotation any Deployments, DaemonSets, or StatefulSets that consume the updated secret
`secrets.infisical.com/auto-reload: "true"`. For each matching workload, the operator triggers a rolling restart to ensure it picks up the latest secret values. and have the annotation `secrets.infisical.com/auto-reload: "true"`. For each
matching workload, the operator triggers a rolling restart to ensure it picks
up the latest secret values.
</Info> </Info>
## Using Managed ConfigMap In Your Deployment ## Using Managed ConfigMap In Your Deployment
@@ -1350,14 +1363,14 @@ To make use of the managed ConfigMap created by the operator into your deploymen
Here, we will highlight three of the most common ways to utilize it. Learn more about Kubernetes ConfigMaps [here](https://kubernetes.io/docs/concepts/configuration/configmap/) Here, we will highlight three of the most common ways to utilize it. Learn more about Kubernetes ConfigMaps [here](https://kubernetes.io/docs/concepts/configuration/configmap/)
<Tip> <Tip>
Automatic redeployment of deployments using managed ConfigMaps is not yet supported. Automatic redeployment of deployments using managed ConfigMaps is not yet
supported.
</Tip> </Tip>
<Accordion title="envFrom"> <Accordion title="envFrom">
This will take all the secrets from your managed ConfigMap and expose them to your container This will take all the secrets from your managed ConfigMap and expose them to your container
````yaml ````yaml
envFrom: envFrom:
- configMapRef: - configMapRef:
name: managed-configmap # managed configmap name name: managed-configmap # managed configmap name
@@ -1366,12 +1379,12 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
Example usage in a deployment Example usage in a deployment
```yaml ```yaml
apiVersion: apps/v1 apiVersion: apps/v1
kind: Deployment kind: Deployment
metadata: metadata:
name: nginx-deployment name: nginx-deployment
labels: labels:
app: nginx app: nginx
spec: spec:
replicas: 1 replicas: 1
selector: selector:
matchLabels: matchLabels:
@@ -1389,7 +1402,7 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
name: managed-configmap # <- name of managed configmap name: managed-configmap # <- name of managed configmap
ports: ports:
- containerPort: 80 - containerPort: 80
```` ````
</Accordion> </Accordion>
@@ -1405,16 +1418,16 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
key: SOME_CONFIG_KEY # The name of the key which exists in the managed configmap key: SOME_CONFIG_KEY # The name of the key which exists in the managed configmap
``` ```
Example usage in a deployment Example usage in a deployment
```yaml ```yaml
apiVersion: apps/v1 apiVersion: apps/v1
kind: Deployment kind: Deployment
metadata: metadata:
name: nginx-deployment name: nginx-deployment
labels: labels:
app: nginx app: nginx
spec: spec:
replicas: 1 replicas: 1
selector: selector:
matchLabels: matchLabels:
@@ -1435,7 +1448,7 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
key: STRIPE_API_SECRET key: STRIPE_API_SECRET
ports: ports:
- containerPort: 80 - containerPort: 80
``` ```
</Accordion> </Accordion>
@@ -1448,25 +1461,25 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
name: managed-configmap # managed configmap name name: managed-configmap # managed configmap name
```` ````
You can then mount this volume to the container's filesystem so that your deployment can access the files containing the managed secrets You can then mount this volume to the container's filesystem so that your deployment can access the files containing the managed secrets
```yaml ```yaml
volumeMounts: volumeMounts:
- name: configmaps-volume-name - name: configmaps-volume-name
mountPath: /etc/config mountPath: /etc/config
readOnly: true readOnly: true
``` ```
Example usage in a deployment Example usage in a deployment
```yaml ```yaml
apiVersion: apps/v1 apiVersion: apps/v1
kind: Deployment kind: Deployment
metadata: metadata:
name: nginx-deployment name: nginx-deployment
labels: labels:
app: nginx app: nginx
spec: spec:
replicas: 1 replicas: 1
selector: selector:
matchLabels: matchLabels:
@@ -1489,7 +1502,8 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
- name: configmaps-volume-name - name: configmaps-volume-name
configMap: configMap:
name: managed-configmap # <- managed configmap name: managed-configmap # <- managed configmap
``` ```
</Accordion> </Accordion>
The definition file of the Kubernetes secret for the CA certificate can be structured like the following: The definition file of the Kubernetes secret for the CA certificate can be structured like the following:
@@ -1532,13 +1546,13 @@ Thus, if a specific label is required on the resulting secret, it can be applied
... ...
``` ```
This would result in the following managed secret to be created: This would result in the following managed secret to be created:
```yaml ```yaml
apiVersion: v1 apiVersion: v1
data: ... data: ...
kind: Secret kind: Secret
metadata: metadata:
annotations: annotations:
example.com/annotation-to-be-passed-to-managed-secret: sample-value example.com/annotation-to-be-passed-to-managed-secret: sample-value
secrets.infisical.com/version: W/"3f1-ZyOSsrCLGSkAhhCkY2USPu2ivRw" secrets.infisical.com/version: W/"3f1-ZyOSsrCLGSkAhhCkY2USPu2ivRw"
@@ -1546,6 +1560,7 @@ Thus, if a specific label is required on the resulting secret, it can be applied
label-to-be-passed-to-managed-secret: sample-value label-to-be-passed-to-managed-secret: sample-value
name: managed-token name: managed-token
namespace: default namespace: default
type: Opaque type: Opaque
``` ```
</Accordion> </Accordion>