Athenzを完全理解したい願望 はい、書いてある通りです。athenz、理解したいです。 正直、個人開発レベルでは全然理解しなくていいやつです。しかし、大きな企業で、多くのサービスが動いていてサービス間でAPIを使い合いたいとかってなると必須の技術になると思います。いくら内部ネットワークとはいえね、認証された人だったりサービスのみにサービスの利用を限定しないと、もし仮に内部ネットワークに攻撃者が入ってしまった時に好き放題やられてしまうからね。 ということで、athenz完全理解を目指してやっていきたいと思う。
流れ athenzの各コンポーネントを紹介します。 athenzで使われているRBACについて説明します athenzを自宅のクラスターにインストールします インストールした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. 一旦用語説明 atehnz service ；アクセス元を識別するためのInfo role : 同じ権限を持つAthenz serviceをグループとしてまとめたもの。Athenz serviceを追加する感じ。 Policy : Roleでどのようなことが行えるのかを記したもの Domain : Athenz Service, Role, Policyを管理する名前空間 x509証明書：athenz serviceであることを証明するもの。 トークンの種類 設定 テナント側： まず、アクセス元を識別するためのathenz serviceを作成する必要がある。 そして、x509証明書を取得する必要がある。（これは秘密鍵を生成して、どこかにcsrを送って、証明書を配布してもらう、という流れだった気がするのだが） ちな、環境によってはこれらが自動化されていることもある。
...