企業にGitHub Appをインストールしても、リポジトリのコードは開放されません
会社の設定を読むスクリプトが、退職した担当者の個人トークンに依存していることがあります。GitHubは10月23日、GitHub Appsの企業インストールの一般提供を発表しました。classic PATから移行できる管理業務が増えますが、企業に入れるだけですべてのコードを読めるわけではありません。
企業向けアプリで管理できること
発表にはリポジトリのポリシーやruleset、バイパス申請の読み取り、IP許可リストなどが含まれます。申請を一覧表示することと、ルールを書き換えることでは必要な権限が異なります。導入時に書き込み権限をすべて有効にする必要はありません。
企業インストールで付与されるのは企業権限だけです。アプリが組織やリポジトリの権限も要求していても、ここでは付与されません。2つの組織のコードを読むには、各組織への別のインストールと適切なリポジトリアクセスが必要です。企業設定を読めてもコード取得が拒否されるのは、想定どおりの動作かもしれません。
同じアプリでもインストールは別です
架空の企業acmeにweb組織とmobile組織があるとします。同じアプリを3つのアカウントに入れると、インストールも3つになります。企業トークンはweb用の代わりにはならず、web用でmobileの境界も越えられません。図はこの例を説明する自作資料で、実際の製品画面ではありません。
トークンキャッシュのキーをアプリ名だけにすると、この違いを見落としがちです。installation IDを含めれば、企業ポリシーの処理と組織内コードの読み取りで誤ったトークンを再利用しにくくなります。これは文書のアカウント境界を実装に反映する例です。
アプリとユーザーの権限が重なる範囲
ユーザーアクセストークンは、アプリとユーザー両方の権限に依存します。アプリに書き込み権限があっても、読み取り専用のユーザーを代理してその範囲を越えることはできません。インストールトークンは、そのインストールに付与されたアプリ権限で動作します。
発行にはアプリのJWTと対象のinstallation IDを使います。文書ではPOST /app/installations/INSTALLATION_ID/access_tokensと1時間の有効期間が説明されています。Octokitで生成と期限後の再生成を任せられますが、秘密鍵の保護とインストール別のキャッシュ管理は必要です。
個人トークンを置き換える前に
企業ポリシーと複数組織のコードを一緒に扱うスクリプトでは、文字列の差し替えだけでは足りないことがあります。処理を分け、各APIのアプリ対応と認証方式を確認します。すべての企業GraphQL操作が対応しているわけではありません。読み取りから移すと結果を比較しやすくなります。
資料の更新には時差もあります。10月23日のchangelogは一般提供としていますが、今日確認したインストール文書にはpublic previewの表記が残っています。本稿では公開段階は日付付き発表、権限範囲は文書を基準にしました。個人の広い権限をコピーする代わりに、どのアカウントで何をする自動化なのかを明確にできる点が大切です。
出典と関連資料
GitHub Docs · Enterprise installation