Athenzを完全理解したい願望

はい、書いてある通りです。athenz、理解したいです。 正直、個人開発レベルでは全然理解しなくていいやつです。しかし、大きな企業で、多くのサービスが動いていてサービス間でAPIを使い合いたいとかってなると必須の技術になると思います。いくら内部ネットワークとはいえね、認証された人だったりサービスのみにサービスの利用を限定しないと、もし仮に内部ネットワークに攻撃者が入ってしまった時に好き放題やられてしまうからね。 ということで、athenz完全理解を目指してやっていきたいと思う。

流れ

  1. athenzの各コンポーネントを紹介します。
  2. athenzで使われているRBACについて説明します
  3. athenzを自宅のクラスターにインストールします
  4. インストールしたathenzを使って色々と試してみたいと思います。（プロバイダとテナントの通信、擬似攻撃者になってみるなど）

そもそもathenzとは

アプリケーション間のアクセスを制御するためのプラットフォーム、ですね。 アクセス制御ってのは、REST APIなどのリソースに対して、権限を与えることだよね。 アクセス制御を実現するための構成要素としては、３つあって、識別、認証、認可、の３つだね。 で、athenzの認証だけど、RBACってのが使われているんだよね。

rbacとは

アクセス対象を役割ごとにグループ化する。んで、グループに対して権限を与える感じ。このグループのことをroleっていうんだよね。 大事なのは、人ではなく、roleに権限を与えるってこと。で、人をroleに追加する。 ちなみに、roleには色々あって、例えばcrudが全部できるroleも作れるし、閲覧しかできないroleを作ることもできる。 ちなみに、各roleに与える権限のことをポリシーという。これも大事。 roleにpolicyを付与する、という感じ。 リソースの提供者をプロバイダ、リソースの利用者をテナントという。そして、中央にathenzがいる。 で、識別情報のことをAthenz serviceとかっていう。ここがちょっと難しいね。あとでドメインって名前も出てくるけどさ。

athenzのアクセス制御の流れ

テナントがプロバイダにアクセスするとき、まずテナントは中央のathenzにトークンを（ロールトークン）発行してももらう。このとき、テナント自身の存在を証明するためにx509証明書を提示する。（ここで一つ目の疑問。誰がx509証明書を発行してくれるのか？）で、発行してもらったトークンをhttpヘッダーにつけて、プロバイダにアクセスする。 プロバイダではathenz-proxyがapiの前で動いている。んで、中央にいるathenzから取得しておいた情報とアクセスを照らし合わせて、apiにプロキシするかしないかを決定する感じです。

アーキテクチャとコンポーネント

1. Management Server (ZMS)
The ZMS is the central authority for managing and provisioning domain-based roles, policies, and resource permissions. It acts as the control plane where administrators define access control rules and service configurations.

Key Features:
Domain Management: Organizes services and resources into "domains" (like a namespace) with associated roles and policies.
Role and Policy Definitions: Allows creation of roles (e.g., admin, reader) and policies specifying which roles can access specific resources.
Audit Trails: Keeps a record of all configuration changes for security and compliance purposes.
REST API: Provides APIs for managing domains, roles, and policies programmatically.
Storage: Persistently stores configuration data in databases like MySQL.


Athenz is a robust system for managing service-to-service authentication and fine-grained access control through its primary components: ZMS (Management Server), ZTS (Token Server), and its User Interface.

1. Management Server (ZMS)
The ZMS is the central authority for managing and provisioning domain-based roles, policies, and resource permissions. It acts as the control plane where administrators define access control rules and service configurations.

Key Features:
Domain Management: Organizes services and resources into "domains" (like a namespace) with associated roles and policies.
Role and Policy Definitions: Allows creation of roles (e.g., admin, reader) and policies specifying which roles can access specific resources.
Audit Trails: Keeps a record of all configuration changes for security and compliance purposes.
REST API: Provides APIs for managing domains, roles, and policies programmatically.
Storage: Persistently stores configuration data in databases like MySQL.


2. Token Server (ZTS)
The ZTS is the runtime component responsible for generating and validating short-lived tokens and certificates that services use to authenticate with one another.

