Authorization Proxy is an implementation of Kubernetes sidecar container to provide a common interface for API endpoint authentication and authorization. It caches the policies from Athenz, and provides a reverse proxy interface to control access on specific URL endpoints.
Client request can be authenticated and authorized by:
- OAuth2 access token
- Role token in the HTTP/HTTPS request header
- Role certificate on mTLS
Requires go 1.23 or later.
Authorization Proxy acts as a reverse proxy sitting in front of the server application. When the client request for specific URL endpoint of the server application, the request comes to authorization proxy first.
To authenticate the request, the authorization proxy should know which client identity (role) can take an action on which URL endpoint, therefore the Athenz authorizer is introduced.
The Athenz authorizer periodically updates the access token JWK, role token public key, and Athenz policy data from the Athenz Server. It decodes and validates the policy data. The decoded policy will store in the memory cache inside the Athenz authorizer for later authorization checks. The Athenz authorizer also helps to extract client credentials from the HTTP/HTTPS request header.
The authorization proxy will call the Athenz authorizer and check if the client can take an action to a specific URL endpoint. If the client is allowed to take an action the URL endpoint, the request will then be forwarded to the server application with authorization information.(HTTP request headers)
The authorization proxy will return 401 Unauthorized to the client whenever the client credentials are missing/invalid, or the client identity (role) presented in the client credentials has no privilege to take the specific action on the specific URL endpoints.
The mapping rules describe the elements used in the authorization proxy. You can configure which Athenz domains are effective in the Authorization Proxy, and design your own sets of Athenz policies to control client access on the server application's endpoints.
The mapping rules are described as below.
| Concept | Description | Map to (Athenz) | Example |
|---|---|---|---|
| Client Identity | Client Identity presented in the client credentials | Role | access token scope |
| Action | HTTP/HTTPS request method | Action | POST |
| Resource | HTTP/HTTPS request URL path, supports wildcard | Resource | /api/* |
When a request is authorized by the authorization proxy, the following HTTP headers is added in the request.
| HTTP Header Name | Description | Example |
|---|---|---|
| X-Athenz-Principal | Authorized principal | principal |
| X-Athenz-Role | Authorized role (A comma-separated string if there is more than one) | role1,role2,role3 |
| X-Athenz-Domain | Authorized domain | domain |
| X-Athenz-Client-ID | Authorized client ID | client-id |
| X-Athenz-Issued-At | Unix timestamp in second that the authorized identity was issued | 1596158946 |
| X-Athenz-Expires-At | Unix timestamp in second that the authorized identity expires | 1596158953 |
The example configuration file is here. For detail explanation, please read config.go.
- Releases