awatertrevi/infisical
1
0
Fork 0
mirror of https://github.com/awatertrevi/infisical.git synced 2026-09-22 13:39:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(k8s): config map support

Browse Source
This commit is contained in:
Daniel Hougaard
2025-03-13 23:44:32 +04:00
parent ace8c37c25
commit 6842f7aa8b
1 changed files with 324 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

341
docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx
View File

@@ -93,7 +93,7 @@ When `hostAPI` is not defined the operator fetches secrets from Infisical Cloud.
CA certificate to use for connecting to the Infisical instance with SSL/TLS.
</Accordion>
### Authentication methods
### Authentication Methods
To retrieve the requested secrets, the operator must first authenticate with Infisical.
The list of available authentication methods are shown below.
@@ -535,7 +535,7 @@ spec:
</Accordion>
### Operator managed secrets
### Operator Managed Secrets
The managed secret properties specify where to store the secrets retrieved from your Infisical project.
This includes defining the name and namespace of the Kubernetes secret that will hold these secrets.
@@ -584,7 +584,7 @@ This is useful for tools such as ArgoCD, where every resource requires an owner
</Accordion>
### Manged secret templating
#### Managed Secret Templating
Fetching secrets from Infisical as is via the operator may not be enough. This is where templating functionality may be helpful.
Using Go templates, you can format, combine, and create new key-value pairs from secrets fetched from Infisical before storing them as Kubernetes Secrets.
@@ -681,6 +681,135 @@ template:
</Accordion>
### Operator Managed ConfigMaps
The managed config map properties specify where to store the secrets retrieved from your Infisical project. Config maps can be used to store **non-sensitive** data, such as application configuration variables.
The properties includes defining the name and namespace of the Kubernetes config map that will hold the data retrieved from your Infisical project.
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.
</Warning>
<Accordion title="managedKubeConfigMapReferences">
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].configMapName">
The name of the managed Kubernetes config map that your Infisical data will be stored in.
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].configMapNamespace">
The namespace of the managed Kubernetes config map that your Infisical data will be stored in.
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].creationPolicy">
Creation polices 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.
#### 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 config map.
</Tip>
</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.
Using Go templates, you can format, combine, and create new key-value pairs from secrets fetched from Infisical before storing them as Kubernetes Config Maps.
<Accordion title="managedKubeConfigMapReferences[].template">
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].template.includeAllSecrets">
This property controls what secrets are included in your managed config map when using templates.
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.**
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.
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].template.data">
Define secret keys and their corresponding templates.
Each data value uses a Golang template with access to all secrets retrieved from the specified scope.
Secrets are structured as follows:
```golang
type TemplateSecret struct {
Value string `json:"value"`
SecretPath string `json:"secretPath"`
}
```
#### Example template configuration:
```yaml
managedKubeConfigMapReferences:
- configMapName: managed-configmap
configMapNamespace: default
template:
includeAllSecrets: true
data:
# Create new key that doesn't exist in your Infisical project using values of other secrets
SITE_URL: "{{ .SITE_URL.Value }}"
# 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"
```
For this example, let's assume the following secrets exist in your Infisical project:
```
SITE_URL = "https://example.com"
REGION = "us-east-1"
API_URL = "old-url" # This will be overridden
```
The resulting managed Kubernetes config map will then contain:
```
# Original config map data (from includeAllSecrets: true)
SITE_URL = "https://example.com"
REGION = "us-east-1"
# New and overridden config map data
SITE_URL = "https://example.com"
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.
### Available templating functions
<Accordion title="decodeBase64ToBytes">
**Function name**: decodeBase64ToBytes
**Description**:
Given a base64 encoded string, this function will decodes the base64-encoded string.
This function is useful when your Infisical secrets are already stored as base64 encoded value in Infisical.
**Returns**: The decoded base64 string as bytes.
**Example**:
The example below assumes that the `BINARY_KEY_BASE64` secret is stored as a base64 encoded value in Infisical.
The resulting managed config map will contain the decoded value of `BINARY_KEY_BASE64`.
```yaml
managedKubeConfigMapReferences:
- configMapName: managed-configmap
configMapNamespace: default
template:
includeAllSecrets: true
data:
BINARY_KEY: "{{ decodeBase64ToBytes .BINARY_KEY_BASE64.Value }}"
```
</Accordion>
</Accordion>
## Applying CRD
Once you have configured the InfisicalSecret CRD with the required fields, you can apply it to your cluster.
@@ -692,17 +821,32 @@ kubectl apply -f example-infisical-secret-crd.yaml
To verify that the operator has successfully created the managed secret, you can check the secrets in the namespace that was specified.
```bash
# Verify managed secret is created
kubectl get secrets -n <namespace of managed secret>
```
<Tabs>
<Tab title="Managed Secret">
```bash
# Verify managed secret is created
kubectl get secrets -n <namespace of managed secret>
```
<Info>
The Infisical secrets will be synced and stored into the managed secret every
1 minute unless configured otherwise.
</Info>
</Tab>
<Tab title="Managed ConfigMap">
```bash
# Verify managed config map is created
kubectl get configmaps -n <namespace of managed config map>
```
<Info>
The Infisical config map data will be synced and stored into the managed config map every
1 minute unless configured otherwise.
</Info>
</Tab>
</Tabs>
<Info>
The Infisical secrets will be synced and stored into the managed secret every
1 minutes.
</Info>
## 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.
Here, we will highlight three of the most common ways to utilize it. Learn more about Kubernetes secrets [here](https://kubernetes.io/docs/concepts/configuration/secret/)
@@ -755,7 +899,7 @@ spec:
valueFrom:
secretKeyRef:
name: managed-secret # managed secret name
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
@@ -861,12 +1005,12 @@ stringData:
-----END CERTIFICATE-----
```
### Auto redeployment
### Automatic Redeployment
Deployments using managed secrets don't reload automatically on updates, so they may use outdated secrets unless manually redeployed.
To address this, we added functionality to automatically redeploy your deployment when its managed secret updates.
#### Enabling auto redeploy
#### Enabling Automatic Redeployment
To enable auto redeployment you simply have to add the following annotation to the deployment, statefulset, or daemonset that consumes a managed secret.
@@ -910,7 +1054,171 @@ spec:
Then, for each deployment that has this annotation present, a rolling update will be triggered.
</Info>
## Propagating labels & annotations
## Using Managed ConfigMap In Your Deployment
To make use of the managed ConfigMap created by the operator into your deployment can be achieved through several methods.
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.
</Tip>
<Accordion title="envFrom">
This will take all the secrets from your managed ConfigMap and expose them to your container
````yaml
envFrom:
- configMapRef:
name: managed-configmap # managed configmap name
```
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
envFrom:
- configMapRef:
name: managed-configmap # <- name of managed configmap
ports:
- containerPort: 80
````
</Accordion>
<Accordion title="env">
This will allow you to select individual secrets by key name from your managed ConfigMap and expose them to your container
```yaml
env:
- name: CONFIG_NAME # The environment variable's name which is made available in the container
valueFrom:
configMapKeyRef:
name: managed-configmap # managed configmap name
key: SOME_CONFIG_KEY # The name of the key which exists in the managed configmap
```
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers: - name: nginx
image: nginx:1.14.2
env: - name: STRIPE_API_SECRET
valueFrom:
secretKeyRef:
name: managed-secret # <- name of managed secret
key: STRIPE_API_SECRET
ports: - containerPort: 80
```
</Accordion>
<Accordion title="volumes">
This will allow you to create a volume on your container which comprises of files holding the secrets in your managed kubernetes secret
```yaml
volumes:
- name: configmaps-volume-name # The name of the volume under which configmaps will be stored
configMap:
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
```yaml
volumeMounts:
- name: configmaps-volume-name
mountPath: /etc/config
readOnly: true
```
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
volumeMounts:
- name: configmaps-volume-name
mountPath: /etc/config
readOnly: true
ports:
- containerPort: 80
volumes:
- name: configmaps-volume-name
configMap:
name: managed-configmap # <- managed configmap
```
</Accordion>
The definition file of the Kubernetes secret for the CA certificate can be structured like the following:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: custom-ca-certificate
type: Opaque
stringData:
ca.crt: |
-----BEGIN CERTIFICATE-----
MIIEZzCCA0+gAwIBAgIUDk9+HZcMHppiNy0TvoBg8/aMEqIwDQYJKoZIhvcNAQEL
...
BQAwDTELMAkGA1UEChMCUEgwHhcNMjQxMDI1MTU0MjAzWhcNMjUxMDI1MjE0MjAz
-----END CERTIFICATE-----
```
## Propagating Labels & Annotations
The operator will transfer all labels & annotations present on the `InfisicalSecret` CRD to the managed Kubernetes secret to be created.
Thus, if a specific label is required on the resulting secret, it can be applied as demonstrated in the following example:
@@ -949,5 +1257,4 @@ metadata:
namespace: default
type: Opaque
```
</Accordion>