Athenz vs. SPIRE Comparison

General

 Athenz
 SPIRE
License
Apache v2
Apache v2
Components
Management Server (Java)
Token Server (Java)
UI (Node.js)
Server (Go)
User Community
Small
Big

License

Both technologies are available under fully open source licenses.

Components

Athenz includes 3 major components: Management Server, Token Server and UI. The servers are written in Java using Jetty 9.4.x. The servers provide a REST interface with clients libraries available in Java and Go. The Athenz UI is a Node.Js 12.x application. The service identity agents and various utilities are all Go applications. The major component in Spire is the server written in Go. The identity agents are also Go applications. Client libraries are available in Go, Java and C++ languages.

User Community

Spire has a big user community and is hosted by the Cloud Native Computing Foundation (CNCF) as an incubation-level project. While Athenz powers most of workloads deployed within Yahoo/Verizon Media with identity certificates, it is just starting to focus on building its user community by joining CNCF and applying as a sandbox-level project.

Athenz vs. SPIRE Comparison

Management

 Athenz
 SPIRE
Delegated Management Support
Yes
No
Full Featured Self Serve UI
Yes
No
Tenancy Support
Yes
Multiple instances through federation

Delegated Management Support

In Spire setup a single instance is associated with a unique trust domain and administrator invokes commands against the server directly.

Athenz, on other hand, has the concept of User Authorities where you integrate with your existing User Authentication System such as Okta, LDAP or even Unix users. The system administrator then creates a top level domain for each product in the same instance and assigns administrator access for those domains to individual users or groups. For example, sports and mail products have their own completely separate domains with their own administrators. If sports and mail administrators want to register their own services, the server authenticates and authorizes those requests and allows them to complete those requests. Furthermore, each product domain can create their own subdomains with further delegated management. For example, the sports domain administrator can create 3 separate sub-domains: sports.prod, sports.stage, and sports.dev where sports.prod only allows their production engineers access while sports.stage and sports.dev have developers access to those domains.

Full Featured Self Serve UI

Athenz provides a full features UI (a Node.js application) where domain administrators can login and create roles, groups, policies and services for their domains. It also provides the capability to register services and authorize which providers can launch them (e.g. sports may deploy their api service in Kubernetes), so it will authorize Kubernetes agent to launch any instance with api service, while they might also deploy their backend service in AWS thus only authorize AWS agent to deploy instances with backend service. The UI also provides easy access to review and confirm/reject any role member access operations to satisfy Governance, Risk and Compliance requirements if required.

Tenancy Support

To support a single organization with different products and administrations, Spire requires multiple instances to be deployed and managed and setup federation between those instances in order to provide interoperability between services of those products. Athenz only provides a single deployment where each product is assigned its own top level/trust domain with their own set of administrators (as described in the Delegated Management Support above). Having a single deployment allows a single team within the organization to manage and secure that instance as opposed to managing and maintaining multiple independent instances.

Athenz vs. SPIRE Comparison

Service Identity Support

 Athenz
 SPIRE
Full SPIFFE Standard Implementation
Support for SPIFFE ID URIs
only in X.509 Certs
Yes
Issue both identity JWT Tokens
and X.509 certificates
X.509 Certificates
Yes
Kubernetes Support
Yes
Yes
AWS Support
EC2, ECS, EKS, Fargate, Lambda
EC2
Azure Support
Yes
Yes
GCP Support
No
Yes

SPIFFE Standard Implementation

The SPIFFE standard defines how services identity themselves using IDs implemented as Uniform Resource Identifiers (URIs), how they're included in SPIFFE Verifiable Identity Document (SVIDs) such as X.509 Certificates and an API specification for issuing and/or retrieving SVIDs known as the Workload API. The Spire is the reference implementation of SPIFFE specifications thus supports the above listed items. Athenz supports issuing X.509 Certificates to registered services with SPIFEE IDs as URIs, however it does not implement the Workload APIs. Athenz provides its own REST API that agents use to retrieve certificates and provide them to services as PEM encoded files on disk.

