github/infisical
1
0
Fork 0
mirror of https://github.com/Infisical/infisical.git synced 2026-01-09 15:38:03 -05:00
Code Issues Packages Projects Releases Wiki Activity

doc: template metadata for infisical secret k8 resource

Browse Source
This commit is contained in:
Sheen Capadngan
2026-01-06 03:53:03 +08:00
parent 39e0f462de
commit 290be19778
1 changed files with 105 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -970,6 +970,13 @@ Please refer to the [templating functions documentation](/integrations/platforms
</Accordion>
<Accordion title="managedKubeSecretReferences[].template.metadata">
Define custom labels and annotations for the managed Kubernetes secret. This allows you to specify metadata that should be applied to the managed secret separately from the InfisicalSecret itself.
For detailed information on how metadata propagation works and examples, see the [Propagating Labels & Annotations](#propagating-labels-&-annotations) section.
</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.
@@ -1078,6 +1085,13 @@ Please refer to the [templating functions documentation](/integrations/platforms
</Accordion>
<Accordion title="managedKubeConfigMapReferences[].template.metadata">
Define custom labels and annotations for the managed Kubernetes ConfigMap. This allows you to specify metadata that should be applied to the managed ConfigMap separately from the InfisicalSecret itself.
This field works the same way as `template.metadata` for managed secrets. For detailed information on how metadata propagation works and examples, see the [Propagating Labels & Annotations](#propagating-labels-&-annotations) section.
</Accordion>
## Applying CRD
Once you have configured the InfisicalSecret CRD with the required fields, you can apply it to your cluster.
@@ -1564,10 +1578,13 @@ stringData:
## 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:
The operator provides flexible options for managing labels and annotations on managed Kubernetes secrets.
<Accordion title="Default Behavior (Without template.metadata)">
By default, the operator will transfer all labels & annotations present on the `InfisicalSecret` to the managed Kubernetes secret to be created.
### Example
<Accordion title="Example propagation">
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
@@ -1578,28 +1595,95 @@ Thus, if a specific label is required on the resulting secret, it can be applied
annotations:
example.com/annotation-to-be-passed-to-managed-secret: "sample-value"
spec:
..
authentication:
...
# ... auth config ...
managedKubeSecretReferences:
...
- secretName: managed-token
secretNamespace: default
```
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>
<Accordion title="Custom Metadata (With template.metadata)">
When you specify `template.metadata` in your template configuration, you have full control over which labels and annotations are applied to the managed secret:
- Labels and annotations from `template.metadata` are used exclusively on the managed secret
- InfisicalSecret labels and annotations are NOT propagated to the managed secret
- This allows you to keep InfisicalSecret-specific metadata separate from the managed secret metadata
<Tip>
To prevent propagation while using `template.metadata`, pass empty objects for labels and/or annotations:
```yaml
template:
metadata:
labels: {}
annotations: {}
```
</Tip>
### Example
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
name: infisicalsecret-with-template-metadata
labels:
managed-by: infisical-operator
annotations:
example.com/cr-specific: "metadata"
spec:
authentication:
# ... auth config ...
managedKubeSecretReferences:
- secretName: managed-secret-with-custom-metadata
secretNamespace: default
template:
includeAllSecrets: true
metadata:
labels:
app: my-application
environment: production
tier: backend
annotations:
secret.example.com/description: "Production database credentials"
secret.example.com/owner: "platform-team"
```
This would result in the following managed secret to be created:
```yaml
apiVersion: v1
data: ...
kind: Secret
metadata:
annotations:
secret.example.com/description: "Production database credentials"
secret.example.com/owner: "platform-team"
labels:
app: my-application
environment: production
tier: backend
name: managed-secret-with-custom-metadata
namespace: default
type: Opaque
```
</Accordion>