External Secrets Operator gets credentials into Kubernetes. Who can read them?

What changes when Infisical secrets reach Kubernetes?

Kubernetes warns that someone allowed to create a Pod in a namespace can use that access to read its Secrets. That matters even when a separate vault supplied the credentials. Kubernetes documentation

External Secrets Operator with Infisical can remove manual credential copying from releases. It also creates a destination your team must protect: the Kubernetes Secret consumed by the application.

The useful question is who can read that copy, who can redirect the delivery, and whether a changed credential actually reaches the running service. A successful sync answers only part of that.

Here are six decisions that make this integration worth operating, from choosing the controller to proving rotation. This is for teams already running Kubernetes; secret management alone is no reason to adopt it.

What does External Secrets Operator actually do?

Infisical holds the source credentials. External Secrets Operator, usually shortened to ESO, authenticates to that provider and reconciles an ExternalSecret resource: a declaration of which values should be delivered. The controller constructs a Kubernetes Secret for the workload to consume. ESO describes that reconciliation here.

That separation is useful. The application can use Kubernetes' familiar delivery mechanism while the team manages source credentials centrally. The tradeoff is explicit: a copy exists inside the cluster, with its own access rules and lifecycle.

Consider a hypothetical distributor whose order service connects its storefront to a warehouse system. Centralized delivery can replace someone updating credentials by hand during each release. But if an unrelated reporting workload can read the warehouse credential, the delivery worked and the security design failed.

Budget for the controller's upkeep, the application's reload behavior and a recovery test. A lean team needs to know who owns all three before adding another component to production.

Which six decisions make ESO with Infisical dependable?

1. Choose the controller you intend to operate

ESO's Infisical provider and the native Infisical Kubernetes Operator are separate integrations. Infisical's own operator uses its own resources; its current documentation separates connection, authentication and static-secret delivery. Do not combine instructions from the two products and assume they describe one installation. Infisical operator documentation

Our recommendation: if your team already operates ESO across several secret providers, assess Infisical as another provider within that established process. If you are starting an Infisical-centered setup, compare the native operator against ESO on support, upgrade effort and the delivery features your applications actually need.

Check the installed controller and resource versions against their matching documentation. ESO's official release history shows ongoing releases, including v2.14.0 on October 23, 2026. An old headline about paused development is not a current support assessment. Assign someone to review releases and security fixes.

2. Separate the identities that deliver and consume credentials

The Infisical provider documentation describes Kubernetes authentication using service-account tokens, as well as other methods. Its Kubernetes option requires Infisical to reach the cluster's TokenReview API. Authentication by a service-account token is not, by itself, mutual TLS; treat transport trust and identity verification as separate questions.

Have the engineer demonstrate the authentication path supported by your installed release. Then review what the delivery identity may retrieve. The order service should receive the warehouse access it needs, without bringing payroll or unrelated production credentials into reach.

Keep ownership visible at both ends. Identify who can change the provider identity's permissions and who can change the application's secret references. A tightly limited application identity will not compensate for unrestricted authority to rewrite the delivery policy.

3. Treat namespaces and stores as explicit access decisions

A SecretStore is bound to a namespace. A ClusterSecretStore can serve ExternalSecrets across namespaces and supports conditions that restrict where it is usable. Shared configuration is convenient, but the access it creates deserves an explicit review.

For a business operating several brands or internal products, decide whether shared delivery is appropriate for each credential. Ask for a demonstrated denial when a workload from another area requests it. Names and folders help people navigate; enforced permissions decide access.

The Infisical provider makes an especially important distinction: its default lookup path is not a security boundary. Enforce source-side restrictions through Infisical access controls. Review the controller's own permissions too, so a broad operator identity does not quietly undo the separation you intended. Provider scope guidance

4. Protect the copy Kubernetes stores

Kubernetes Secrets are unencrypted in etcd by default, according to the Kubernetes documentation. Verify the actual encryption-at-rest settings of your platform, least-privilege role-based access control, and which containers receive each value. A managed service may configure protections for you; confirm them rather than assuming.

Review indirect access as carefully as direct reads. The ability to create workloads can expose secrets those workloads are allowed to mount. Include deployment tooling, administrative access and emergency support paths in the review. Protect backups and diagnostic exports as part of the same policy.

For the distributor, this means examining the warehouse credential's whole destination environment. The question is not simply whether the order service needs it. The team must also know which other people and workloads can obtain it, and how that access is removed when responsibilities change.

5. Define rotation from the source to the running process

ESO offers several refresh policies. Periodic refresh, the default, updates on its configured interval; OnChange updates when the ExternalSecret's metadata or specification changes. CreatedOnce is not scheduled source polling. Choose behavior deliberately, and check the version-specific details rather than assuming every upstream edit is immediately delivered.

