MinIO STSのモデル

MinIO の認証に STS 対応というものがある。AWS STS 相当で実装されていて、Action は AssumeRole, AssumeRoleWithWebIdentity のみが共通になっている。

STS は任意の認可に対して Policy を bind する機能になっている。bind の状態管理は使い捨ての token を使う。AssumeRoleWithWebIdentity では WebIdentity と呼ばれるところの OIDC での JWT を対象にしている。MinIO では OIDC の access_token JWT か id_token JWT を受け入れる。JWT は MinIO が外部認証サーバとして指定した鍵で署名されているので、署名検証するだけで短命な認証として使える。この認証に対して認可の Policy を bind することになるが、これに Role を使っていて、RolePolicy を bind する仕組みにしている。

minio の RolePolicy は RoleARN と identity provider client をセットにして管理している。
まず RoleARN は RolePolicy に読み替えられて、どの IdP を使っているかがわかる。
STS endpoint の AssumeRoleWithWebIdentity で JWT token (access_tokenまたはid_token)を渡すと、RoleARN から解決した IdP の鍵で JWT token が検証されて、検証が通れば RolePolicy の policy を受け取ることができる。
もちろん JWT で検証が通ればどの鍵が正しかったかはわかる。ただし、例えば同じ realm で異なる client で接続しているする場合を考えるとわかるのだけれど、どの client であったと読み解くかは RoleARN が無いと区別できない。ということで、JWT と RoleARN の両方がリクエストに含まれることになる。

AssumeRole

MinioはただのAssumeRoleもサポートしている。別のドキュメントには記載がある。

AssumeRole では Minio は RoleARN を無視 しており、単に認証で割り当たるポリシーが利用可能になる。