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): added better templating docs

Browse Source
This commit is contained in:
Daniel Hougaard
2025-03-29 04:45:04 +04:00
parent ed94e7a8e7
commit 3ad50a4386
3 changed files with 307 additions and 336 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -451,30 +451,7 @@ Using Go templates, you can format, combine, and create new key-value pairs of s
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="encodeBase64">
**Function name**: encodeBase64
**Description**:
Given a string, this function will encode the string as a base64 encoded string.
This function is useful when you want to store a string as a base64 encoded value in Infisical.
**Returns**: The base64 encoded string.
**Example**:
The example below assumes that the `PLAIN_KEY` secret is stored in your source secret as a plaintext string.
```yaml
push:
secret:
secretName: push-secret-demo
secretNamespace: default
template:
includeAllSecrets: true
data:
PLAIN_KEY: "{{ encodeBase64 .PLAIN_KEY.Value }}" # Will be stored in Infisical as a base64 encoded string
```
</Accordion>
Please refer to the [templating functions documentation](/integrations/platforms/kubernetes/overview#available-helper-functions) for more information.
</Accordion>
## Applying the InfisicalPushSecret CRD to your cluster

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

@@ -654,30 +654,7 @@ To help transform your secrets further, the operator provides a set of built-in
### 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 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 secret will contain the decoded value of `BINARY_KEY_BASE64`.
```yaml
managedKubeSecretReferences:
secretName: managed-secret
secretNamespace: default
template:
includeAllSecrets: true
data:
BINARY_KEY: "{{ decodeBase64ToBytes .BINARY_KEY_BASE64.Value }}"
```
</Accordion>
Please refer to the [templating functions documentation](/integrations/platforms/kubernetes/overview#available-helper-functions) for more information.
</Accordion>
@@ -783,31 +760,8 @@ Using Go templates, you can format, combine, and create new key-value pairs from
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>
Please refer to the [templating functions documentation](/integrations/platforms/kubernetes/overview#available-helper-functions) for more information.
</Accordion>
## Applying CRD
@@ -854,39 +808,39 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
<Accordion title="envFrom">
This will take all the secrets from your managed secret and expose them to your container
````yaml
envFrom:
- secretRef:
name: managed-secret # managed secret name
```
````yaml
envFrom:
- secretRef:
name: managed-secret # managed secret name
```
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
template:
metadata:
labels:
spec:
replicas: 1
selector:
matchLabels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
envFrom:
- secretRef:
name: managed-secret # <- name of managed secret
ports:
- containerPort: 80
````
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
envFrom:
- secretRef:
name: managed-secret # <- name of managed secret
ports:
- containerPort: 80
````
</Accordion>
@@ -902,91 +856,90 @@ spec:
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
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
template:
metadata:
labels:
spec:
replicas: 1
selector:
matchLabels:
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
```
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: secrets-volume-name # The name of the volume under which secrets will be stored
secret:
secretName: managed-secret # managed secret name
````
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: secrets-volume-name # The name of the volume under which secrets will be stored
secret:
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
volumeMounts:
- name: secrets-volume-name
mountPath: /etc/secrets
readOnly: true
```
```yaml
volumeMounts:
- name: secrets-volume-name
mountPath: /etc/secrets
readOnly: true
```
Example usage in a deployment
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
template:
metadata:
labels:
spec:
replicas: 1
selector:
matchLabels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
volumeMounts:
- name: secrets-volume-name
mountPath: /etc/secrets
readOnly: true
ports:
- containerPort: 80
volumes:
- name: secrets-volume-name
secret:
secretName: managed-secret # <- managed secrets
```
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
volumeMounts:
- name: secrets-volume-name
mountPath: /etc/secrets
readOnly: true
ports:
- containerPort: 80
volumes:
- name: secrets-volume-name
secret:
secretName: managed-secret # <- managed secrets
```
</Accordion>
@@ -1021,34 +974,34 @@ secrets.infisical.com/auto-reload: "true"
```
<Accordion title="Deployment example with auto redeploy enabled">
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
annotations:
secrets.infisical.com/auto-reload: "true" # <- redeployment annotation
spec:
replicas: 1
selector:
matchLabels:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
template:
metadata:
labels:
annotations:
secrets.infisical.com/auto-reload: "true" # <- redeployment annotation
spec:
replicas: 1
selector:
matchLabels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
envFrom:
- secretRef:
name: managed-secret
ports:
- containerPort: 80
```
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
envFrom:
- secretRef:
name: managed-secret
ports:
- containerPort: 80
```
</Accordion>
<Info>
#### How it works
@@ -1069,39 +1022,39 @@ Here, we will highlight three of the most common ways to utilize it. Learn more
<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
```
````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:
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
template:
metadata:
labels:
spec:
replicas: 1
selector:
matchLabels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
envFrom:
- configMapRef:
name: managed-configmap # <- name of managed configmap
ports:
- containerPort: 80
````
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>
@@ -1117,92 +1070,91 @@ spec:
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
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
template:
metadata:
labels:
spec:
replicas: 1
selector:
matchLabels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
env:
- name: STRIPE_API_SECRET
valueFrom:
configMapKeyRef:
name: managed-configmap # <- name of managed configmap
key: STRIPE_API_SECRET
ports:
- containerPort: 80
```
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
env:
- name: STRIPE_API_SECRET
valueFrom:
configMapKeyRef:
name: managed-configmap # <- name of managed configmap
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
````
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
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
```
```yaml
volumeMounts:
- name: configmaps-volume-name
mountPath: /etc/config
readOnly: true
```
Example usage in a deployment
Example usage in a deployment
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
template:
metadata:
labels:
spec:
replicas: 1
selector:
matchLabels:
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
```
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:
@@ -1228,37 +1180,37 @@ The operator will transfer all labels & annotations present on the `InfisicalSec
Thus, if a specific label is required on the resulting secret, it can be applied as demonstrated in the following example:
<Accordion title="Example propagation">
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
name: infisicalsecret-sample
labels:
label-to-be-passed-to-managed-secret: sample-value
annotations:
example.com/annotation-to-be-passed-to-managed-secret: "sample-value"
spec:
..
authentication:
...
managedKubeSecretReferences:
...
```
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
name: infisicalsecret-sample
labels:
label-to-be-passed-to-managed-secret: sample-value
annotations:
example.com/annotation-to-be-passed-to-managed-secret: "sample-value"
spec:
..
authentication:
...
managedKubeSecretReferences:
...
```
This would result in the following managed secret to be created:
This would result in the following managed secret to be created:
```yaml
apiVersion: v1
data: ...
kind: Secret
metadata:
annotations:
example.com/annotation-to-be-passed-to-managed-secret: sample-value
secrets.infisical.com/version: W/"3f1-ZyOSsrCLGSkAhhCkY2USPu2ivRw"
labels:
label-to-be-passed-to-managed-secret: sample-value
name: managed-token
namespace: default
type: Opaque
```
```yaml
apiVersion: v1
data: ...
kind: Secret
metadata:
annotations:
example.com/annotation-to-be-passed-to-managed-secret: sample-value
secrets.infisical.com/version: W/"3f1-ZyOSsrCLGSkAhhCkY2USPu2ivRw"
labels:
label-to-be-passed-to-managed-secret: sample-value
name: managed-token
namespace: default
type: Opaque
```
</Accordion>

42
docs/integrations/platforms/kubernetes/overview.mdx
View File

@@ -114,6 +114,48 @@ spec:
```
## Advanced Templating
With the Infisical Secrets Operator, you can use templating to dynamically generate secrets in Kubernetes. The templating is built on top of [Go templates](https://pkg.go.dev/text/template), which is a powerful and flexible template engine built into Go.
Please be aware that trying to reference non-existing keys will result in an error. Additionally, each template field is processed individually, which means one template field cannot reference another template field.
<Note>
Please note that templating is currently only supported for the `InfisicalPushSecret` and `InfisicalSecret` CRDs.
</Note>
### Available helper functions
The Infisical Secrets Operator exposes a wide range of helper functions to make it easier to work with secrets in Kubernetes.
| Function | Description | Signature |
| -------- | ----------- | --------- |
| `decodeBase64ToBytes` | Given a base64 encoded string, this function will decode the base64-encoded string. | `decodeBase64ToBytes(encodedString string) string` |
| `encodeBase64` | Given a string, this function will encode the string to a base64 encoded string. | `encodeBase64(plainString string) string` |
| `pkcs12key`| Extracts all private keys from a PKCS#12 archive and encodes them in PKCS#8 PEM format. | `pkcs12key(input string) string` |
| `pkcs12keyPass`|Same as pkcs12key. Uses the provided password to decrypt the PKCS#12 archive. | `pkcs12keyPass(pass string, input string) string` |
| `pkcs12cert` | Extracts all certificates from a PKCS#12 archive and orders them if possible. If disjunct or multiple leaf certs are provided they are returned as-is. Sort order: `leaf / intermediate(s) / root`. | `pkcs12cert(input string) string` |
| `pkcs12certPass` | Same as `pkcs12cert`. Uses the provided password to decrypt the PKCS#12 archive. | `pkcs12certPass(pass string, input string) string` |
| `pemToPkcs12` | Takes a PEM encoded certificate and key and creates a base64 encoded PKCS#12 archive. | `pemToPkcs12(cert string, key string) string` |
| `pemToPkcs12Pass` | Same as `pemToPkcs12`. Uses the provided password to encrypt the PKCS#12 archive. | `pemToPkcs12Pass(cert string, key string, pass string) string` |
| `fullPemToPkcs12` | Takes a PEM encoded certificates chain and key and creates a base64 encoded PKCS#12 archive. | `fullPemToPkcs12(cert string, key string) string` |
| `fullPemToPkcs12Pass` | Same as `fullPemToPkcs12`. Uses the provided password to encrypt the PKCS#12 archive. | `fullPemToPkcs12Pass(cert string, key string, pass string) string` |
| `filterPEM` | Filters PEM blocks with a specific type from a list of PEM blocks.. | `filterPEM(pemType string, input string) string` |
| `filterCertChain` | Filters PEM block(s) with a specific certificate type (`leaf`, `intermediate` or `root`) from a certificate chain of PEM blocks (PEM blocks with type `CERTIFICATE`). | `filterCertChain(certType string, input string) string` |
| `jwkPublicKeyPem` | Takes an json-serialized JWK and returns an PEM block of type `PUBLIC KEY` that contains the public key. [See here](https://golang.org/pkg/crypto/x509/#MarshalPKIXPublicKey) for details. | `jwkPublicKeyPem(jwkjson string) string` |
| `jwkPrivateKeyPem` | Takes an json-serialized JWK and returns an PEM block of type `PRIVATE KEY` that contains the private key. [See here](https://pkg.go.dev/crypto/x509#MarshalPKCS8PrivateKey) for details. | `jwkPrivateKeyPem(jwkjson string) string` |
| `toYaml` | Takes an interface, marshals it to yaml. It returns a string, even on marshal error (empty string). | `toYaml(v any) string` |
| `fromYaml` | Function converts a YAML document into a `map[string]any`. | `fromYaml(str string) map[string]any` |
### Sprig functions
The Infisical Secrets Operator integrates with the [Sprig library](https://github.com/Masterminds/sprig) to provide additional helper functions.
<Note>
We've removed `expandEnv` and `env` from the supported functions for security reasons.
</Note>
## Global configuration
To configure global settings that will apply to all instances of `InfisicalSecret`, you can define these configurations in a Kubernetes ConfigMap.