General
 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 with identity certificates, it is just starting to focus on building its user community by joining CNCF and applying as a sandbox-level project.
Management
| 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.
Service Identity Support
| 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 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.
Authorization Support
| 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.
Extensibility
| 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 Yahoo 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.