Cloud Source Repositories

解決する課題

ソースコードを保管する Git リポジトリを自前で立てると、サーバーの構築・バックアップ・アクセス管理を継続して面倒みる必要があります。Cloud Source Repositories は、この「プライベート Git ホスティング」を GCP 上でマネージドに引き受け、既存の GCP の権限やビルド・ログ基盤とそのまま統合します。

• Git リポジトリを自前サーバーなしでプライベートにホストしたい
• リポジトリへのアクセス権を、別の認証基盤ではなく既存の GCP の IAM で一元管理したい
• コードの push を起点に Cloud Build で CI/CD を自動起動したい
• GitHub や Bitbucket のリポジトリを GCP 内にミラーリングして取り込みたい
• 誰がいつリポジトリを操作したかを GCP の監査ログとして残したい

主要概念と用語

• リポジトリ（repository）: Git のコード履歴を保管する単位。プロジェクトに紐づくプライベートな Git リポジトリとして作成する
• クローン（clone）: 標準の git クライアントでリポジトリを取得する操作。認証は gcloud 連携のヘルパーや SSH 鍵で行う
• ミラーリング（mirroring）: GitHub・Bitbucket・GitLab などの外部リポジトリの内容を、Cloud Source Repositories 側へ自動的に複製して同期する仕組み
• IAM ロール: リポジトリの閲覧・書き込み・管理などの権限を表すロール。ユーザーやサービスアカウントに付与してアクセスを制御する
• 認証ヘルパー（credential helper）: gcloud の資格情報を使って HTTPS で Git 認証を通す仕組み。GCP のログイン状態を Git の認証に流用できる
• ビルドトリガー連携: リポジトリへの push やタグ作成を起点に Cloud Build を起動する連携。CI/CD の入り口になる

仕様・制限・クォータ

• 標準の Git プロトコルに対応し、一般的な git クライアントからクローン・push・pull できる。HTTPS と SSH の両方の経路を利用できる
• 認証は GCP の IAM に統合され、リポジトリ単位・プロジェクト単位で権限を割り当てる
• 外部リポジトリのミラーリングに対応し、GitHub・Bitbucket・GitLab などを同期元にできる
• リポジトリ数・サイズ・転送量などに上限やクォータがあり、具体値は変動し得るため公式ドキュメントで確認する
• リポジトリ内のコード検索やコミット履歴の閲覧をコンソールから行える
• 新規顧客向けの提供は終了しているため、新規プロジェクトでの作成可否は制限される。既存環境での挙動を前提に設計する

内部の仕組み

Cloud Source Repositories は、プロジェクトに紐づくプライベートな Git リポジトリをマネージドに保持し、標準の Git 操作をそのまま受け付けます。リポジトリへのアクセスは独自のアカウント体系ではなく GCP の IAM を通して認可されるため、ほかの GCP リソースと同じ権限モデルでコードを守れます。

• クローンや push といった Git 操作は、gcloud の認証ヘルパーまたは SSH 鍵を介して認証され、その先で IAM ロールがアクセス可否を判定する
• 外部リポジトリをミラーリングすると、同期元の更新が Cloud Source Repositories 側へ反映され、GCP 内のリポジトリとして扱える
• リポジトリへの push などのイベントは Cloud Build のトリガーと連携でき、CI/CD パイプラインの起点になる
• リポジトリへの操作は Cloud Audit Logs に記録され、誰がいつアクセスしたかを追跡できる

AWS でいえば、マネージドなプライベート Git ホスティングを担う AWS CodeCommit が近い位置づけです。どちらもクラウドの IAM でアクセスを制御し、同じクラウド内の CI/CD サービス（Cloud Build／CodeBuild）と連携してパイプラインの入り口になります。

設計パターン / ベストプラクティス

• リポジトリへのアクセスは最小権限の IAM ロールで割り当て、閲覧だけでよい利用者に書き込み権限を与えない
• CI/CD で利用する場合は、サービスアカウントに必要最小限の読み取り権限だけを付与する
• 外部の GitHub などを正とする運用では、ミラーリングで取り込む構成にして同期元と取り込み先の役割を明確にする
• push を起点に Cloud Build トリガーを組み、ビルド・テスト・デプロイを自動化する
• 機密値や鍵はリポジトリにコミットしない。シークレットは Secret Manager で管理し、コードから分離する
• 新規構築では後継サービス（Secure Source Manager）や外部リポジトリ連携を含めて選定し、提供状況を踏まえた設計にする

運用・監視

• リポジトリへのアクセスや設定変更は Cloud Audit Logs に記録され、誰がいつ操作したかを監査できる
• push を契機にした Cloud Build の実行履歴を追うことで、コード変更から後続処理までの流れを可観測にする
• ミラーリング利用時は同期の成否を確認し、同期元と取り込み先の差分が放置されないようにする
• アクセスできない・push が拒否されるといった事象の典型原因は IAM ロールの不足で、付与ロールを見直して切り分ける
• コミット履歴やコード検索をコンソールから使い、変更の追跡や調査に役立てる

コスト

Cloud Source Repositories は、一定範囲までの利用者数やストレージ・データ転送に対する無料の枠があり、それを超えた利用に応じて課金される、という考え方が基本です。あわせて、連携する Cloud Build の実行や Cloud Logging の保管など周辺サービスの費用も別途発生し得ます。具体的な料金体系は変動し得るため、断定的な金額ではなく構造で捉え、最新は公式の料金ページで確認してください。

セキュリティ

• アクセス制御は GCP の IAM に統合される。リポジトリ単位・プロジェクト単位で最小権限のロールを割り当てる
• CI/CD から参照するサービスアカウントの権限を絞り、不要な書き込み権限を与えない
• 認証は gcloud の認証ヘルパーまたは SSH 鍵で行い、資格情報の管理を徹底する
• シークレットや鍵をリポジトリにコミットしない。機密値は Secret Manager から実行時に読み込む
• リポジトリへの操作を Cloud Audit Logs で監査し、不審なアクセスや権限変更を追跡できるようにする

関連サービス・比較

Cloud Source Repositories は単体で完結するというより、Cloud Build（CI/CD） や IAM（アクセス制御）、Cloud Logging（監査） と連携して開発フローの入り口を担います。AWS では、マネージドなプライベート Git ホスティングを担う AWS CodeCommit が最も近い位置づけです。

ハンズオン / CLI例

# 必要な API を有効化
gcloud services enable sourcerepo.googleapis.com

# プライベートな Git リポジトリを作成する
gcloud source repos create my-app

# 作成したリポジトリの一覧を確認する
gcloud source repos list

# gcloud の認証情報を Git のクレデンシャルヘルパーとして設定し、HTTPS でクローンする
gcloud source repos clone my-app --project=PROJECT_ID

# リポジトリへの閲覧（読み取り）権限をユーザーに付与する
gcloud source repos set-iam-policy my-app policy.json
# もしくは IAM ロールを直接バインドする例
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:dev@example.com" \
  --role="roles/source.reader"