目次
#1.はじめに
#2.GitLab単体構成では満たしにくいAWS統制要件
#3.なぜ「完全移行」ではなく「ミラーリング」なのか
#4.なぜ一方向ミラーなのか
#5.実際にやってみる
#6.まとめ
1.はじめに
※本記事は個人の見解であり、所属組織とは関係ありません
※本記事の執筆にあたり調査や検証をしていますが、技術的な誤りがありましたら申し訳ありません
※本記事の作成にあたり生成AIを活用しています
CodeCommitは一時期サービス終了予定がアナウンスされ、多くの現場で外部Gitホスティングサービスへの移行が進んでいたかと思います。
先日以下発表され各所で大きな話題となっていましたが、CodeCommitは一般提供が継続される形でサービスが維持され、再び選択肢として検討できる状況になりました。
一方で、私がよく利用するGitLabはDevSecOpsの統合プラットフォームであり、例えば以下の点で非常に優れた開発体験を提供します。
- issueによるチケット管理やMergeRequestを用いたプロジェクト管理
- GitLabから提供されるスキャナーによる脆弱性チェック
- GitLab CIによりセキュリティチェックのシームレスな実施
- GitLabDuoでのAI開発支援
しかし、実行環境がAWSで稼働している場合は、GitリポジトリをCodeCommitで持つことで、IAM認証やログ管理、CI/CDパイプラインの観点でも便利なケースがあるのもまた事実です。
本記事では、
開発はGitLab、
AWSリソースとの連携はCodeCommit
という役割分担を前提に、
GitLab → CodeCommit の一方向ミラーリング設計を整理してみます。
2.GitLab単体構成では満たしにくいAWS統制要件
GitLabは高機能なGit ホスティングサービスですが、AWS統制という観点では以下の制約があります。
- IAMと直接統合できない
- AWS Organizations / SCP による操作制御ができない
- CloudTrailによる操作監査の対象外
「AWSアカウント配下で何が行われたか」を厳密に管理したいケースで重要な要素ですね。
これらの点から、CodeCommitは単なるGitホスティングというより、
「AWSアカウント配下のリソースとして、IAM・CloudTrail・Organizationsによる統制を受けられる」
という位置付けで捉えることができます。
3.なぜ「完全移行」ではなく「ミラーリング」なのか
CodeCommit復活に伴い検討した代替案は以下3点です。
- GitLabのみを利用する案
⇒開発体験は変わりませんが、前述の通りAWS統制要件を満たせません
- CodeCommitに完全回帰する案
⇒AWS統制要件は満たせますが、GitLabに移行して開発機能に旨味を感じているユーザは嬉しくないですし開発標準の再設計が発生します。
- 成果物のみをAWS側で管理する案
⇒リポジトリの二重化、リポジトリを使わないなら履歴なしなど問題があります。
これらを踏まえて、開発体験とAWS統制を分離し、役割分担で両立するという設計判断から、ミラーリング構成がいいと考えました。
Developer
↓
GitLab（主リポジトリ）
↓（一方向ミラー）
CodeCommit（AWS側リポジトリ）
GitLab：開発者向けの正リポジトリ
CodeCommit：AWS統制・監査用途のミラー先リポジトリ
4.なぜ一方向ミラーなのか
以下のGitLabドキュメントにも記載はありますが、双方向ミラーリングの場合、競合する可能性が高いです。
一応ブランチ戦略や運用を工夫すれば対応自体は可能ですが、#3に記載したGitLabとCodeCommitの役割分担だとCodeCommit側では更新は発生しない(させない)ため、一方向がベストと考えています。
なお、本構成ではCodeCommit側での直接編集やPull Request運用は行わず、
あくまでAWS統制・監査用途の参照リポジトリとして利用する前提としています。
5.実際にやってみる
1.AWS上でCodeCommitリポジトリ、認証用IAMユーザを準備する
今回はAWSコンソールで「CodeCommitUser」というユーザを作成しました。
用途はミラーリングのみなのでコンソールアクセスはなしにしています。
ユーザ作成後、CodeCommit認証用の設定が必要になりますが、以下の画像のようにhttpsとsshの選択肢があります。
要件としてはどちらでも構わないのですが、今回はより簡単に検証が行えるhttpsを採用しました。
以下のように認証用のIDとパスワードの生成が可能です。
なお、GitLabのリポジトリミラーリング機能では、
STSによる一時クレデンシャルを用いたIAM Roleの利用ができないため、
本構成ではIAMユーザのGit認証情報を利用しています。
IAMユーザはミラーリング専用とし、
対象リポジトリの最小権限のみを付与することで、
リスクを限定した運用を想定しています。
ユーザ作成後、ミラーリング先となるリポジトリ「mirror_gitlab」を作成しました。
この時点では何もコミットされていない空っぽのリポジトリです。
2.GitLab側のリポジトリでミラーリング設定を行う
設定->リポジトリ->リポジトリのミラーリングから設定追加を行います。
リポジトリの設定ではリポジトリのURLと手順1で取得したIAMユーザの認証情報を入力します。
ミラーリングの設定が追加されました。
更新ボタンを押下するとリポジトリミラーリングが動作したようです。
CodeCommit側にリポジトリがミラーリングされました。
3.ミラーリングの検証とCloudTrailの確認を行う
続いてこの状態でGitLabリポジトリに新たにコミットを行いCodeCommit側に同期されるか確認をします。
GitLab側に2件目のコミットを行いました。
しばらくするとCodeCommit側にも2件目のコミットが取り込まれました。
以下ドキュメントにも記載がありますが、GitLabのpushミラーリングは即時ではなく、5分以内の動作のようです。
CloudTrailを確認してみると「CodeCommitUser」によるログもちゃんと記録されています。
6.まとめ
CodeCommit復活のニュースを受けてGitLabとのリポジトリミラーリングを検討してみました。
現場の要件によって必ずしもミラーリングが最適解となるとは限りませんが、
今後このような要件やケースも出てくるのかなと思います。