⚠️ Warning: This repository has been moved to AthenZ/authorization-proxy.
This repository is submitted to Athenz Open-Source Community. All ongoing developments and maintenances will continue in the new repository.
# update your local clone
git remote set-url origin https://github.com/AthenZ/authorization-proxy.git
- What is Authorization Proxy
- Use case
- Features to Debug
- Configuration
- License
- Contributor License Agreement
- About releases
- Authors
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.19 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.
Copyright (C) 2018 Yahoo Japan Corporation Athenz team.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.This project requires contributors to agree to a Contributor License Agreement (CLA).
Note that only for contributions to the authorization-proxy repository on the GitHub, the contributors of them shall be deemed to have agreed to the CLA without individual written agreements.
- Releases