アイデンティティとアクセス管理（IAM）
RustFS のアイデンティティとアクセス管理（IAM）について、アイデンティティの種類、ポリシーの割り当て、ポリシー評価の意味を説明します。
RustFS には、AWS IAM のポリシー言語をモデルにした、組み込みのアイデンティティとアクセス管理（IAM）があります。S3 のデータアクセス、Console の操作、管理 API の呼び出しを問わず、すべてのリクエストは認証情報で認証されたあと、そのアイデンティティに割り当てられたポリシーで認可されます。
アイデンティティの種類
RustFS では、次のアイデンティティの種類を区別します。
| アイデンティティ | 作成方法 | 主な用途 |
|---|---|---|
| ルート認証情報 | サーバー起動時の環境変数 RUSTFS_ACCESS_KEY / RUSTFS_SECRET_KEY | 初期設定と緊急時の管理。ルートアカウントは IAM のアイデンティティポリシー評価を迂回します（所有者としての扱い）。 |
| IAM ユーザー | Console または管理 API（add-user） | 人またはアプリケーション向けの、長期の名前付きアカウント。 |
| グループ | Console または管理 API（update-group-members） | 1 組のポリシーを多数のユーザーに一度に割り当てます。ユーザーは、所属するすべてのグループのポリシーを継承します。 |
| サービスアカウント（アクセスキー） | Console または管理 API（add-service-account） | 親ユーザーに属する派生認証情報です。親の権限を継承し、任意で埋め込まれたセッションポリシーによってさらに制限でき、有効期限を持てます。 |
| STS の一時認証情報 | AssumeRole / AssumeRoleWithWebIdentity の STS 呼び出し | アクセスキー、シークレットキー、セッショントークンを持つ短期間の認証情報（15 分から 12 時間）。 |
| 外部 OIDC アイデンティティ | OpenID Connect プロバイダー（Keycloak、Authing、その他の標準 OIDC IdP） | Console のシングルサインオン。ID トークンのクレームは RustFS のポリシー名に対応付けられ、RustFS は STS の一時認証情報を発行します。 |
ルート認証情報は IAM のアイデンティティポリシーを迂回しますが、バケットポリシーはルートの S3 リクエストを拒否できます。バケットポリシーの拒否を迂回するのは GetBucketPolicy、PutBucketPolicy、DeleteBucketPolicy だけであり、これは所有者がアクセスを回復できるようにするためです。ルート認証情報はデプロイの初期設定にだけ使い、日常の作業には IAM ユーザーとサービスアカウントを作成します。
ポリシーとアイデンティティの対応
ポリシーは、RustFS に保存される名前付きの JSON ドキュメントです。割り当ては次のように機能します。
- ユーザーへの割り当て — 1 つ以上のポリシー名を IAM ユーザーに割り当てます（
set-user-or-group-policy、またはポリシーのリストを受け付けるidp/builtin/policy/attachエンドポイント）。 - グループへの割り当て —
isGroup=trueによる同じ仕組みです。グループの各メンバーは、自身のポリシーに加えてグループのポリシーを受け取ります。 - サービスアカウント — 独自のポリシー割り当ては持ちません。親ユーザーのポリシーを組み合わせた結果の下で評価されます。サービスアカウント作成時に明示的なポリシードキュメントを指定した場合、そのセッションポリシーは追加の制限として適用されます（両方で許可される必要があります）。
- STS セッション — 親アイデンティティのポリシーを継承します。
AssumeRoleのリクエストパラメータPolicyで、一時認証情報をさらに制限する追加のセッションポリシーを埋め込めます。 - OIDC アイデンティティ — ID トークンの
groupsとrolesのクレーム値が RustFS のポリシー名と照合されます。一致したポリシーが、発行される STS の一時認証情報を制御します。
RustFS には、次の組み込み（canned）ポリシーがあります。readwrite、readonly、writeonly、diagnostics、consoleAdmin です。内容とカスタムポリシーの書き方は、ユーザー、グループ、ポリシーを参照します。
ポリシー評価の意味
アイデンティティに複数のポリシーが割り当てられている場合、RustFS はステートメントを統合し（重複は除く）、統合したドキュメントを評価します。
- 明示的な拒否が優先されます。 すべての
Denyステートメントを最初に確認します。リクエストに一致するDenyステートメントがあれば、Allowの有無にかかわらずリクエストは拒否されます。 - 所有者の特例。 ルートアカウントは IAM のアイデンティティポリシー評価を迂回します。上記のバケットポリシーの確認と例外は、引き続き適用されます。
- 明示的な許可が必要です。 それ以外の場合、要求されたアクションとリソースに一致する
Allowステートメントが少なくとも 1 つ必要です。 - 既定は拒否です。 一致するステートメントがなければ、リクエストは拒否されます。
セッションポリシーを持つサービスアカウントと STS セッションでは、有効な権限は積集合です。親のポリシーとセッションポリシーの両方が、リクエストを許可する必要があります。
このセクションの内容
- ユーザー、グループ、ポリシー — ユーザーとグループの管理、ポリシードキュメントの形式、組み込みポリシー。
- サービスアカウントと STS —
AssumeRoleによる派生アクセスキーと一時認証情報。 - アクセスキー — Console からのアクセスキーの作成と削除。