Athenz is an open-source platform for service authentication and fine-grained authorization. It issues each workload, whether a virtual machine, a container or a CI job, a short-lived X.509 certificate that proves its identity, and it stores role-based policies that decide whether an authenticated service may perform an action on a resource. It addresses the problem of trust between services in dynamic infrastructure: shared passwords and long-lived API keys do not scale to thousands of services that start and stop constantly across clouds. Athenz was developed at Yahoo to secure its own large service estate and was open-sourced in 2017. It joined the CNCF as a sandbox project in January 2021, the level the CNCF Landscape still lists.
CNCF daily · Sprint 2, day 7 · Key Management
At a glance
| Category | Provisioning › Key Management |
| CNCF status | Sandbox. Accepted January 26, 2021 |
| Written in | Java for the ZMS and ZTS servers; Go for the service identity agents and many clients |
| License | Apache 2.0 |
| Identity | Short-lived X.509 certificates (typically valid for up to 30 days and refreshed daily), used for mutual TLS |
| Authorization | Role-based access control with allow and deny policies, checked centrally or locally |
| Platforms | AWS (EC2, EKS, Fargate), Azure VMs, Google Cloud (GCE, GKE), Kubernetes, OpenStack, GitHub Actions |
Architecture
flowchart TB
ADMIN[Admins and teams<br/>UI or zms-cli] ==>|domains roles policies| ZMS[ZMS<br/>management service]
ZMS ==>|signed domain data| ZTS[ZTS<br/>token and certificate service]
SIA[SIA agent<br/>on each workload] ==>|attested identity request| ZTS
ZTS -.->|verify instance| PROV[Platform provider<br/>AWS, GCP, Azure, Kubernetes]
ZTS ==>|X.509 identity cert| SIA
SIA ==> APP[Client service]
APP ==>|mTLS with identity cert| SVC[Target service]
SVC ==> ZPE[ZPE<br/>local policy engine]
ZTS -.->|signed policy files| ZPE
ZTS -.->|role certs, access tokens,<br/>cloud credentials| APP
classDef actor fill:#eceff1,stroke:#455a64,stroke-width:1.5px,color:#1d1c1a
classDef core fill:#0f766e,stroke:#064e4a,stroke-width:2px,color:#ffffff
classDef ctrl fill:#ede7f6,stroke:#5e35b1,stroke-width:1.5px,color:#1d1c1a
classDef data fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#1d1c1a
classDef sec fill:#fce4ec,stroke:#ad1457,stroke-width:1.5px,color:#1d1c1a
class ADMIN actor
class ZMS,ZTS,SIA,ZPE core
class PROV ctrl
class APP,SVC data
Key: teal blocks are the project itself, blue are workloads, purple is the platform used to verify instances, grey are people. Thick arrows show the main path, dashed arrows verification and distribution of policies and credentials.
| Component | Responsibility |
|---|---|
| ZMS (management service) | The source of truth. Stores domains (one per team or product), their services, roles (sets of members) and policies (assertions granting or denying actions on resources). Supports delegated, multi-tenant administration and audit. |
| ZTS (token service) | The runtime service. Issues X.509 identity certificates after verifying the workload with its platform, plus role certificates, OAuth2 access tokens and temporary cloud credentials, and serves signed policy data. |
| SIA (service identity agent) | Runs with each workload, proves its identity to ZTS using platform attestation, and keeps its certificate refreshed. |
| ZPE (policy engine) | A library inside the target service that evaluates signed policy files locally, so authorization decisions need no network call. |
| UI and zms-cli | Web interface and command-line tool for managing domains, roles and policies. |
Design principle. Separate who you are from what you may do. Identity comes from short-lived certificates issued only after the platform confirms the workload (Athenz calls this framework Copper Argos), so there are no shared secrets to leak. Authorization comes from centrally managed policies that are distributed as signed data and enforced locally, so decisions are fast and still controlled in one place.
Production reference design
A typical deployment serves several teams across Kubernetes clusters and cloud accounts, with Athenz as the common identity layer.
- Run the control plane. Deploy ZMS and ZTS with highly available databases and certificate signing keys protected by an HSM or a cloud key management service, plus the UI. The repository documents a local and a production deployment.
- Model ownership. Create a domain per team (for example
payments), register its services (payments.api), and define roles and policies. A policy, as stored in ZMS, is a list of assertions:{ "name": "payments:policy.readers", "assertions": [ { "role": "payments:role.readers", "action": "read", "resource": "payments:invoices", "effect": "ALLOW" } ] } - Give workloads identity. Run the SIA on each instance or pod, using the provider for its platform (for example EKS or GKE), so every service receives and refreshes its own certificate. You can check what a workload holds with
openssl x509 -in <cert-file> -noout -subject -enddate. - Authenticate with mTLS. Configure services and gateways to require client certificates signed by the Athenz CA.
- Authorize locally. Use ZPE in the target service, or access tokens checked at a gateway, to enforce the policies on each request.
Typical uses include zero-trust service-to-service authentication in large multi-team environments, replacing long-lived cloud access keys with temporary credentials issued against Athenz identities, and consistent authorization across VMs, Kubernetes and multiple clouds.
Operational considerations
- The CA is critical. Protect the signing keys of ZTS with an HSM or cloud KMS, and plan key rotation. A compromised CA compromises every identity.
- Availability. Running workloads keep their current certificates and cached policies if ZTS is briefly unavailable, but new workloads cannot get identities. Run ZTS with several replicas in each region.
- Certificate refresh. Monitor certificate expiry on workloads. A broken SIA refresh leads to failures days later, when the certificate expires, which is easy to miss.
- Policy model discipline. Domains, roles and policies multiply quickly. Agree naming conventions and ownership early, and review role membership regularly.
- Ecosystem size. Athenz is a sandbox project with a smaller community than SPIFFE and SPIRE. Expect to build some integrations yourself.
Adoption
- Athenz was built at Yahoo, where it secures a very large internal service estate; Yahoo engineers remain its core maintainers.
- Engineers at Yahoo Japan (now part of LY Corporation) have published open-source Athenz integrations, such as authorization tools for Kubernetes.
- The project does not publish a long public list of adopters. Teams evaluating it should look at the GitHub activity and the maintainers’ availability for support.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| SPIFFE and SPIRE (CNCF Graduated) | Standard workload identity with attested X.509 and JWT SVIDs | Identity only, with a large ecosystem; see the SPIRE brief |
| cert-manager (CNCF Graduated) | Certificate issuance and renewal in Kubernetes | Managing TLS certificates rather than workload identity and authorization; see the cert-manager brief |
| Open Policy Agent (CNCF Graduated) | General-purpose policy engine | Authorization decisions, combined with a separate identity system |
| Cloud IAM (AWS IAM roles, GCP workload identity, Azure managed identities) | Provider-native identity | Single-cloud workloads accessing that cloud’s services |
| Service meshes (Istio, Linkerd) | Automatic mTLS and authorization between mesh workloads | Kubernetes-centred estates that already run a mesh |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| Identity and authorization in one platform | Sandbox project with a small community and few public adopters |
| Short-lived, attested certificates instead of shared secrets | Operating ZMS, ZTS, databases and a CA is significant work |
| Local policy evaluation for fast, offline-capable decisions | Its own model and APIs rather than the SPIFFE standard |
| Works across VMs, Kubernetes, multiple clouds and CI | Fewer ready-made integrations than SPIRE or service meshes |
| Proven at very large scale at Yahoo | Documentation assumes familiarity with its concepts |
Recommendation
Assess. Athenz is a capable, battle-tested system that combines workload identity with role-based authorization, and it can suit large organisations that want both from a single platform across clouds and VMs. Most teams starting today will find a larger ecosystem with SPIFFE and SPIRE for identity, combined with OPA or a service mesh for authorization. Evaluate Athenz if its integrated model fits your needs and you can operate its control plane.
References: CNCF project page · Athenz website · Athenz repository · CNCF Landscape