mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-10-10 23:28:45 +00:00
docs: ldap auth in operator
This commit is contained in:
=
@@ -68,6 +68,11 @@ spec:
|
||||
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:
|
||||
@@ -137,6 +142,7 @@ When `hostAPI` is not defined the operator fetches secrets from Infisical Cloud.
|
||||
|
||||
<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.
|
||||
|
||||
</Note>
|
||||
</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`.
|
||||
- `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:
|
||||
|
||||
```yaml
|
||||
@@ -316,7 +321,40 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws
|
||||
```
|
||||
|
||||
</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">
|
||||
The AWS IAM machine identity authentication method is used to authenticate with Infisical.
|
||||
[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:
|
||||
name: <secret-name>
|
||||
namespace: <secret-namespace>
|
||||
ldapAuth:
|
||||
identityId: <machine-identity-id>
|
||||
credentialsRef:
|
||||
secretName: <secret-name> # ldap-auth-credentials
|
||||
secretNamespace: <secret-namespace> # default
|
||||
universalAuth:
|
||||
credentialsRef:
|
||||
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>
|
||||
```
|
||||
</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">
|
||||
The AWS IAM machine identity authentication method is used to authenticate with Infisical.
|
||||
[Read more about AWS IAM Auth](/documentation/platform/identities/aws-auth).
|
||||
|
||||
@@ -525,49 +525,6 @@ spec:
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@@ -747,6 +704,59 @@ spec:
|
||||
|
||||
</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">
|
||||
|
||||
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.
|
||||
|
||||
<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>
|
||||
|
||||
<Accordion title="managedKubeConfigMapReferences">
|
||||
@@ -955,7 +967,6 @@ The Infisical operator will automatically create the Kubernetes config map in th
|
||||
|
||||
</Accordion>
|
||||
|
||||
|
||||
#### Managed ConfigMap Templating
|
||||
|
||||
Fetching secrets from Infisical as is via the operator may not be enough. This is where templating functionality may be helpful.
|
||||
@@ -1025,6 +1036,7 @@ Using Go templates, you can format, combine, and create new key-value pairs from
|
||||
### Available templating functions
|
||||
|
||||
Please refer to the [templating functions documentation](/integrations/platforms/kubernetes/overview#available-helper-functions) for more information.
|
||||
|
||||
</Accordion>
|
||||
|
||||
## Applying CRD
|
||||
@@ -1061,8 +1073,6 @@ To verify that the operator has successfully created the managed secret, you can
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
## 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.
|
||||
@@ -1150,6 +1160,7 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="volumes">
|
||||
@@ -1339,9 +1350,11 @@ secrets.infisical.com/auto-reload: "true"
|
||||
</Accordion>
|
||||
|
||||
<Info>
|
||||
#### How it works
|
||||
When a managed secret is updated, the operator checks for any Deployments, DaemonSets, or StatefulSets that consume the updated secret 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.
|
||||
#### How it works When a managed secret is updated, the operator checks for
|
||||
any Deployments, DaemonSets, or StatefulSets that consume the updated secret
|
||||
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>
|
||||
|
||||
## Using Managed ConfigMap In Your Deployment
|
||||
@@ -1350,10 +1363,10 @@ 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/)
|
||||
|
||||
<Tip>
|
||||
Automatic redeployment of deployments using managed ConfigMaps is not yet supported.
|
||||
Automatic redeployment of deployments using managed ConfigMaps is not yet
|
||||
supported.
|
||||
</Tip>
|
||||
|
||||
|
||||
<Accordion title="envFrom">
|
||||
This will take all the secrets from your managed ConfigMap and expose them to your container
|
||||
|
||||
@@ -1490,6 +1503,7 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
|
||||
configMap:
|
||||
name: managed-configmap # <- managed configmap
|
||||
```
|
||||
|
||||
</Accordion>
|
||||
|
||||
The definition file of the Kubernetes secret for the CA certificate can be structured like the following:
|
||||
@@ -1548,4 +1562,5 @@ Thus, if a specific label is required on the resulting secret, it can be applied
|
||||
namespace: default
|
||||
type: Opaque
|
||||
```
|
||||
|
||||
</Accordion>
|
||||
|
||||
Reference in New Issue
Block a user