> ## Documentation Index
> Fetch the complete documentation index at: https://infisical.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Kubernetes Agent Injector

> How to use the Infisical Kubernetes Agent Injector to inject secrets directly into Kubernetes pods.

## Overview

The Infisical Kubernetes Agent Injector allows you to inject secrets directly into your Kubernetes pods. The Injector will create a [Infisical Agent](https://infisical.com/docs/integrations/platforms/infisical-agent.md) container within your pod that syncs secrets from Infisical into a shared volume mount within your pod.

> [!TIP]
>
> For a complete Helm chart reference including all configurable values, see the [Agent Injector Helm chart documentation](https://infisical.com/docs/self-hosting/helm-charts/agent-injector.md).

The Infisical Agent Injector will patch and modify your pod's deployment to contain an [Infisical Agent](https://infisical.com/docs/integrations/platforms/infisical-agent.md) container which renders your Infisical secrets into a shared volume mount within your pod.

The Infisical Agent Injector is built on [Kubernetes Mutating Admission Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers), and will watch for `CREATE` and `UPDATE` events on pods in your cluster.
The injector is namespace-agnostic, and will watch for pods in any namespace, but will only patch pods that have the `org.infisical.com/inject` annotation set to `true`.

```mermaid theme={"dark"}
flowchart LR
    subgraph Secrets Management
        SS(Infisical) --> INJ(Infisical Injector)
    end

    subgraph Pod
        INJ --> INIT(Agent Init Container)
        INIT --> V(Volume)
        V <--> P(Application)
    end
    
```

## Install the Infisical Agent Injector

To install the Infisical Agent Injector, you'll need to install our helm charts using [Helm](https://helm.sh/).

```bash theme={"dark"}
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
helm repo update
helm install --generate-name infisical-helm-charts/infisical-agent-injector
```

After installing the helm chart you can verify that the injector is running and working as intended by checking the logs of the injector pod.

```bash theme={"dark"}
kubectl logs deployment/infisical-agent-injector 
2025/05/19 14:20:05 Starting infisical-agent-injector...
2025/05/19 14:20:05 Generating self-signed certificate...
2025/05/19 14:20:06 Creating directory: /tmp/tls
2025/05/19 14:20:06 Writing cert to: /tmp/tls/tls.crt
2025/05/19 14:20:06 Writing key to: /tmp/tls/tls.key
2025/05/19 14:20:06 Starting HTTPS server on port 8585...
2025/05/19 14:20:06 Attempting to update webhook config (attempt 1)...
2025/05/19 14:20:06 Successfully updated webhook configuration with CA bundle
```

## Windows support

By default the agent injector is built for Linux-based pods, but supports injecting into Windows-based pods.

**To inject into Windows-based pods, no extra configuration is needed.** The agent injector will automatically detect and handle injections into Windows-based pods.

However, if you're trying to run the agent injector itself on a Windows-based pod, you'll need to configure your helm values.yaml file to point to a Windows-based image.

The Agent Injector will only run on and inject into Windows-based pods that are running on the supported Windows versions:

* **Windows Server 2022**
* **Windows Server 2019**

We're looking to add support for other Windows versions in the future. If you're using a different Windows version, please let us know by opening [an issue](https://github.com/Infisical/infisical-agent-injector/issues/new), and we'll look into adding support for your desired version as soon as possible.

You'll need to set the `nodeSelector.kubernetes.io/os` label to `windows` and set the image tag to a Windows-based image. Below are two examples for Windows Server 2019 and Windows Server 2022.

> [accordion] Run Agent Injector on Windows Server 2019
>
> Create your `values.yaml` file and add the following:
>
> ```yaml values.yaml theme={"dark"}
> image:
>   repository: infisical/infisical-agent-injector
>   tag: "v0.1.4-windows-server-2019"
>
> nodeSelector:
>   kubernetes.io/os: windows
> ```
>
> Install the agent injector using the values.yaml file you created above.
>
> ```bash theme={"dark"}
> helm install --generate-name infisical-helm-charts/infisical-agent-injector -f values.yaml
> ```

> [accordion] Run Agent Injector on Windows Server 2022
>
> Create your `values.yaml` file and add the following:
>
> ```yaml values.yaml theme={"dark"}
> image:
>   repository: infisical/infisical-agent-injector
>   tag: "v0.1.4-windows-server-2022"
>
> nodeSelector:
>   kubernetes.io/os: windows
> ```
>
> Install the agent injector using the values.yaml file you created above.
>
> ```bash theme={"dark"}
> helm install --generate-name infisical-helm-charts/infisical-agent-injector -f values.yaml
> ```

> [!TIP]
>
> Note that Windows support is only supported in version `v0.1.4` and above. If you're using an older version, you'll need to upgrade to `v0.1.4` or above to use Windows support.

## Supported annotations

The Infisical Agent Injector supports the following annotations:

> [accordion] org.infisical.com/inject
>
> The inject annotation is used to enable the injector on a pod. Set the value to `true` and the pod will be patched with an Infisical Agent container on update or create.

> [accordion] org.infisical.com/inject-mode
>
> The inject mode annotation is used to specify the mode to use to inject the secrets into the pod.
>
> * `init`: The init method will create an init container for the pod that will render the secrets into a shared volume mount within the pod. The agent init container will run before any other containers in the pod runs, including other init containers.
> * `sidecar`: The sidecar method will create a sidecar container for the pod that will render the secrets into a shared volume mount within the pod. The agent sidecar container will run alongside the main container in the pod. This means that the secrets rendered will always be in sync with your Infisical secrets.
> * `sidecar-init`: The sidecar-init method will create the init container and the sidecar container from the other two methods. The init container will run before any other container and fetch the secrets from the start and the sidecar container will keep the secrets in sync throughout the lifecycle of the deployment.

> [accordion] org.infisical.com/agent-config-map
>
> The agent ConfigMap annotation is used to specify the name of the ConfigMap that contains the configuration for the injector. The ConfigMap must be in the same namespace as the pod.

> [accordion] org.infisical.com/agent-cache-enabled
>
> Whether to enable client-side caching of dynamic secret leases. Defaults to `false`. If you set this to `true`, the agent will persist any dynamic secret leases across restarts of the agent. This is especially useful when using the `sidecar-init` inject mode, to pass the dynamic secret leases created in the init container to the sidecar container.
> This will ensure that no new leases are created except those initially created in the init container. The sidecar container will register the leases created in the init container and start managing them from that point onwards.

> [accordion] org.infisical.com/agent-image
>
> Specify a custom agent image to use for the agent sidecar / init container(s). Example: `infisical/cli:0.43.32`.
> If not specified, the most recent stable version of the Infisical Agent will be used.

> [accordion] org.infisical.com/agent-revoke-on-shutdown
>
> Whether to revoke all managed dynamic secret leases and machine identity access tokens on shutdown. Defaults to `false`.
>
> If you set this to `true`, all managed dynamic secret leases and machine identity access tokens will be revoked when a `SIGTERM` signal is sent to the agents container *(such as when a pod is terminated or when the pod is restarted)*.
>
> **Note:** In disaster events such as cluster power outages, a `SIGTERM` signal won't be sent to the agents container, and the credentials will not be revoked.

> [accordion] org.infisical.com/agent-client-max-retries
>
> How many times to retry failed API requests such as authentication, secret retrieval, etc. Defaults to `3` retries. Refer to the [Retrying mechanism](https://infisical.com/docs/integrations/platforms/infisical-agent.md#retrying-mechanism) documentation for more information on how to configure the retry strategy.

> [accordion] org.infisical.com/agent-client-max-delay
>
> The maximum delay between retries. Defaults to `5s` (5 seconds). Refer to the [Retrying mechanism](https://infisical.com/docs/integrations/platforms/infisical-agent.md#retrying-mechanism) documentation for more information on how to configure the retry strategy.

> [accordion] org.infisical.com/agent-client-base-delay
>
> The base delay between retries. Defaults to `200ms` (200 milliseconds). Refer to the [Retrying mechanism](https://infisical.com/docs/integrations/platforms/infisical-agent.md#retrying-mechanism) documentation for more information on how to configure the retry strategy.

> [accordion] org.infisical.com/agent-limits-cpu
>
> The maximum CPU limit for the agent containers.
>
> Linux Pods: Defaults to `500m` (500 milliCPUs).
> Windows Pods: Defaults to `500m` (500 milliCPUs).

> [accordion] org.infisical.com/agent-requests-cpu
>
> The minimum CPU request for the agent containers.
>
> Linux Pods: Defaults to `100m` (100 milliCPUs).
> Windows Pods: Defaults to `100m` (100 milliCPUs).

> [accordion] org.infisical.com/agent-limits-memory
>
> The maximum memory limit for the agent containers.
>
> Linux Pods: Defaults to `128Mi` (128 megabytes).
> Windows Pods: Defaults to `512Mi` (512 megabytes).

> [accordion] org.infisical.com/agent-requests-memory
>
> The minimum memory request for the agent containers.
>
> Linux Pods: Defaults to `64Mi` (64 megabytes).
> Windows Pods: Defaults to `256Mi` (256 megabytes).

> [accordion] org.infisical.com/agent-limits-ephemeral
>
> The maximum ephemeral storage limit for the agent containers. Doesn't have an explicit default value. The default value will conform to the default ephemeral storage limit for the pod.

> [accordion] org.infisical.com/agent-requests-ephemeral
>
> The minimum ephemeral storage request for the agent containers. Doesn't have an explicit default value. The default value will conform to the default ephemeral storage request for the pod.

> [accordion] org.infisical.com/agent-set-security-context
>
> Whether to set a security context on the injected agent containers. Defaults to `false`.
>
> When set to `true`, the agent containers will be configured with a hardened security context. The default security context applied is:
>
> ```yaml theme={"dark"}
> securityContext:
>   allowPrivilegeEscalation: false
>   capabilities:
>     drop:
>       - ALL
>   privileged: false
>   readOnlyRootFilesystem: true
>   runAsGroup: 2000
>   runAsNonRoot: true
>   runAsUser: 1000
> ```
>
> You can customize individual security context settings using the other `agent-security-context-*` annotations.

> [accordion] org.infisical.com/agent-security-context-run-as-user
>
> The user ID to run the agent containers as. Defaults to `1000`.
>
> If set to `0`, `runAsNonRoot` will automatically be set to `false` to allow the container to run as root.
>
> > [!NOTE]
> >
> > This annotation is only applicable when `org.infisical.com/agent-set-security-context` is set to `true`.

> [accordion] org.infisical.com/agent-security-context-run-as-group
>
> The group ID to run the agent containers as. Defaults to `2000`.
>
> If set to `0`, `runAsNonRoot` will automatically be set to `false` to allow the container to run as the root group.
>
> > [!NOTE]
> >
> > This annotation is only applicable when `org.infisical.com/agent-set-security-context` is set to `true`.

> [accordion] org.infisical.com/agent-security-context-read-only-root-filesystem
>
> Whether to mount the root filesystem as read-only. Defaults to `true`.
>
> > [!TIP]
> >
> > This setting only applies to Linux-based pods.
> > Windows containers do not support read-only root filesystems.
>
> > [!NOTE]
> >
> > This annotation is only applicable when `org.infisical.com/agent-set-security-context` is set to `true`.

> [accordion] org.infisical.com/agent-security-context-privileged
>
> Whether to run the agent containers in privileged mode. Defaults to `false`.
>
> > [!WARNING]
> >
> > Running containers in privileged mode grants full access to the host and should only be used when absolutely necessary.
>
> > [!NOTE]
> >
> > This annotation is only applicable when `org.infisical.com/agent-set-security-context` is set to `true`.

> [accordion] org.infisical.com/agent-security-context-allow-privilege-escalation
>
> Whether to allow privilege escalation for the agent containers. Defaults to `false`.
>
> When set to `false`, the container cannot gain more privileges than its parent process. This is a recommended security hardening measure.
>
> > [!NOTE]
> >
> > This annotation is only applicable when `org.infisical.com/agent-set-security-context` is set to `true`.

## ConfigMap configuration

### Supported fields

When you're configuring a pod to use the injector, you must create a ConfigMap in the same namespace as the pod you want to inject secrets into.
The entire config needs to be of string format and needs to be assigned to the `config.yaml` key in the ConfigMap. You can find a full example of the config at the end of this section.

> [accordion] infisical.address
>
> The address of your Infisical instance. This field is optional and will default to `https://app.infisical.com` if not provided.

> [accordion] infisical.revoke-credentials-on-shutdown
>
> Whether to revoke all managed dynamic secret leases and machine identity access tokens on shutdown. Default: `"false"`.
>
> If this is set to `true`, all managed dynamic secret leases and machine identity access tokens will be revoked when a `SIGTERM` signal is sent to the agents container *(such as when a pod is terminated or when the pod is restarted)*.
>
> **Note:** In disaster events such as cluster power outages, a `SIGTERM` signal won't be sent to the agents container, and the credentials won't be revoked.
>
> > [!NOTE]
> >
> > This is currently unsupported on Windows-based pods, and will only work when injecting into Linux-based pods.
> >
> > It's recommended to use the annotation `org.infisical.com/agent-revoke-on-shutdown: "true"` instead of configuring the revoke on shutdown on the ConfigMap. Refer to the [Supported annotations](https://infisical.com/docs/integrations/platforms/kubernetes-injector.md#supported-annotations) documentation for more information on how to configure the revoke on shutdown through annotations.

> [accordion] infisical.auth.type
>
> The authentication type to use to connect to Infisical. Supported types: `kubernetes`, `ldap-auth`, and `aws-iam`.
>
> * For `kubernetes`: The pod's default service account will be used to authenticate with Infisical. See [Kubernetes Auth](https://infisical.com/docs/documentation/platform/identities/kubernetes-auth.md).
> * For `ldap-auth`: LDAP credentials are used. See [LDAP Auth](https://infisical.com/docs/documentation/platform/identities/ldap-auth).
> * For `aws-iam`: The pod's AWS credential chain (IRSA or instance profile) is used to authenticate. See [AWS Auth](https://infisical.com/docs/documentation/platform/identities/aws-auth.md).

> [accordion] infisical.auth.config.identity-id
>
> The ID of the machine identity to use for authentication. This field is required when `infisical.auth.type` is set to `kubernetes`, `ldap-auth`, or `aws-iam`.

> [accordion] infisical.auth.config.username
>
> The LDAP username to use for LDAP authentication.
> This field is required if the `infisical.auth.type` is set to `ldap-auth`.

> [accordion] infisical.auth.config.password
>
> The LDAP password to use for LDAP authentication.
> This field is required if the `infisical.auth.type` is set to `ldap-auth`.

> [accordion] infisical.retry-strategy.max-retries
>
> How many times to retry failed API requests such as authentication, secret retrieval, etc. Defaults to `3` retries. Refer to the [Retrying mechanism](https://infisical.com/docs/integrations/platforms/infisical-agent.md#retrying-mechanism) documentation for more information on how to configure the retry strategy.
>
> > [!NOTE]
> >
> > You can also configure the max retries through annotations. Refer to the [Supported annotations](https://infisical.com/docs/integrations/platforms/kubernetes-injector.md#supported-annotations) documentation for more information on how to configure the max retries through annotations.

> [accordion] infisical.retry-strategy.max-delay
>
> The maximum delay between retries. Defaults to `5s` (5 seconds). Refer to the [Retrying mechanism](https://infisical.com/docs/integrations/platforms/infisical-agent.md#retrying-mechanism) documentation for more information on how to configure the retry strategy.
>
> > [!NOTE]
> >
> > You can also configure the max delay through annotations. Refer to the [Supported annotations](https://infisical.com/docs/integrations/platforms/kubernetes-injector.md#supported-annotations) documentation for more information on how to configure the max delay through annotations.

> [accordion] infisical.retry-strategy.base-delay
>
> The base delay between retries. Defaults to `200ms` (200 milliseconds). Refer to the [Retrying mechanism](https://infisical.com/docs/integrations/platforms/infisical-agent.md#retrying-mechanism) documentation for more information on how to configure the retry strategy.
>
> > [!NOTE]
> >
> > You can also configure the base delay through annotations. Refer to the [Supported annotations](https://infisical.com/docs/integrations/platforms/kubernetes-injector.md#supported-annotations) documentation for more information on how to configure the base delay through annotations.

> [accordion] cache.persistent.type
>
> The type of persistent caching to use. Currently only `kubernetes` is available, and will only work within Kubernetes environments.
>
> > [!NOTE]
> >
> > It's recommended to use the annotation `org.infisical.com/agent-cache-enabled: "true"` instead of configuring the cache on the ConfigMap. Refer to the [Supported annotations](https://infisical.com/docs/integrations/platforms/kubernetes-injector.md#supported-annotations) documentation for more information on how to configure the cache through annotations.

> [accordion] cache.persistent.service-account-token-path
>
> The path to the Kubernetes service account token to use for encrypting the persistent cache. Required when using `kubernetes` cache type. Defaults to `/var/run/secrets/kubernetes.io/serviceaccount/token`.
>
> > [!NOTE]
> >
> > It's recommended to use the annotation `org.infisical.com/agent-cache-enabled: "true"` instead of configuring the cache on the ConfigMap. Refer to the [Supported annotations](https://infisical.com/docs/integrations/platforms/kubernetes-injector.md#supported-annotations) documentation for more information on how to configure the cache through annotations.

> [accordion] templates\[]
>
> The templates hold an array of templates that will be rendered and injected into the pod.

> [accordion] templates\[].destination-path
>
> The path to inject the secrets into within the pod.
> If not specified, this will default to `/shared/infisical-secrets`. If you have multiple templates and don't provide a destination path, the destination paths will default to `/shared/infisical-secrets-1`, `/shared/infisical-secrets-2`, etc.

> [accordion] templates\[].template-content
>
> The content of the template to render.
> This will be rendered as a [Go Template](https://pkg.go.dev/text/template) and will have access to the following variables.
> It follows the templating format and supports the same functions as the [Infisical Agent](https://infisical.com/docs/integrations/platforms/infisical-agent.md#quick-start-infisical-agent)

### Authentication

The Infisical Agent Injector supports Machine Identity [Kubernetes Auth](https://infisical.com/docs/documentation/platform/identities/kubernetes-auth.md), [LDAP Auth](https://infisical.com/docs/documentation/platform/identities/ldap-auth), and [AWS Auth](https://infisical.com/docs/documentation/platform/identities/aws-auth.md) authentication.

> [accordion] Kubernetes Auth
>
> To configure Kubernetes Auth, you need to set the `auth.type` field to `kubernetes` and set the `auth.config.identity-id` to the ID of the machine identity you wish to use for authentication.
>
> ```yaml theme={"dark"}
> auth:
>   type: "kubernetes"
>   config:
>     identity-id: "<your-infisical-machine-identity-id>"
> ```
>
> ### Example ConfigMap
>
> ```yaml config-map.yaml theme={"dark"}
> apiVersion: v1
> kind: ConfigMap
> metadata:
>   name: demo-config-map
> data:
>   config.yaml: |
>     infisical:
>       address: "https://app.infisical.com"
>       auth:
>         type: "kubernetes"
>         config:
>           identity-id: "<your-infisical-machine-identity-id>"
>     templates:
>       - destination-path: "/path/to/save/secrets/file.txt"
>         template-content: |
>           {{- with secret "<your-project-id>" "dev" "/" }}
>           {{- range . }}
>           {{ .Key }}={{ .Value }}
>           {{- end }}
>           {{- end }}
> ```
>
> ```bash theme={"dark"}
> kubectl apply -f config-map.yaml
> ```

> [accordion] LDAP Auth
>
> To configure LDAP Auth, you need to set the `auth.type` field to `ldap-auth` and set the `auth.config.identity-id` to the ID of the machine identity you wish to use for authentication. Configure the `auth.config.username` and `auth.config.password` to the username and password of the LDAP user to authenticate with.
>
> ```yaml theme={"dark"}
> auth:
>   type: "ldap-auth"
>   config:
>     identity-id: "<your-infisical-machine-identity-id>"
>     username: "<your-ldap-username>"
>     password: "<your-ldap-password>"
> ```
>
> ### Example ConfigMap
>
> ```yaml config-map.yaml theme={"dark"}
> apiVersion: v1
> kind: ConfigMap
> metadata:
>   name: demo-config-map
> data:
>   config.yaml: |
>     infisical:
>       address: "https://app.infisical.com"
>       auth:
>         type: "ldap-auth"
>         config:
>           identity-id: "<your-infisical-machine-identity-id>"
>           username: "<your-ldap-username>"
>           password: "<your-ldap-password>"
>     templates:
>       - destination-path: "/path/to/save/secrets/file.txt"
>         template-content: |
>           {{- with secret "<your-project-id>" "dev" "/" }}
>           {{- range . }}
>           {{ .Key }}={{ .Value }}
>           {{- end }}
>           {{- end }}
> ```
>
> ```bash theme={"dark"}
> kubectl apply -f config-map.yaml
> ```

> [accordion] AWS IAM Auth
>
> To configure AWS IAM Auth, you need to set the `auth.type` field to `aws-iam` and set the `auth.config.identity-id` to the ID of the machine identity you wish to use for authentication. The pod must run in an AWS environment (e.g., EKS with IRSA or EC2 with instance profile) so that the agent can use the pod's ambient AWS credential chain to authenticate with Infisical.
>
> ```yaml theme={"dark"}
> auth:
>   type: "aws-iam"
>   config:
>     identity-id: "<your-infisical-machine-identity-id>"
> ```
>
> ### Example ConfigMap
>
> ```yaml config-map.yaml theme={"dark"}
> apiVersion: v1
> kind: ConfigMap
> metadata:
>   name: demo-config-map
> data:
>   config.yaml: |
>     infisical:
>       address: "https://app.infisical.com"
>       auth:
>         type: "aws-iam"
>         config:
>           identity-id: "<your-infisical-machine-identity-id>"
>     templates:
>       - destination-path: "/path/to/save/secrets/file.txt"
>         template-content: |
>           {{- with secret "<your-project-id>" "dev" "/" }}
>           {{- range . }}
>           {{ .Key }}={{ .Value }}
>           {{- end }}
>           {{- end }}
> ```
>
> ```bash theme={"dark"}
> kubectl apply -f config-map.yaml
> ```

To use the ConfigMap in your pod, you'll need to add the `org.infisical.com/agent-config-map` annotation to your pod's deployment. The value of the annotation is the name of the ConfigMap you created above. The ConfigMap must be in the same namespace as the pod you're injecting into.

```yaml theme={"dark"}
apiVersion: v1
kind: Pod
metadata:
  name: demo
  labels:
    app: demo
  annotations:
    org.infisical.com/inject: "true" # Set to true for the injector to patch the pod on create/update events
    org.infisical.com/inject-mode: "init" # The mode to use to inject the secrets into the pod. init|sidecar
    org.infisical.com/agent-config-map: "name-of-config-map" # The name of the ConfigMap that you created above, which contains all the settings for injecting the secrets into the pod
spec:
  # ...
```

## Quick start

In this section we'll walk through a full example of how to inject secrets into a pod using the Infisical Agent Injector.
In this example we'll create a basic nginx deployment and print a Infisical secret called `API_KEY` to the container logs.

### Create secrets in Infisical

First you'll need to create the secret in Infisical.

* `API_KEY`: The API key to use for the nginx deployment.

Once you've created the secret, save your project ID, environment slug, and secret path, as these will be used in the next step.

### Configuration

To use the injector you must create a ConfigMap in the same namespace as the pod you want to inject secrets into. In this example we'll create a ConfigMap in the `test-namespace` namespace.

The agent injector will authenticate with Infisical using a [Kubernetes Auth](https://infisical.com/docs/documentation/platform/identities/kubernetes-auth.md) machine identity. Please follow the [instructions](https://infisical.com/docs/documentation/platform/identities/kubernetes-auth.md) to create a machine identity configured for Kubernetes Auth.
The agent injector will use the service account token of the pod to authenticate with Infisical.

The `template-content` will be rendered as a [Go Template](https://pkg.go.dev/text/template) and will have access to the following variables. It follows the templating format and supports the same functions as the [Infisical Agent](https://infisical.com/docs/integrations/platforms/infisical-agent.md#quick-start-infisical-agent)
The `destination-path` refers to the path within the pod that the secrets will be injected into. In this case we're injecting the secrets into a file called `/infisical/secrets`.

Replace the `<your-project-id>`, `<your-environment-slug>`, with your project ID and the environment slug of where you created your secrets in Infisical. Replace `<your-infisical-machine-identity-id>` with the ID of your machine identity configured for Kubernetes Auth.

```yaml config-map.yaml theme={"dark"}
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-infisical-config-map
  namespace: test-namespace
data:
  config.yaml: |
    infisical:
      address: "https://app.infisical.com"
      auth:
        type: "kubernetes"
        config:
          identity-id: "<your-infisical-machine-identity-id>"
    templates:
      - destination-path: "/infisical/secrets"
        template-content: |
          {{- with secret "<your-project-id>" "<your-environment-slug>" "/" }}
          {{- range . }}
          {{ .Key }}={{ .Value }}
          {{- end }}
          {{- end }}
```

Now apply the ConfigMap:

```bash theme={"dark"}
kubectl apply -f config-map.yaml
```

### Injecting secrets into your pod

To inject secrets into your pod, you'll need to add the `org.infisical.com/inject: "true"` annotation to your pod's deployment.

The `org.infisical.com/agent-config-map` annotation will point to the ConfigMap we created in the previous step. It's important that the ConfigMap is in the same namespace as the pod.

We're creating a nginx deployment with a PVC to store the database data.

```yaml nginx.yaml theme={"dark"}
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  namespace: test-namespace
  labels:
    app: nginx
  annotations:
    org.infisical.com/inject: "true"
    org.infisical.com/inject-mode: "init"
    org.infisical.com/agent-config-map: "nginx-infisical-config-map"
spec:
  containers:
    - name: simple-app-demo
      image: nginx:alpine
      command: ["/bin/sh", "-c"]
      args:
        - |
          export $(cat /infisical/secrets | xargs)
          echo "API_KEY is set to: $API_KEY"
          nginx -g "daemon off;"
```

### Applying the deployment

To apply the deployment, you can use the following command:

```bash theme={"dark"}
kubectl apply -f nginx.yaml
```

It may take a few minutes for the pod to be ready and for the Infisical secrets to be injected. You can check the status of the pod by running:

```bash theme={"dark"}
kubectl get pods -n test-namespace
```

### Verifying the secrets are injected

To verify the secrets are injected, you can check the pod's logs:

```bash theme={"dark"}
kubectl exec -it pod/nginx-pod -n test-namespace -- cat /infisical/secrets

Defaulted container "simple-app-demo" out of: simple-app-demo, infisical-agent-init (init)

API_KEY=sk_api_... # The secret you created in Infisical
```

Additionally you can now check that the `API_KEY` secret is being logged to the nginx container logs:

```bash theme={"dark"}
kubectl logs pod/nginx-pod -n test-namespace                              
Defaulted container "simple-app-demo" out of: simple-app-demo, infisical-agent-init (init)
API_KEY is set to: sk_api_... # The secret you created in Infisical
```

## Troubleshooting

> [accordion] The pod is stuck in `Init` state
>
> If the pod is stuck in `Init` state, it means the Agent init container is failing to start or is stuck in a restart loop.
> This could be due to a number of reasons, such as the machine identity not having the correct permissions, or trying to fetch secrets from a non-existent project/environment.
>
> You can check the logs of the infisical init container by running:
>
> ```bash theme={"dark"}
> # For deployments
> kubectl logs deployment/your-deployment-name -c infisical-agent-init -n "<namespace>"
>
> # For pods
> kubectl logs pod/your-pod-name -c infisical-agent-init -n "<namespace>"
> ```
>
> You can also check the logs of the pod by running:
>
> ```bash theme={"dark"}
> kubectl logs deployment/postgres-deployment -n test-namespace
> ```
>
> When checking the logs of the agent init container, you may see something like the following:
>
> ```bash theme={"dark"}
> Starting infisical agent...
> 11:10AM INF starting Infisical agent...
> 11:10AM INF Infisical instance address set to https://daniel1.tunn.dev
> 11:10AM INF template engine started for template 1...
> 11:10AM INF attempting to authenticate...
> 11:10AM INF new access token saved to file at path '/home/infisical/config/identity-access-token'
> 11:10AM ERR unable to process template because template: literalTemplate:1:9: executing "literalTemplate" at <secret "3c0d3ff6-165c-4dc9-b52c-ff3ffaedfce311111" "dev" "/">: error calling secret: CallGetRawSecretsV3: Unsuccessful response [GET https://daniel1.tunn.dev/api/v3/secrets/raw?environment=dev&expandSecretReferences=true&include_imports=true&secretPath=%2F&workspaceId=3c0d3ff6-165c-4dc9-b52c-ff3ffaedfce311111] [status-code=404] [response={"reqId":"req-ljqNq567jchFrK","statusCode":404,"message":"Project with ID '3c0d3ff6-165c-4dc9-b52c-ff3ffaedfce311111' not found during bot lookup. Are you sure you are using the correct project ID?","error":"NotFound"}]
> + echo 'Agent failed with exit code 1'
> + exit 1
> Agent failed with exit code 1
> ```
>
> In the above error, the project ID was invalid in the ConfigMap.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.