Edera 1.12 brings workload identity to KubernetesEdera 1.12 brings workload identity to Kubernetes

The problem is not storing a secret

Kubernetes deployments still solve too many authentication problems with environment variables, Secrets, and credentials that live longer than they should. It works, but Laravel workers, CI jobs, and AI agents often end up using access patterns that are hard to audit and rotate properly. The real question is not where a secret is stored, but how to prove that the process using it is the process it claims to be.

Edera 1.12 adds SPIFFE and SPIRE-based workload identity for Edera zones. The goal is to give a workload a verifiable identity tied to its execution context instead of relying only on a key injected during deployment. In SPIFFE terms, that identity is represented by short-lived X.509 credentials known as SVIDs. (docs.edera.dev)

Identity only where it is needed

Edera runs a SPIRE agent inside every SPIRE-enabled zone rather than sharing one agent per node. That matters because a zone is an isolated virtual machine, and a conventional node-level agent cannot directly inspect what is happening inside it. The SPIRE server validates the zone through the edera-hypervisor node attestor, which asks the Edera daemon for confirmation. (docs.edera.dev)

Identity is not handed out automatically just because a workload runs in a SPIRE-enabled zone. When launching a workload, --enable-identity mounts the certificate material read-only at /run/spire/identity. For software that already supports SPIRE’s Workload API, --enable-spire-access exposes the agent socket at /shared/zone/sockets/agent.sock so the process can request and rotate its own credentials. (docs.edera.dev)

What this changes for a Laravel application

For a Laravel application running on Kubernetes, I would separate identities for the web container, Horizon workers, scheduled maintenance jobs, and CI processes. They do not all need access to the same services, even when they belong to the same repository and use the same base image. Workload selectors make it possible to scope an identity to a specific workload instead of giving implicit access to every process in a zone. (docs.edera.dev)

This is particularly useful when Laravel needs to authenticate to an internal service using mTLS, a private API, or infrastructure that already trusts SPIFFE identities. The certificate can be projected as files for tools that expect a conventional certificate and private key. Clients with native SPIFFE support can use the socket to fetch and rotate an SVID without copying credential files as part of deployment. (docs.edera.dev)

I also see a practical use for this in a homelab where personal services, runners, and experimental automation share a cluster. A CI runner building an application should not inherit the credentials used by a worker that handles payments, even if both run in the same Kubernetes environment. The same applies to AI agents: runtime isolation helps, but a separate identity also limits which services that runtime can request access to.

The minimum configuration to review

According to the documentation, SPIRE requires two alpha feature flags in daemon.toml, and both are disabled by default. After enabling them, the daemon must be restarted, the server started with protect-ctl host spire-start, and zones created with protect-ctl zone launch --with-spire. Enabling the server does not automatically turn every workload into a SPIFFE identity. (docs.edera.dev)

[features]
spire-v0 = "enabled"
object-capabilities-v0 = "enabled"

For a workload that only needs projected certificate files, this is the documented starting point. The meaningful decision is whether the process receives files managed by Edera or needs direct access to the Workload API. Those are separate grants and can be assigned independently. (docs.edera.dev)

protect-ctl workload launch --enable-identity

The fine print before replacing secrets

This does not magically remove every secret from a Laravel application. Your database, Redis instance, SMTP provider, or external API must support certificate-based authentication, exchangeable tokens, or an integration that turns the identity into a useful authorization decision. If a service only accepts a static password, that password still needs to come from somewhere.

Mounting a certificate is not enough to achieve least privilege either. Registration entries need selectors that are specific enough, because an entry that only uses zone-level selectors can match every workload in that zone. Edera also notes that image selectors alone cannot define a closed set of images; they need to be combined with zone-image-count when that is the intended policy. (docs.edera.dev)

The maturity level is the main caveat. The technical documentation labels SPIRE support as alpha and warns that the zone attestation identity is currently self-asserted by the in-zone agent, so it should not be treated as a hardened trust boundary. The Edera 1.12 announcement also calls it Early Access, so I would use it to design, test integrations, and uncover dependencies rather than immediately replacing an already-audited production model. (docs.edera.dev)

A sensible place to start

I would begin with one Laravel worker accessing a non-critical internal service through mTLS. It is a limited enough case to validate the whole lifecycle: attestation, issuance, mounting, renewal, and revocation. Once that works, separating CI, automation, and AI agents becomes less about distributing fewer secrets and more about writing an explicit policy for which workload can talk to which service.

Source: Edera 1.12 announcement Official documentation: Workload identity with SPIFFE and SPIRE