Cloud/設定/ロール
ロール
組織の権限モデルです。最初から用意されているシステムロール、権限カタログから組み立てるカスタムロール、そしてシステムロールは削除できないというルールがあります。
Roles は、組織の権限モデルを可視化したものです。説明は "Custom roles and the permissions they grant." 管理には org:manage が必要です。
Roles
Custom roles and the permissions they grant.
Full control over the organization.
Default access for invited people.
Read-only access for reporting.
Data Analyst
Pick the permissions this role grants within its scope.
Members
Teams
Settings
Audit
モックアップが実際のページです。ロールを選択してグループ化された権限を確認し、削除できないものに付いている System バッジに注目してください。
まずはシステムロール
すべての組織は 2 つのロールから始まります。完全な制御権を持つ Owner と、招待されたメンバーの既定値である Member です。どちらにも System バッジが付いており、コンソールは削除を拒否します。この 2 つは、モデルの残りの部分が支えられる土台です。
カスタムロール
Create role を開くとエディターが表示されます。"Data Analyst" のような名前と権限ピッカーがあり、指示は "Pick the permissions this role grants within its scope." です。権限は組織のカタログから、メンバー、チーム、設定、監査といったドメインごとにグループ化されて提供され、各権限は org:members:read や org:manage のような具体的な能力です。カスタムロールは Clone で複製もできます。ロールを複製して調整する方が、ゼロから作るより速いでしょう。カスタムロールの削除は Delete で確認を伴います。Members でそのロールを参照していたメンバーには、新しいロールを割り当てる必要があります。
このページが存在する理由
ここでの権限は飾りではありません。コンソールが至るところで適用している ABAC チェックそのものであり、誰が監査ログを見られるか、誰が SSO を編集できるか、誰がメンバーリストを管理できるかを決めています。ロールはこれらのチェックを再利用可能な言葉に変えます。org:audit:read を個人に付与する代わりに Data Analyst を付与すれば、その意味は名前とともに伝わります。
次に読むべきページ
Service Accounts は、同じ考え方を人ではない ID に適用したものです。