The Infisical Kubernetes Operator: Sync Secrets Into Your Cluster

Your secrets live in Infisical, but your workloads run in Kubernetes. The Infisical Kubernetes Operator closes that gap. It syncs secrets from Infisical into your clusters as native Kubernetes secrets, keeps them available at pod startup, and keeps them current after every rotation, automatically. This walkthrough covers what the operator is, how it works, and how to deploy it.

The operator is built around three custom resources that form a chain. At the bottom sits the `InfisicalConnection`, which points at the Infisical instance your secrets live in. The `InfisicalAuth` resource points at that connection and handles how the cluster proves who it is. The secret resource points at the auth and declares what to sync and where to put it.

So the secret names the auth, the auth names the connection, and that is the whole chain. You define the connection and auth once, then every secret in the cluster references them instead of repeating that setup. They do not just share configuration. The auth logs in a single time, and that token is reused across every secret that points at it, so adding more secrets does not multiply login traffic or memory.

The operator runs inside your cluster. It uses the auth to log in over the connection, pulls the secrets you asked for from Infisical, and writes them out as a native Kubernetes secret that your pods read like any other. It rechecks on an interval you define so the cluster copy stays in sync.

If you have run the External Secrets Operator (ESO) before, this maps cleanly. The connection and auth play the role of a secret store, and each secret resource plays the role of an external secret.

The piece that is a little different is the breadth. This one operator does three jobs. It syncs secrets in, which is the path covered here. It can also push secrets from the cluster back into Infisical, and it can broker dynamic leased secrets. Push and dynamic each get their own walkthrough. This one stays on the sync-in path.

Installation is a couple of Helm commands into the operator's own namespace. The full chart values live in the operator documentation. Installing brings up the controller and registers the three custom resource definitions. A quick `kubectl get pods` confirms the operator pod is running, and the cluster now recognizes the `InfisicalConnection`, `InfisicalAuth`, and `InfisicalStaticSecret` resource types. From here, the rest is defining those three resources and letting the operator take over.

Start with the connection. `InfisicalConnection` points your operator at an Infisical instance. On Infisical Cloud, that is `app.infisical.com`, or the EU region endpoint if that is where your data lives. Apply it, and the operator confirms it can reach Infisical as the `ready` column flips to `true`. You set this once, and every secret in the cluster reuses it.

Next comes the auth. `InfisicalAuth` references the connection and picks an authentication method. The operator supports a range of methods through Infisical's machine identities, and which one you reach for comes down mostly to where the operator runs, because it can lean on whatever workload identity the platform already provides.

On Amazon Elastic Kubernetes Service (EKS), that is AWS authentication. The operator's pod already holds an AWS identity through an IAM Roles for Service Accounts (IRSA) role or an EKS pod identity attached ahead of time. It signs a request with that identity, sends it to Infisical, and Infisical verifies the request directly with AWS. Apply it, and the operator authenticates and caches a short-lived token.

That handshake has a real advantage. The whole exchange stays outbound, because Infisical checks the operator's identity with AWS rather than reaching back into your cluster. Your EKS API server can stay completely private. Teams running on other platforms can lean on the equivalent workload identity, such as Kubernetes-native authentication with a service account.

Last comes the static secret, the part that does the work. `InfisicalStaticSecret` references the auth, then points at one or more sources in Infisical. Each source is a project, an environment, and a path. The operator pulls back every secret it finds at those locations and writes them into a single Kubernetes object it creates, kept in sync at the interval you set.

That object is usually a native Kubernetes secret, but it can also be a config map for the nonsensitive configuration you keep in Infisical alongside your secrets. The output does not have to be a one-to-one copy either. You can template it, so four separate values like host, port, user, and password become a single connection string shaped exactly the way your app expects. There is conditional and loop support for more involved cases too.

Apply it, and `kubectl get secrets` shows a native Kubernetes secret in the cluster. The operator created it and now owns its lifecycle.

Infisical stays the source of truth. What lives in the cluster is a synced copy, and the manifest references it by path, never by value. That makes the manifest safe to commit to Git. A workload consumes the secret like any other, pulling it with `envFrom` in a deployment, and the values show up live inside the running container.

When a value changes in Infisical, two things have to happen. The secret has to update, and the workloads using it have to pick up the new value. Within the refresh interval, the operator updates the Kubernetes secret to match. On Enterprise, you are not bound to that interval at all, and changes can be pushed instantly, so secrets update the moment the value changes in Infisical. This is the foundation of automated secret rotation.

Updating the secret is not enough on its own. A pod that already loaded the old value as an environment variable keeps running until something restarts it. That is where the `secrets.infisical.com/auto-reload: true` annotation comes in. With it set, when the managed secret changes, the operator rolls the workload for you. With ESO, teams typically add a separate tool like Stakater Reloader to do this. Here it is built into the operator.

The External Secrets Operator is a genuinely good, broadly compatible operator, and it even has an Infisical provider, so some teams already pull Infisical secrets into their clusters with it. The differences with the first-party Infisical operator are the built-in reload and the breadth: one operator that syncs in, pushes out, and brokers dynamic secrets, rather than a sync plus a separate generators add-on.

If you are weighing a move off HashiCorp Vault, Infisical has migration tooling that translates concepts instead of just copying values. It maps your key-value secrets over, turns the Kubernetes auth method into machine identities, secrets-engine rules into dynamic secrets, and your HashiCorp Configuration Language (HCL) policies into rules.

A few things matter once this is past a single cluster. You can scope the install to specific namespaces with their own role-based access control, so one team's secrets stay isolated. Every sync is governed and audited in Infisical. The operator exposes Prometheus metrics, and it runs on EKS, Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), OpenShift, and the rest.

If you would rather your secrets land as files mounted inside the pods instead of as Kubernetes-native secrets, the Kubernetes CSI driver and the agent injector cover that pattern.

That is the Infisical Kubernetes Operator. Three reusable resources get your Infisical secrets into your cluster as native Kubernetes secrets your apps already know how to read. Reload is built in, and it is one operator across syncing secrets in, pushing them out, and brokering dynamic leases. From here, push and dynamic secrets each get their own walkthrough, and if you are coming from v1 of the operator or moving over from Vault, the migration docs cover both.