ロールベースアクセス制御とは何か？ロールを通じたパーミッション

ロールベースアクセス制御（RBAC）はパーミッションをロールに付与し、そのロールをアイデンティティに割り当てるため、アクセスは個別の例外ではなく職務に従います。

ロールベースアクセス制御、すなわちRBACは、大規模に認可を整理する最も一般的な方法です。各ユーザーに1つずつパーミッションを付与する代わりに、ロール（admin、developer、viewer）を定義し、それらのロールにパーミッションを紐づけ、ロールを人やサービスに割り当てます。これにより、チームやパイプラインが成長してもアクセスを管理しやすく保てます。

RBACの構造

パーミッションはリソースに対する操作を記述します。ロールは関連するパーミッションをまとめます。アイデンティティ（ユーザーやサービス）は1つ以上のロールを受け取ります。誰かができることを変えるには、散在する個別の付与を編集するのではなく、その人のロールを変更します。

チームがそれを使う理由

一貫性: あるロールに属する全員が同じアクセスを持つ。
監査可能性: 誰が何をできるかを容易に把握できる。
オンボーディングとオフボーディング: 数十のパーミッションではなく、ロールを割り当てるか取り消す。

CI/CDにおけるRBAC

ソースホストやCIプラットフォームは、人間のアクセスにRBACを使います。誰がmergeできるか、誰がシークレットを管理できるか、誰がパイプライン設定を変更できるか、といった具合です。クラウドプロバイダーは人とworkloadの両方にロールを使います。パイプラインはしばしばロールを引き受けて、必要なクラウドパーミッションだけを得ます。

RBACと最小権限

RBACはロールが厳しくスコープされているときに最もよく機能します。よくあるミスは、包括的なadminロールを気軽に配りすぎることです。実際のタスクに沿った狭いロールを定義することで、最小権限の原則を保ち、侵害による被害を限定できます。

RBACの限界

アクセスがコンテキスト（時刻、リソースの所有者、リクエストの発生元）に依存する必要がある場合、RBACは苦労することがあります。ルールがそこまで細かくなると、属性ベースアクセス制御のほうが適合するかもしれません。多くのシステムは両者を組み合わせます。

RBACとrunner

パイプラインが引き受けるロールが、そのrunnerが触れられるものを決めます。そのロールを単一の環境にスコープすることで、露出を限定します。エフェメラルなrunner（Latchkeyのマネージドrunnerなど）では、引き受けたロールのコンテキストはjob間で持続しません。

重要なポイント

RBACはパーミッションをロールに、ロールをアイデンティティに割り当て、大規模なアクセスを簡素化します。
一貫性、監査可能性、オンボーディングやオフボーディングを改善します。
狭くタスクに沿ったロールは、パイプラインのアクセスを最小権限に近く保ちます。