アクセス制御リストとは？リソースごとの権限リスト

アクセス制御リスト (ACL) は、リソースに付与されたリストであり、どのアイデンティティがそのリソースに対してどのアクションを実行できるかを正確に定めます。

アクセス制御リスト、すなわちACLは、認可を表現する最も古く最も直接的な方法の一つです。保護された各リソースはエントリのリストを持ち、各エントリはどのアイデンティティがどのアクションを許可 (または拒否) されるかを示します。ACLはファイル、クラウドストレージのバケット、そしてCI/CDインフラ全体のネットワークリソースで見られます。

ACLの仕組み

各エントリはアイデンティティとリソースに対する権限を対応付けます。このユーザーは読み取り可能、あのグループは書き込み可能、このサービスは拒否、といった具合です。要求が到着すると、システムはリストをたどって判断します。権限は中央のロールカタログではなく、リソースとともに存在します。

ACLに遭遇する場所

buildエージェント上のファイルシステム権限。
artifact向けのクラウドストレージのバケットおよびオブジェクトのACL。
サブネット間のトラフィックを制御するネットワークACL。

ACL対RBAC

ACLはリソース中心です。「誰がこのものに触れられるか？」と問います。RBACはアイデンティティ中心です。「このロールは何ができるか？」と問います。ACLは正確ですが、各リソースが独自のリストを保持するため、大規模では管理が難しくなることがあります。

CI/CDにおけるACL

パイプラインはartifact、cache、ストレージバケットを読み書きし、これらはすべてACLで管理される可能性があります。パブリック読み取りを許可する設定ミスのバケットACLは漏洩の再発源であるため、artifactストレージのACLは慎重なレビューに値します。

よくある落とし穴

ACLの氾濫が主なリスクです。何千ものリソースがそれぞれ独自のエントリを持つと、監査が不可能になります。過度に寛容なエントリ (パブリックアクセス、広範な許可ルール) が、データが露出する原因です。多くのプラットフォームは今や、オブジェクトごとのACLよりもポリシーベースのアクセスを好みます。

ACLとbuild環境

runner上では、ファイルシステムのACLがjobの読み書きできるものを決定します。エフェメラルで隔離されたrunner (Latchkeyのマネージドrunnerなど) は毎回クリーンな状態で開始するため、jobは以前のjobが残したACL保護されたファイルを継承できません。

重要なポイント

ACLは、誰がどのアクションを実行できるかを示すリソースごとのリストです。
RBACのようなアイデンティティ中心のモデルとは異なり、リソース中心です。
設定を誤ったストレージACLは、CIにおけるartifact漏洩の頻繁な原因です。