Key Features:
Token Issuance:
Issues Access Tokens (JWTs) and Role Tokens for authorization.
Tokens are short-lived, improving security by reducing exposure to stolen credentials.
Certificate Issuance:
Provides short-lived X.509 certificates for mutual TLS authentication between services.
Decentralized Authorization:
Services can independently validate tokens or certificates using the ZTS public keys, reducing reliance on the ZTS during runtime.
Dynamic Trust:
Works seamlessly in dynamic environments like Kubernetes, issuing tokens based on pod identities.
Integration:
Compatible with OAuth 2.0 and OIDC for standardized authentication.


3. User Interface
Athenz includes a user-friendly web-based UI that enables administrators and users to interact with the system without directly accessing APIs or configuration files.

Key Features:
Role and Policy Management:
Intuitive interfaces for creating and managing roles, policies, and resource permissions.
Domain Browsing:
Easily navigate through domains and view their configurations.
Audit and Reporting:
Visualize audit logs and track changes to roles, policies, and resource access.
Ease of Use:
Simplifies complex RBAC configurations into a graphical and interactive platform, making it easier to onboard new administrators.

コンポーネントのまとめ

Summary of Workflow:
Setup Phase:
Use the ZMS or UI to define domains, roles, and policies.
Runtime Phase:
Services request tokens or certificates from ZTS to authenticate with other services.
Decentralized Validation:
Tokens are validated locally by consuming services using ZTS-provided public keys.

一旦用語説明

  1. atehnz service ；アクセス元を識別するためのInfo
  2. role : 同じ権限を持つAthenz serviceをグループとしてまとめたもの。Athenz serviceを追加する感じ。
  3. Policy : Roleでどのようなことが行えるのかを記したもの
  4. Domain : Athenz Service, Role, Policyを管理する名前空間
  5. x509証明書：athenz serviceであることを証明するもの。

トークンの種類

設定

テナント側： まず、アクセス元を識別するためのathenz serviceを作成する必要がある。 そして、x509証明書を取得する必要がある。（これは秘密鍵を生成して、どこかにcsrを送って、証明書を配布してもらう、という流れだった気がするのだが） ちな、環境によってはこれらが自動化されていることもある。

プロバイダ側： ドメインを作成。RoleとPolicyをドメインに対して作成。そして、Roleに先ほど作成したテナントのAthenz serviceをメンバーとして追加。

ここまでの疑問に答える

ここで一つ目の疑問。誰がx509証明書を発行してくれるのか？ これはね、ztsです。ztsというのは、athenzのコンポーネントの一つです。 athenzでは3つのコンポーネントがあります（プロバイダとテナントのコンポーネントを除く） zts zms athenz-ui それぞれの役割としては、 zts (AuthZ Token System)で、

ZTS, the authentication token service, is only needed to support decentralized or data plane functionality. In many ways, ZTS is like a local replica of ZMS's data to check a principal's authentication and confirm membership in roles within a domain. The authentication is in the form of a signed Access Token that can be presented to any decentralized service that wants to authorize access efficiently. If needed, multiple ZTS instances will be distributed to different data centers as needed to scale for issuing tokens.

zms (AuthZ Management System)

ZMS is where domains, roles, and policies are defined. This is Athenz's centralized authorization system and is likely part of a larger management system. In addition to allowing CRUD operations on the basic entities, ZMS provides an API to replicate the entities, per domain, to ZTS. It also can directly support the access check, both for internal management system checks, as well as a simple centralized deployment.

んで、uiはそのまんまコンソールだよね。 はい、でね。やり方としては結構簡単なんだわ。まず秘密鍵を生成するやろ。公開鍵も生成されるやろ？ でね、ドメインを作ってからathenz-serviceを作るんや。UIから。その時に公開鍵をはっつけるんや。これはgithubの公開鍵の登録みたいなものや。で、 そのあと、ztsのapiにアクセスするんや。証明書くださいって。zts api その時にドメインと、athenz-serviceの名前と、秘密鍵を指定するんだな。これでathenzはワイが本物だってわかってくれるんだよ。 その証明としてx509証明書をくれるんや。

athenzをインストール

では実際にathenzをインストールしてみようと思う。いつも通り、 deltaに立てるか。gwのね。

デモなど

そのほかの情報

authorization-proxyというものがあります。 これはですね、プロバイダ用のサイドカーです。つまり、provider-sidecarです。プロバイダ側ではこれをインストールしてください。 athenz/authorization-proxy

んで、これが普通にathenzのクライアントサイドカーやった笑（おもろ！！） athenz/client-sidecar