Delivery is only one stage. Kubernetes documents that an existing container consuming a Secret through an environment variable will not see its update until the container restarts. Your engineer must establish how the particular application adopts a new credential and prove it with a real request. Kubernetes consumption behavior

Agree on a rotation window with the system issuing the credential. Where supported, an overlap between old and new credentials can allow a controlled transition. Where it is not supported, plan the interruption and recovery explicitly. Retiring the old credential should be a verified event, not an assumption attached to a green dashboard.

Agree on what happens to existing copies during an outage or removal of the integration. Retaining a value may preserve service while also preserving unwanted access. Deleting it may stop a critical workload. Ask the engineer to demonstrate the configured behavior and its consequences, including a fresh application start while the source is unavailable.

6. Give failures an owner and a recovery path

ESO's Ready condition describes the target Secret and its synchronization state. It does not prove that the warehouse API accepted the application's last request. Keep synchronization health and business-operation health visible as separate signals.

Decide who responds when source authentication expires, the provider is unreachable, or an application fails after a credential change. Test these conditions outside production. The operator should know whether to restore connectivity, correct access, reload a workload or stop affected work.

We would require a recovery record containing the affected service, last successful refresh, observed application failure and responsible person. Keep credential values out of that record. Someone should be able to diagnose the failure without creating a new security incident in a chat or ticket.

What should the business ask to see before launch?

Ask for a short acceptance demonstration around one integration. The order service should complete a representative request, adopt a changed test credential and reject access from a workload that has no business using it. The engineer should explain any delay between the source change and application adoption.

Include a recovery rehearsal after the normal rotation test. Use disposable credentials to establish whether a restored environment starts with the intended access, whether a revoked identity stays revoked, and whether someone can identify an obsolete copy. Record the result without copying the secret into the evidence. This is an acceptance requirement, not a claim that either controller automatically performs these checks.

Keep those checks tied to the service's importance. A customer checkout dependency deserves a different recovery target from an overnight report. The target should reflect what the business can tolerate, and the team should measure whether the complete chain meets it.

For finance and operations, ask where the maintenance work will sit. Controller upgrades, upstream account changes and application releases may belong to different people. Put the handoffs in the support scope, including who is available during a planned rotation. That is a more useful cost discussion than comparing license prices while leaving the operating work unassigned.

This is where the integration earns its place. Reliable delivery reduces manual handling; tested access and recovery let the company rely on that automation. A green sync indicator is a starting point. The acceptance standard is a working service whose credentials can be changed and withdrawn safely.

Our platform and cloud work includes release ownership, operational visibility and recovery. For this integration, that means reviewing the destination permissions and application behavior alongside the provider connection.

Does this keep credentials away from an AI agent?

Only when the surrounding design denies the agent access to them. ESO delivers a credential to a workload; if an agent or its tools can read that workload's environment or mounted secrets, the credential remains available to it. Centralized delivery does not change that fact.

Use a separate authorization decision when the agent should request an operation without possessing the upstream credential. A broker can perform an allowed action and return a limited result. Our article on AI agents and .env files examines that boundary; it is a different problem from keeping Kubernetes workloads supplied with current credentials.

For the distributor, a conventional order service may legitimately need warehouse credentials. A support agent may need only an authorized order-status lookup. Treat those as different consumers, even when they serve the same customer journey.

Start with the application that creates the most operational friction when access changes. Establish its ownership, delivery behavior and recovery standard. Talk with us about that integration if your team needs help making it dependable.

FAQs

Is External Secrets Operator safe to use?

It can be part of a secure design. Its safety depends on the version you run, provider permissions, cluster access, storage protections and workload behavior. Require evidence of denied access and successful rotation; installing a controller is not a security certification.

Should we choose ESO or the Infisical Kubernetes Operator?

Evaluate them as separate controllers. An existing ESO estate gives you an established operating model; an Infisical-centered setup may benefit from its native integration. Compare supported features and the work your team will own. Neither choice removes the need to protect destination Secrets.

Does rotating a secret automatically update the application?

Not necessarily. Source rotation, controller refresh and application adoption are separate stages. Environment-variable consumers need a restart to observe a changed Kubernetes Secret. Verify the application's actual behavior and retire the old credential under a tested transition plan.

Do we need Kubernetes to use a secret manager?

No. This article concerns an integration for teams already using Kubernetes. Choose secret delivery around the platform and applications you operate. Adding a cluster solely to distribute credentials creates an operating burden without establishing that it solves your business problem.

Is External Secrets Operator open source?

Yes. The official ESO repository identifies an Apache-2.0 license. Software licensing is separate from the cost of running it: include maintenance, incident response and any paid provider or support services in your decision.