docs(k8s): config map support

docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx

@@ -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
+<Tabs>
-# Verify managed secret is created
+  <Tab title="Managed Secret">
-kubectl get secrets -n <namespace of 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>