Domain

Domains are namespaces, strictly partitioned, providing a context for authoritative statements to be made about the entities it contains.

Policies

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.

Resources

Resources aren't explicitly modeled in Athenz, they are referred to by name. A resource is something that is "owned" and controlled in a specific domain by the provider service. Each service using Athenz for authorization is responsible for defining their own resources and referencing them in their policy rules (assertions).

Actions

Similar to resources, actions are also controlled by the service owners. Athenz does not own nor enforce the actions on resources. They are only referenced in policies and used by Athenz to carry out authorization checks and return the appropriate response to the caller.

Roles

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.

Principal

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.

Groups

To simplify principal management, the users and services can be included in Groups. Then, the Group can be added as a member to any role within Athenz thus granting the members of that group access to the configured resources.

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) 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

Centralized Access Control

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 Athenz Management Service 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

Decentralized Access Control

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 an access token, 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 an access token and locally cached policies. Learn More

Zero Trust is a security model to defend against modern day adversaries. In a nutshell, the Zero Trust model stipulates that in order to establish or maintain a certain level of security, any and all trust amongst participating entities has to be explicit and limited , not implicit or inherited and broad or persistent. That is, by default a system or service will not trust any user or client. While this does not sound particularly revolutionary, it does overturn a few decades of common practice of perimeter security ("hard shell, soft internals") whereby a privileged position inside a network, such as being on a VPN, implicitly grants access to various services. Instead, in a Zero Trust network, the underlying assumption is that enterprise users, devices, applications, and data are at constant risk of compromise both from external as well as internal threats. As part of a typical Attack Life Cycle, after an initial compromise, attackers will attempt to move laterally within the target infrastructure. As a result, the surrounding environment of even "internal" services must be assumed to be hostile, untrusted. Zero Trust treats the surrounding environment as inherently untrusted, thereby mandating the application of a few core principles:

Traffic Encryption

All network traffic between services, clients, and components must be encrypted in transit, as all networks are considered hostile.

AuthN and AuthZ

Always authenticate and always verify authorization all the way up to an appropriate Root Of Trust.

Dynamic trust

Any given entity is trusted only for a limited duration, and only when it is expected (e.g., authenticated and authorized). Trust may also be context-dependent.

Least Privilege

Entities—whether people, organizations, hardware, or software—are granted only the least privilege required to accomplish their current tasks. Any particular grant of privilege ends when the task for which it was granted ends. New tasks require new grants of privilege.