Issue both identity JWT Tokens and X.509 Certificates

Spire provides SPIFEE IDs in both X.509 Certificates and JWT Tokens for services to identify themselves. Athenz only issues X.509 Certificates which allows us to enforce that all services within the organization use mTLS for service to service communication.

Kubernetes Support

Both Athenz and Spire provide support for issuing identity to workloads deployed within Kubernetes clusters. The Kubernetes team at Yahoo/Verizon Media has open-sourced several components that integrate Kubernetes with Athenz:

  • k8s-athenz-identity is a Kubernetes control plane component which aims to securely provision unique Athenz identities (X.509 certificates) for pods.
  • k8s-athenz-webhook is an API for a Kubernetes authentication and authorization webhook that integrates with Athenz for access checks. It allows flexible resource mapping from Kubernetes resources to Athenz.
  • k8s-athenz-istio-auth is a controller which converts Athenz domains to Istio RBAC custom resources.

AWS Support

Both Athenz and Spire provide support for issuing identity to workloads deployed within AWS EC2. Spire relies on AWS metadata documents for attestation while Athenz requires both metadata document and AWS Temporary credentials (with empty IAM roles that do not expose access to any resources). The attestation in Athenz is based on the AWS account registered with the trust domain thus allowing any instance that is bootstrapped as part of Auto Scaling Group auto-scale deployments to obtain service identities without explicitly registering the EC2 instances. Additionally, based on AWS temporary credentials support, Athenz supports issuing X.509 certificates to Fargate and Lambda workloads in AWS. There are efforts in the Spire community to add support for serverless workloads in AWS.

Azure Support

Both Athenz and Spire provide support for issuing identity to workloads deployed within Azure Virtual Machines. Both seem to rely on the Azure JWT Tokens that VMs would obtain based on their managed service identities and present for attestation to their respective servers.

GCP Support

Spire issues identities to workloads deployed in GCP based on the GCP Instance Identity Tokens. Athenz currently does not have an agent supporting GCP workloads.

Athenz vs. SPIRE Comparison

Authorization Support

 Athenz
 SPIRE
RBAC Authorization System
with JWT Access Tokens
Yes
No
mTLS Bound JWT
Access Token Support
Yes
N/A

RBAC Authorization System with JWT Access Tokens

Athenz provides fine-grained role-based access control (RBAC) support for a centralized management system with support for control-plane access control decisions and a decentralized enforcement mechanism suitable for data-plane access control decisions. It issues industry standard JWT Access Token to all registered services that clients present to their respective resource servers to enforce both authentication (based on their x.509 client certificates) and authorization (based on their access tokens).

mTLS Bound JWT Access Token Support

Athenz Token Service issues industry standard mTLS bound OAuth2 access tokens that application services can use to both authenticate (x.509 identity certificates) and authorize requests based on policies defined in the Athenz Management System. With the mTLS binding, the replay attacks are only possible if both the access token and the private key of the service have been compromised.

Athenz vs. SPIRE Comparison

Extensibility

 Athenz
 SPIRE
Pluggable DataStore Plugin
Yes (default using MySQL)
Yes (default using sqlite3)
Key Store Plugin
Yes
Yes

Pluggable DataStore Plugin

Both Athenz and Spire are extensible when it comes to providing plugin capabilities to store required data. Spire is using sqlite3 by default, while Athenz provides a datastore plugin for MySQL servers (using AWS Aurora for AWS deployments).

Key Store Plugin

Both Athenz and Spire are extensible when it comes to providing plugin capabilities to store and sign certificates. Athenz also provides support for crypki which is open-sourced by the Verizon Media Paranoids Team and is a simple service for interacting with an HSM or other PKCS #11 device. It supports minting and signing of both SSH and x509 certificates.