Athenz is an open source platform for X.509 certificate based service authentication and fine grained access control in dynamic infrastructures. It provides a generalized model for authorized service providers to launch other services identified by their X.509 certificates in an authorized way through a callback-based verification model. Athenz also supports role-based authorization (RBAC) for provisioning and configuration (centralized authorization) use cases as well as serving/runtime (decentralized authorization) use cases to handle on-box enforcement.
Athenz provides secure identity in the form of short-lived X.509 certificates for every workload or service deployed in private (e.g. OpenStack, Kubernetes, Screwdriver) or public cloud (e.g. AWS EC2, ECS, Fargate, Lambda). Using these X.509 certificates, clients and services establish secure connections and through mutual TLS authentication verify each other's identity. The service identity certificates are only valid for 30 days and the service identity agents (SIA) part of those frameworks automatically refresh them daily. The term service within Athenz is more generic than a traditional service. A service identity could represent a command, job, daemon, workflow, as well as both an application client and application service.
Once the client is authenticated with its X.509 certificate, the service can then check if the given client is authorized to carry out the requested action. 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 also provides a delegated management model that supports multi-tenant and self-service concepts. Learn More
A traditional centralized mechanism works as expected for services that are not dealing with the decentralized authorization: the server with resources can simply ask the ZMS directly about access, passing the service identity and resource/action information to get a simple boolean answer. It is suitable for provisioning and configuration use cases where latency for authorization checks is not important. Learn More
A more interesting scenario introduces the local policy engine (ZPE), and a few supporting changes. Rather than directly asking for an access check with a principal identity, the identity is instead used to get a ZToken, and that is presented to the target service until it expires. This mechanism allows a service to make a completely local access check against ZPE, given a ZToken and locally cached policies. Learn More
When working with AWS, Athenz provides support to access AWS services from on-prem services by using AWS temporary credentials rather than static credentials. Athenz ZTS server can be used to request AWS temporary credentials for configured AWS IAM roles.
Domains are namespaces, strictly partitioned, providing a context for authoritative statements to be made about the entities it contains.
To implement access control, we have policies in our domain that govern the use of our resources. A policy is set of assertions (rules) about granting or denying an operation/action on a resource.
A role can be thought of as a group and anyone in the group can assume the role that takes a particular action. Every policy assertion describes what can be done by a role.
The actors in Athenz that can assume a role are called principals. These principals are authenticated and can be users or services. Athenz currently provides service identity and authentication support.