ghtknを開発フローに組み込んでみて
はじめに
ghtknという素晴らしいツールがある。 これは、GitHub Appにより発行できるUser Access TokenをCLIで取得できるようにしてくれるツールだ。何がうれしいかというと、特定のGitHub Orgやリポジトリのみにアクセスを絞れて、必要な権限のみに限定して、有効期限が8時間以内のアクセストークンを払い出せることだ。
昨年、作者のsuzuki-shunsukeさんの記事を見て存在は認識していたのだが、当時はそのメリットにあまりピンときていなかった。 昨今世間を騒がせているセキュリティインシデント事例の中には侵害された端末上のGitHubアクセストークンを窃取する例もあることを知ってはじめて、ghtknの有用性に気がついた。
それ以来、ここ3ヶ月ほど開発フローにghtknを取り入れて利用してきた。これに関していろいろと思うことがあるので、それを書き留めておきたい。
ghtknの活用シーン
前おきとして、筆者がghtknをどのように利用しているかも紹介しておく。
ghtknを利用しはじめて以来、GitHubに対するCLI上のアクセス(gh cliや git コマンドによるリポジトリへのアクセス)全てにghtknを利用している。
ghtknで払い出したトークンを環境変数 GH_TOKEN に指定して gh を利用し、ghtknをGit credential helperに設定して git を利用している。
私用・社用トークンの使い分け
筆者が最も効果を感じているのが、私用・社用トークンの使い分けだ。 筆者の所属する組織では、GitHub Enterprise Cloudを利用しており、GitHubアカウントは私用・社用で同じものを使用している。(GitHubの規約では1人1アカウントが原則だったと思うので、当然そうなるが)
よって、私用端末から組織のリポジトリにアクセスできてしまうし、会社の貸与端末からも私用のリポジトリにアクセスできてしまう。 私用端末からの情報漏洩が怖いのもともかく、社用端末からトークンが漏洩し、私用のリポジトリやOSSリポジトリが侵害されるのも避けたい。なんならこちらのほうが個人としての信用に直接関わってくるまである。
ghtknを使えば、組織のOrgにアクセスを限定したトークンや、個人リポジトリにアクセスを限定したトークンを発行することができる。これにより、少なくともターミナル上の作業では私用と社用の完全な分離が実現できる。
読み取り専用トークン
ghtknでは、トークン発行に利用するGitHub Appの持つ権限範囲により、発行される権限スコープが絞られる。 つまり、読み取り権限しか持たないAppを利用すれば、発行されるトークンもまた読み取り権限しか持たない。
これが何の役に立つかというと、Claude CodeなどのAIエージェントに調査タスクなどをやらせるときに、リポジトリに対する意図しない変更を防ぐために役立つ。
--permission-mode auto を指定してClaudeに調査タスクやらせると、気をきかせて調査結果をIssueのコメントに書き込んだり、修正のためのPull Requestを作ったりすることがある。正直これらはありがた迷惑なので、そもそも書き込み権限なしの権限だけ渡しておけばよいだろうという考えだ。
AIに対して適切な指示を与えれば防げることだろうという指摘もあるかもしれないが、個人的には権限範囲を絞るというのが、この問題への対策として最もしっくりくる。
組織への導入と課題
組織への導入
さて、前述のように利用するため、組織のOrgにGitHub Appを導入する必要があった。筆者は組織内ではOrgを管理する立場ではなかったため、関係部署への提案や説得を行った。その際に意識したのは次のようなポイントだった。
- セキュリティ的懸念の少ない権限設計
- 具体的ユースケースを交えた説明
- 利用者向けドキュメントの整備
セキュリティ的懸念の少ない権限設計
組織への導入という意味では、個別のリポジトリではなく、Org全体に対するアクセス権を持つGitHub Appを作成できると話が早い。
そのような広いアクセス権を持つAppを用意するとなると、当然だが必要最小限の権限のみをつけるようにしたい。
そのため、提案の際には、 gh や git から具体的に利用が想定される権限の一覧を用意した。
具体的には次のようにした。
- リポジトリに関する権限は、一般的な
gh,git利用に関連するもの のみ付与する。セキュリティ的懸念が考えられるものは付与しない- Administration, Secrets, Variablesなどの権限は与えない
- Secret scanning alert, Dependabot alertなども、AIが誤ってアラートを閉じることがないように権限を与えない
- Organizationに関する権限は、よく利用されるMembers, Projectsのみ付与する
特にクリティカルになりそうな権限をそもそも付与しないことで、万が一アクセストークンが漏れた際にも被害範囲を小さくとどめられるようにした。
具体的ユースケースを交えた説明
この仕組みを導入することで何がうれしいのか、どのようなメリットが得られるのかを、組織視点と利用者視点から説明した。 私の所属する組織では、過去にOrg外のリポジトリに業務コードを誤ってプッシュしてしまうインシデントがあったようなので、そのようなインシデントも防げることを訴えた。
利用者向けドキュメントの整備
組織として誤プッシュを防ぐという目的のためには、誤プッシュをしてしまいかねない人たちにもこの仕組みを利用してもらう必要がある。 ghtkn公式のドキュメントも決してわかりづらいことはないのだが、この層の人たちでもハードルを感じずに利用できるよう、さらに噛み砕いた内容の利用ドキュメントを用意した。
利用は個人の裁量に任されてしまう
以上のように、組織に導入するにあたっては広くいろいろな人に使ってもらえるように足回りを固めたのだが、実際に利用されるかどうかは別問題だ。 ghtknはGitHubの公式のツールではないため、Orgのポリシーなどで利用を強制することはできない。 一部のセキュリティ意識の高い人たちにはすぐに利用が広まったのだが、本当に利用してもらいたい層に働きかけていくのはこれからだ。 結局このあたりは地道な草の根活動をしていくしかないとは思うが、こういうところこそうまくAIなんかを活用して効率的に広められたら良いなと思う。
また、私の所属する組織には業務委託などで参画してくれている人も多く、トークン管理をghtknに統一することが難しい場合があるのも課題だ。その人がGitHub上で関わる全てのOrgでghtkn利用への対応が行われないと導入の意味は薄く、利用者の負担も大きくなってしまう。
結局のところは、サードパーティツールではなくGitHub公式からこのあたりの問題を解決する術が提供されるのが最善だと思う。関連Issueなどを見る限りはGitHub側はやる気はなさそうだが。
GitHubのプライベート利用をやめるという選択
極端な話、筆者個人の事情に限って言えば、GitHubは仕事専用に割り切って利用すれば全ての問題は解決する。 最近では度々著名なOSSがGitHub以外のGitホスティングサービスに引っ越す例もあるわけだし、わざわざGitHubを利用し続ける理由もそこまではない。 dotfilesなんかはGitHub Actionsにがっちりロックインされてしまっているが、これから作るリポジトリはtangled.orgかSourceHutに籍を置くのがよさそうだと思っている。
おわりに
ここまで書いたように、ghtknは既に私の日々の開発フローの中では、なくてはならないツールの1つとなっている。 もしここに書いたような課題を感じている方は、ぜひghtknを試してみてほしい。このツールを活用してセキュリティ的な懸念を1つなくすことで、これまでよりも開発に集中できる環境を得ることができると思う。