9.16. アイデンティティーおよびアクセス管理 (IAM) (テクノロジープレビュー)
アイデンティティーおよびアクセス管理 (IAM) 機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、実稼働環境での Red Hat サービスレベルアグリーメント (SLA) ではサポートされておらず、機能的に完全ではない可能性があるため、Red Hat では実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。詳細は、Red Hat テクノロジープレビュー機能のサポート範囲 を参照してください。
この Ceph Object Gateway はオプション機能としてユーザーアカウントをサポートし、AWS Identity and Access Management (IAM) と同様のユーザー、グループ、およびロールのセルフサービス管理を可能にします。
アカウントの root ユーザー
各アカウントはアカウント root ユーザーによって管理されます。通常のユーザーやロールと同様に、アカウントとアカウント root ユーザーは、管理者が radosgw-admin または Admin Ops API を使用して作成する必要があります。アカウントの root ユーザーには、アカウントが所有するすべてのリソースに対するデフォルトのパーミッションがあります。root ユーザーの認証情報 (アクセスキーとシークレットキー) を Ceph Object Gateway IAM API で使用すると、Ceph Object Gateway S3 API で使用する追加の IAM ユーザーとロールを作成したり、関連するアクセスキーとポリシーを管理したりできます。
アカウントの所有者は、このアカウントの root ユーザーを管理目的にのみ使用し、特定のアプリケーションに対して権限を詳細に指定したユーザーとロールを作成することを推奨します。
アカウントの root ユーザーはアカウント内のリソースにアクセスするために IAM ポリシーを必要としませんが、明示的にアクセスを拒否するポリシーを追加できます。Deny ステートメントは慎重に使用してください。
リソース所有者
通常の (アカウントを持たない) ユーザーがバケットを作成し、オブジェクトをアップロードした場合に、そのようなリソースはこのユーザーが所有することになります。関連付けられている S3 ACL では、そのユーザーが所有者と権限付与者の両方として指定され、それらのバケットは s3:ListBuckets リクエストで所有ユーザーにのみ表示されます。対照的に、ユーザーまたはロールがアカウントに属している場合、ユーザーやコールが作成するリソースはアカウントにより所有されます。関連付けられている S3 ACL では、アカウント ID が所有者および権限受領者として指定され、それらのバケットは、そのアカウント内の任意のユーザーまたはロールによって送信された s3:ListBuckets リクエストに表示されます。
リソースはユーザーではなくアカウントが所有するため、すべての使用統計とクォータの適用は、個々のユーザーではなくアカウント全体に適用されます。
アカウント IDS
アカウント識別子は、ユーザー ID またはテナント名を受け入れるいくつかの場所で使用できます。そのため、アカウント ID では、あいまいさを避けるために特別な形式が使用されます。RGW という文字列の後に 17 桁の数字が続きます (例: RGW33567154695143645)。指定されていない場合は、アカウント作成時にその形式のアカウント ID が無作為に生成されます。
アカウント ID は通常、IAM ポリシードキュメントの Amazon リソース名 (ARN) に記載されています。たとえば、arn:aws:iam::RGW33567154695143645:user/A は、そのアカウント内の A という名前の IAM ユーザーを指します。Ceph Object Gateway は、その位置でのテナント名もサポートします。アカウント ID は、CanonicalUser タイプの Grantee の ACL でも使用できます。ここではユーザー ID もサポートされています。
IAM ポリシー
アカウントのないユーザーはデフォルトでバケットの作成とオブジェクトのアップロードが許可されますが、アカウントユーザーの場合は最初は権限が割り当てられていません。IAM ユーザーが API 操作を実行する前に、操作を許可するためのポリシーを追加する必要があります。アカウントの root ユーザーは、いくつかの方法でユーザーに ID ポリシーを追加できます。iam:PutUserPolicy および iam:AttachUserPoliicy アクションを使用して、ユーザーにポリシーを直接追加します。IAM グループを作成し、iam:PutGroupPolicy および iam:AttachGroupPoliicy アクションを使用してグループポリシーを追加します。iam:AddUserToGroup アクションを使用してそのグループに追加されたユーザーは、グループのポリシーをすべて継承します。IAM ロールを作成し、iam:PutRolePolicy および iam:AttachRolePoliicy アクションを使用してロールポリシーを追加します。sts:AssumeRole および sts:AssumeRoleWithWebIdentity アクションを使用してこのロールを一時的に使用するユーザーは、ロールのすべてのポリシーを継承します。これらのアイデンティティーポリシーは、単一アカウント内でのポリシーの評価およびクロスアカウントポリシー評価ロジックのルールに従って評価されます。
プリンシパル
ポリシードキュメント内の “プリンシパル“ ARN は、ユーザーがアカウントに属している場合にユーザーを別の方法で参照します。アカウント外では、ユーザープリンシパルは、arn:aws:iam:::user/uid や arn:aws:iam::tenantname:user/uid などのユーザー ID で名前が付けられます。ここで、uid は radosgw-admin の --uid 引数に対応します。
アカウント内では、ユーザープリンシパルは、arn:aws:iam::RGW33567154695143645:user/name などのユーザー名を使用します。ここで、name は radosgw-admin の --display-name 引数に対応します。アカウントユーザーは引き続きテナントフォームと同じであるため、ユーザーがアカウントに移行されても既存のポリシーは引き続き機能します。
テナントの分離
ユーザーと同様に、アカウントはオプションで、バケットの名前空間の分離のためにテナントに所属できます。たとえば、“acct” という名前のアカウントがテナント “a” の下に存在し、“acct” という名前の別のアカウントをテナント “b” の下に存在させることができます。
テナントアカウントには、同じテナント名を持つユーザーのみを含めることができます。テナントに関係なく、アカウント ID とメールアドレスはグローバルに一意である必要があります。
9.16.1. アカウントの作成
IAM ユーザーを作成するには、radosgw-admin アカウントを使用します。
注記ユーザー ID と表示名を指定する必要があります。メールアドレスを指定することもできます。
構文
radosgw-admin account create [--account-name={name}] [--account-id={id}] [--email={email}]例
radosgw-admin account create --account-name=user1 --account-id=12345 --email=user1@example.com
9.16.2. アカウントの root ユーザーの作成
IAM ユーザーを作成するには、radosgw-admin user create コマンドを使用します。
注記ユーザー ID と表示名を指定する必要があります。メールアドレスを指定することもできます。root ユーザーは、アカウントに完全にアクセスできる特権 IAM ユーザーであり、他のユーザーの管理など、すべての操作を実行できます。
構文
radosgw-admin user create --uid={userid} --display-name={name} --account-id={accountid} --account-root --gen-secret --gen-access-key例
radosgw-admin user create --uid=rootuser1 --display-name="Root User One" --account-id=account123 --account-root --gen-secret --gen-access-key
9.16.3. アカウントの削除
IAM ユーザーを削除するには、radosgw-admin
rmコマンドを使用します。ユーザーを削除すると、そのユーザーはシステムから削除されます。構文
radosgw-admin account rm --account-id={accountid}例
radosgw-admin account rm --account-id=account123
9.16.4. アカウントの統計情報とクォータの有効化および表示
ストレージ使用量やオブジェクト数など、特定のアカウントの詳細な統計情報を取得できます。また、アカウントのストレージクォータを定義して有効にしたり、アカウント内の特定のバケットのクォータを設定して有効にしたりして、そのバケットに保存できるオブジェクトの最大数を制限することもできます。
手順
アカウント統計を表示します。
構文
radosgw-admin account stats --account-id={accountid} --sync-stats例
{ "account": "account123", "data_size": 3145728000, # Total size in bytes (3 GB) "num_objects": 12000, # Total number of objects "num_buckets": 5, # Total number of buckets "usage": { "total_size": 3145728000, # Total size in bytes (3 GB) "num_objects": 12000 } }アカウントクォータを有効にします。
構文
radosgw-admin quota set --quota-scope=account --account-id={accountid} --max-size=10G radosgw-admin quota enable --quota-scope=account --account-id={accountid}例
{ "status": "OK", "message": "Quota enabled for account account123" }アカウントのバケットクォータを有効にします。
構文
radosgw-admin quota set --quota-scope=bucket --account-id={accountid} --max-objects=1000000 radosgw-admin quota enable --quota-scope=bucket --account-id={accountid}例
{ "status": "OK", "message": "Quota enabled for bucket in account account123" }バケット、ロール、ユーザー、またはシークレットのクォータを変更するには、
account modifyコマンドを使用します。例
[root@magna045 ~]# radosgw-admin quota set --quota-scope=account --account-id RGW12345678901234568 --max-buckets 10000 { "id": "RGW12345678901234568", "tenant": "tenant1", "name": "account1", "email": "tenataccount1", "quota": { "enabled": true, "check_on_raw": false, "max_size": 10737418240, "max_size_kb": 10485760, "max_objects": 100 }, "bucket_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, "max_users": 1000, "max_roles": 1000, "max_groups": 1000, "max_buckets": 1000, "max_access_keys": 4 } [root@magna045 ~]# radosgw-admin quota enable --quota-scope=account --account-id RGW12345678901234568 { "id": "RGW12345678901234568", "tenant": "tenant1", "name": "account1", "email": "tenataccount1", "quota": { "enabled": true, "check_on_raw": false, "max_size": 10737418240, "max_size_kb": 10485760, "max_objects": 100 }, "bucket_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, "max_users": 1000, "max_roles": 1000, "max_groups": 1000, "max_buckets": 1000, "max_access_keys": 4 } [root@magna045 ~]# radosgw-admin account get --account-id RGW12345678901234568 { "id": "RGW12345678901234568", "tenant": "tenant1", "name": "account1", "email": "tenataccount1", "quota": { "enabled": true, "check_on_raw": false, "max_size": 10737418240, "max_size_kb": 10485760, "max_objects": 100 }, "bucket_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, "max_users": 1000, "max_roles": 1000, "max_groups": 1000, "max_buckets": 1000, "max_access_keys": 4 } [root@magna045 ~]# [root@magna045 ~]# ceph versions { "mon": { "ceph version 19.1.1-63.el9cp (8fa7b56d5e9f208c4233b0a8273665087bded8ae) squid (rc)": 3 }, "mgr": { "ceph version 19.1.1-63.el9cp (8fa7b56d5e9f208c4233b0a8273665087bded8ae) squid (rc)": 3 }, "osd": { "ceph version 19.1.1-63.el9cp (8fa7b56d5e9f208c4233b0a8273665087bded8ae) squid (rc)": 9 }, "rgw": { "ceph version 19.1.1-63.el9cp (8fa7b56d5e9f208c4233b0a8273665087bded8ae) squid (rc)": 3 }, "overall": { "ceph version 19.1.1-63.el9cp (8fa7b56d5e9f208c4233b0a8273665087bded8ae) squid (rc)": 18 } }
9.16.5. 既存のユーザーのアカウントへの移行
radosgw-admin user modify コマンドを使用して、既存の IAM ユーザーアカウントを変更できます。Ceph Object Gateway アカウントに関連付けられたロールを作成すると、radosgw-admin role list --account-id <RGWaccountID> コマンドを使用してリスト表示できます。
手順
既存のユーザー IAM アカウントを変更します。
構文
radosgw-admin user modify --uid={userid} --account-id={accountid}
アカウントユーザーにはデフォルトでは権限がないため、ユーザーの元の権限を復元するにはアイデンティティーポリシーを追加する必要があります。または、既存のユーザーごとに新しいアカウントを作成することもできます。その際、--account-root オプションを追加して、各ユーザーを対象のアカウントの root ユーザーにします。
ユーザーのすべてのバケットの所有権がアカウントに譲渡されます。
アカウントのメンバーシップは永続的です。一度追加されたユーザーはアカウントから削除できません。
ユーザーの通知トピックの所有権はアカウントに譲渡されません。通知は引き続き機能しますが、トピックは SNS トピック API に表示されなくなります。
通知トピックの移行
アカウントトピックは、notification_v2 機能が有効になっている場合にのみサポートされます。
移行の影響 アカウントのないユーザーがアカウントに移行されると、既存の通知トピックは RadosGW 管理 API 経由で引き続きアクセスできますが、ユーザーは SNS トピック API 経由ではアクセスできなくなります。にもかかわらず、トピックは引き続き機能し、バケット通知は期待どおりに配信され続けます。
トピックの再作成 アカウントユーザーは、同じ名前を使用してトピックを再作成する必要があります。古いトピック (現在はアクセスできません) と新しいアカウント所有のトピックは干渉することなく共存します。
バケット通知設定の更新 古いユーザー所有のトピックにサブスクライブされているバケットは、新しいアカウント所有のトピックを使用するように更新する必要があります。通知の重複を防ぐには、同じ通知 ID を維持します。
たとえば、バケットの既存の通知設定は以下のようになります。
{"TopicConfigurations": [{ "Id": "ID1", "TopicArn": "arn:aws:sns:default::topic1", "Events": ["s3:ObjectCreated:*"]}]}更新された設定は次のようになります。
{"TopicConfigurations": [{ "Id": "ID1", "TopicArn": "arn:aws:sns:default:RGW00000000000000001:topic1", "Events": ["s3:ObjectCreated:*"]}]}この例では、RGW00000000000000001 はアカウント ID、topic1 はトピック名、ID1 は通知 ID です。
古いトピックの削除 バケットから、古いユーザー所有のトピックへのサブスクライブが解除された場合、管理者は削除できます。
$ radosgw-admin topic rm --topic topic1
アカウントなしのユーザーから RGW アカウントへのユーザーの移行
アカウントなしから RGW アカウントにユーザーを移行する場合は、シームレスな IO 移行と適切な IAM 設定を確保するために、以下の手順に従ってください。
ユーザーの移行中にアカウントルートフラグを割り当てます。ユーザーをアカウントに移行するときに、アカウントルートフラグが追加されていることを確認します。これにより、移行に必要な権限がユーザーに付与されます。
radosgw-admin user modify --uid <user_ID> --account-id <Account_ID> --account-root
S3 アクセスポリシーを割り当てます。ユーザーを移行した後に、適切な IAM ポリシーを割り当て、ユーザーに S3 アクセスを許可します。この場合、AmazonS3FullAccess ポリシーを割り当てます。
radosgw-admin user policy attach --uid <user_ID> --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess
account-root 権限を削除します。移行して必要なアクセス権を付与した後、ユーザーからアカウントのルート権限を削除して、権限の範囲を制限します。
radosgw-admin user modify --uid <user_ID> --account-root=0
