本記事ではGitHubにおけるリポジトリのアクセス権(アクセス可)に関して書いていきます。せっかくなので、EnterpriseやOrganizationも含めて書きます。
自分のリポジトリに外部コラボレータ招待であれば、単純だけど、EnterpriseやOrganizationでは一体・・・?
というのがあるので書くよ!以下、目次です。
リポジトリのアクセス権
アクセス権の種類を再確認
通常は以下の5種類の権限が準備されています(強い順に並べています)。
- Admin
- Maintainer
- Write
- Triage
- Read
権限毎に何が出来るかについては、GitHub公式サイトを見たほうが確実です。
○カスタムロール
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
が可能です。
続いて、Enterprise/Organization/Repositoryという階層を意識して、以下の表で整理してみます。
対象 | Enterprise | Organization | Repository (Private) |
---|---|---|---|
デフォルトアクセス権 | 定義可 | 定義可 | ー |
外部共同者の招待 | 制限可 | 制限可 | 上位の制限がなければ勝手に招待可 |
ポリシーの強さはEnterprise > Organization > Repositoryです。
Enterpriseで定義されていた場合、Organizationでは定義出来ません。
→ Enterpriseという上位設定をOrganizationはオーバーライドすることは出来ない。
※ただし、Enterpriseで未定義(No permissions)であればOrganizationに設定を委ねることが出来ます。柔軟ですね。
ところで、リポジトリのアクセス権という観点から派生しますが、次のような内容もEnterpriseやOrganizationレベルでポリシーとして設定可能です。
- リポジトリ可視性(Public/Internal/Private)の変更
- Fork許可
- リポジトリやIssue削除
- ブランチのルールセット
- ・・・
こりゃ、全体のポリシーを俯瞰するのは大変だわ。
けど、上位層でのポリシー管理は重要だからね。
まとめ
リポジトリのアクセス権についてご紹介しました。
リポジトリ単体であればリポジトリ管理者(Admin権限保有者)が任意ユーザやTeamを追加します。追加の際は、WriteやReadといった権限を設定します。
※Publicリポジトリの場合は明示的な付与がなくてもRead権限があります。
EnterpriseやOrganizationを利用する場合は、上位でポリシーを設定出来ます。これによって、Organizationに所属した段階で関連リポジトリにRead権を与えたり、Organization非所属の第3者の招待を不可能とするようなことが出来ます。
最後までご覧いただき、ありがとうございました!
コメント