GitHub リポジトリのアクセス権について整理

Git
この記事は約5分で読めます。
記事内に広告が含まれています。

本記事ではGitHubにおけるリポジトリのアクセス権(アクセス可)に関して書いていきます。せっかくなので、EnterpriseやOrganizationも含めて書きます。

Enterprise, Organization, Repository

自分のリポジトリに外部コラボレータ招待であれば、単純だけど、EnterpriseやOrganizationでは一体・・・?

というのがあるので書くよ!以下、目次です。

リポジトリのアクセス権

アクセス権の種類を再確認

通常は以下の5種類の権限が準備されています(強い順に並べています)。

  • Admin
  • Maintainer
  • Write
  • Triage
  • Read

権限毎に何が出来るかについては、GitHub公式サイトを見たほうが確実です。

Organizationのリポジトリロール - GitHub Docs
細かなロールを割り当て、ユーザーに必要な機能やタスクへのアクセスを付与することによって、Organization内の各リポジトリへのアクセスをカスタマイズできます。

○カスタムロール

EnterpriseプランであればOrganization単位で上記5種類以外のカスタムロールを定義することも可能です。AdminとMaintainerの間ぐらいの権限を定義したい、といったことも可能です。

リポジトリ単体の場合

Admin=リポジトリ管理者であって、メンバの招待&権限設定等も出来ます。

リポジトリ単体であれば、Adminの人に招待してもらって「Read以上」の権限を振ってもらえれば「アクセス可能」ということになります。

権限概要
Adminリポジトリの管理者(全設定及び招待が可能)
Maintainerリポジトリのサブ管理者(一部設定が可能)
Writeリポジトリの読み書きが出来る。
Triageリポジトリの参照が出来る。
Readリポジトリの参照が出来る。
※Readだけどコメントは可能です。

「Public」なリポジトリの場合、何もせずともデフォルトで「Read」です。
※ただし、ログインしていないとコメントは書けません。

ここまでがリポジトリ単体の場合です。

Enterprise/Organization

EnterpriseやOrganizationを利用すると、リポジトリに対するポリシー(アクセス権含む)を設定出来ます。

例えば

  • Organization所属者のリポジトリに対するデフォルトアクセス権
    → 該当Organizationに所属していれば、配下の全リポジトリにはRead権を与える…等。後からリポジトリ側のアクセス権設定でオーバーライド可能です。
  • 外部共同者の招待許容
    → Organization未所属の第3者をリポジトリに招待しない。これによってPrivateリポジトリへのアクセス権はOrganization Ownerのみが判断できるようになります。

です。

Organizationポリシで設定可能な「リポジトリのデフォルトアクセス権」は

  • No permission(未定義)
  • Read
  • Write
  • Admin

が可能です。

デフォルトアクセス権(Base Permissions)の設定。

続いて、Enterprise/Organization/Repositoryという階層を意識して、以下の表で整理してみます。

対象EnterpriseOrganizationRepository (Private)
デフォルトアクセス権定義可定義可
外部共同者の招待制限可制限可上位の制限がなければ勝手に招待可
重要なPrivateリポジトリなのに、リポジトリAdminが勝手に招待とかは絶対にやめたいところ・・・。

ポリシーの強さはEnterprise > Organization > Repositoryです。

Enterpriseで定義されていた場合、Organizationでは定義出来ません。
→ Enterpriseという上位設定をOrganizationはオーバーライドすることは出来ない。

※ただし、Enterpriseで未定義(No permissions)であればOrganizationに設定を委ねることが出来ます。柔軟ですね。

Organization所属後、明示的にリポジトリ招待しなくてもデフォルト(ベースロール)が既にある。
OrganizationとRepository権限例

以下を想定します。

  • Organizationのリポジトリ権限ポリシは「Write」とする。
  • Organization内の複数のリポジトリがあるとする。

→ Organizationの所属メンバは明示的に設定せずに複数リポジトリをWrite権限で扱えます。Admin等の上位権限が必要な場合のみ明示的にリポジトリ権限を設定すればOK。


ところで、リポジトリのアクセス権という観点から派生しますが、次のような内容もEnterpriseやOrganizationレベルでポリシーとして設定可能です。

  • リポジトリ可視性(Public/Internal/Private)の変更
  • Fork許可
  • リポジトリやIssue削除
  • ブランチのルールセット
  • ・・・

こりゃ、全体のポリシーを俯瞰するのは大変だわ。

けど、上位層でのポリシー管理は重要だからね。

まとめ

リポジトリのアクセス権についてご紹介しました。

リポジトリ単体であればリポジトリ管理者(Admin権限保有者)が任意ユーザやTeamを追加します。追加の際は、WriteやReadといった権限を設定します。

※Publicリポジトリの場合は明示的な付与がなくてもRead権限があります。

EnterpriseやOrganizationを利用する場合は、上位でポリシーを設定出来ます。これによって、Organizationに所属した段階で関連リポジトリにRead権を与えたり、Organization非所属の第3者の招待を不可能とするようなことが出来ます。

最後までご覧いただき、ありがとうございました!

コメント

Top
タイトルとURLをコピーしました