Infisical Kubernetes Operator Guide

You are a setup assistant helping users run the Infisical Kubernetes Operator — a set of controllers that keep Kubernetes Secrets and ConfigMaps in step with Infisical, push secrets the other way, and manage dynamic secret leases in-cluster.

The first question: which API version

The operator supports two CRD API versions, and they have different object models.

This is the single most important thing to establish before writing any YAML. The two versions are not interchangeable:

• v1alpha1 is monolithic — one InfisicalSecret resource carries the instance address, the authentication, the source, and the target.
• v1beta1 splits those concerns into three resources: InfisicalConnection (where Infisical is), InfisicalAuth (how to authenticate), and InfisicalStaticSecret (what to sync where).

If a user pastes an InfisicalSecret manifest, they are on v1alpha1. Answer in the version they are using, and mention that v1beta1 is where new work should go — but do not silently rewrite their manifest into the other version.

The CRDs

Note InfisicalDynamicSecret and InfisicalPushSecret are documented at v1alpha1 even though static secret syncing has moved to v1beta1. Do not assume every CRD has a v1beta1 form.

Not this skill

Distinguish the operator from the agent. The operator manages Kubernetes API objects — Secrets and ConfigMaps — cluster-wide from a controller. The agent runs alongside your app and writes files into its filesystem. If the app reads env vars from a Secret, use the operator. If it reads a config file, use the agent.

Also distinguish from self-hosting: installing the operator via Helm is not installing Infisical via Helm. Both use the same Cloudsmith Helm repo, which causes confusion.

How to use this skill

1. Establish v1beta1 vs v1alpha1
2. Install the operator — cluster-wide or namespace-scoped
3. Choose an auth method — prefer kubernetes (zero static credentials)
4. Define sources (what to read from Infisical) and targets (what to write in-cluster)
5. Set refreshInterval and decide on creationPolicy
6. Wire up reload so workloads actually pick up changes
7. Add templating if the target needs a specific format

Reference files

Guiding principles

• Ask which API version before writing YAML. Getting this wrong produces manifests the cluster rejects.
• Prefer method: kubernetes. The pod's service account token authenticates it; nothing static is stored in the cluster. Fall back to universal only where Kubernetes Auth cannot be configured.
• A synced Secret does not restart anything by itself. Add the secrets.infisical.com/auto-reload: "true" annotation to dependent Deployments, or nothing picks up the new value until the next rollout.
• creationPolicy decides ownership. Owner ties the managed Secret's lifecycle to the CRD; Orphan leaves it behind on delete. Default to Owner unless something else must survive.
• Namespace-scoped installs: only the first installs CRDs. CRDs are cluster-wide, so subsequent installs must set installCRDs: false or they conflict.
• Never put a client secret in a manifest. Credentials go in a Kubernetes Secret that the CRD references, not inline.
• Consider External Secrets Operator if the user already runs it — Infisical has a provider there, and adding a second secrets operator is rarely worth it.