Enable zero trust core principles like traffic encryption, AuthN, AuthZ, Dynamic Trust & Least privilege access
Service Identity in the form of short-lived X.509 certificate to all workloads deployed in private or public clouds. Stronger security by mTLS authentication.
Authorize all authenticated clients using fine-grained role-based (RBAC) access control.
Consolidated service serving various downstream security implementations, including support for non-user entities.
Athenz 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 provides service identity X.509 certificates for services running in common providers like OpenStack and AWS that can be used for mutual TLS authentication.The term service here is more generic than a traditional service. A service identity could represent a command, job, daemon, workflow, as well as a service. The launch management software itself (i.e. OpenStack, AWS EC2, Lambda, etc) must be a known entity registered with Athenz, and provisioned to create new identities in its namespace. So for example AWS EC2 can create instances in the same account, Openstack can bootstrap hosts for its tenants, and so on. When the process or instance is launched, various specific information is collected by the Service Identity Agent (SIA) to present to Athenz to prove itself, and if this matches what is provisioned in Athenz and verified by the Provider itself through a callback mechanism, a X.509 identity TLS certificate is issued that can be used both as a client certificate to talk to other Athenz-protected services and as a server certificate to accept incoming TLS connections from other Athenz services.
The diagram on the right shows an instance being bootstrapped with its own Athenz Service Identity X.509 certificates.
Athenz is a set of services and libraries supporting 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.
A traditional centralized access control model requires any Athenz enabled application to contact Athenz Management Service directly to determine if a specific authenticated principal (user and/or service) has been authorized to carry out the given action on the requested resource. The application receives a simple boolean answer whether or not the request should be processed or rejected. In this model, the Athenz Management Service is the only component that needs to be deployed and managed within your environment. It is suitable for provisioning and configuration use cases where the number of requests processed by the server is small and the latency for authorization checks is not important.
The diagram on the left shows a typical control plane provisioning request handled by Athenz protected service.
For serving/runtime use cases where the application is required to handle large number of requests per second and latency is a concern, Athenz provides a decentralized access control model where the check to see if a given principal (user and/or service) has been authorized to carry out the given action on the requested service is done on the host itself using the Athenz local policy engine library.
With the decentralized model, the authorization policies defining which roles have been authorized to carry out specific actions on resources are asynchronously updated on application hosts and used by the Athenz local policy engine to evaluate the authorization check. In this model, the principal needs to contact Athenz Token Service first to retrieve an Authorization RoleToken for the request and submit that Token as part of its request to the Athenz protected service.
The diagram on the right shows a typical decentralized authorization request handled by Athenz protected service.
Domains are namespaces, strictly partitioned, providing a context for authoritative statements to be made about entities it contains.
To implement access control, we have policies in our domain that govern the use of our resources. A policy is a set of assertions (rules) about granting or denying an operation/action on a resource.
A role can be thought of as a group, 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 Athens that can assume a role are called principals. These principals are authenticated and can be users or services. Athens currently provides service identity and authentication support.