GitLab Protected Branchesの深淵：CI/CDの聖域を守る「不可侵」の設計思想
GitLabの`Protected Branches`は、単なる権限設定のスイッチではない。これは「本番環境という名の聖域」と「開発現場という名の混沌」の間に引かれる、絶対的な防波堤だ。
多くのエンジニアがGUIのチェックボックスをポチポチと押すだけで満足しているが、真のDevOpsアーキテクトは、その裏側にあるAPIの挙動、Gitの参照整合性、そして人為的ミスを排除するための「コード化されたガバナンス」を設計する。本稿では、GUIの先にある「真の防御」について解説する。
—
1. GUIは捨てろ：Protected BranchesのIaC化
本番環境の設定をGUIで行うなど論外だ。設定のドリフトを許容することは、セキュリティ上の脆弱性を放置することに等しい。GitLab APIを叩き、Terraformやスクリプトで一元管理せよ。
以下のスクリプトは、特定のブランチ（`production`）に対する保護ルールをAPI経由で強制適用するものだ。これにより、誰かが勝手に設定を変更する余地を排除する。
!/bin/bash
GitLab APIを用いたProtected Branchesの強制適用スクリプト
実行時には適切なProject Access Tokenが必要
PROJECT_ID=”your_project_id”
BRANCH=”production”
GITLAB_URL=”https://gitlab.example.com”
既存の保護設定を一度削除し、クリーンな状態で適用する（冪等性の確保）
curl –request DELETE –header “PRIVATE-TOKEN: $GITLAB_TOKEN” \
“$GITLAB_URL/api/v4/projects/$PROJECT_ID/protected_branches/$BRANCH”
新たな保護ルールを適用
allow_force_push: false (絶対禁止)
code_owner_approval_required: true (CODEOWNERSの承認を必須化)
curl –request POST –header “PRIVATE-TOKEN: $GITLAB_TOKEN” \
–data “name=$BRANCH&push_access_level=0&merge_access_level=40&allow_force_push=false&code_owner_approval_required=true” \
“$GITLAB_URL/api/v4/projects/$PROJECT_ID/protected_branches”
なぜこれが「極限」なのか
- 冪等性: スクリプトを何度叩いても、期待通りの状態に収束する。
- Audit Trail: 設定変更がCIパイプラインのログとして残り、誰が・いつ設定を変えたかが明確になる。
- 権限の最小化: `push_access_level=0`（No one）を設定することで、人間による直接プッシュを物理的に遮断する。
—
2. 権限の重層化：CODEOWNERSと環境スコープの融合
ただ保護するだけでは不十分だ。上級者は`CODEOWNERS`ファイルとGitLabの`Protected Environments`を連携させる。
CODEOWNERSの最適解
`CODEOWNERS`は単なる承認依頼リストではない。CIパイプラインの品質保証ゲートである。
.gitlab/CODEOWNERS
本番環境へのマージには、SREチームの承認を必須とする
[Production]
- @sre-team-lead @architecture-guild
これにより、開発者がどれほど優秀でも、SREの合意なしに本番コードが一行たりとも混入しないアーキテクチャが完成する。
—
3. パイプライン・ハック：Protected BranchesとRunnerの分離
本番環境を守るための極致は、「誰がパイプラインを実行できるか」の制御にある。
Protected Branches上で動くRunnerには、必ず「Protected Runner」タグを付与し、かつそのRunner自体を「Protected Environments」に紐付けよ。これにより、開発者がCI設定ファイルを書き換えて、本番用のクレデンシャル（AWS Secret Key等）を盗み出す攻撃を封じ込める。
- アーキテクチャ上の注意点:
- Variablesのスコープ: GitLabのCI/CD Variablesは、必ず「Protected」かつ「Environment scope」を限定すること。`production`ブランチ以外では、これらの変数はメモリ上に一切ロードされない。これが真のインフラ保護だ。
—
4. 悲劇を未然に防ぐ「マージ戦略」の要諦
「誰でもマージできる」は、組織の崩壊を招く。以下の設定をポリシーとして強制せよ。
1. Merge Request dependencies: 先行するタスクが完了するまでマージ不可にする。
2. Pipelines must succeed: テストが通っていないコードをマージする人間は、プロではない。
3. All discussions must be resolved: コードレビューの指摘を無視したマージは、技術的負債の爆弾だ。
—
伝説的エンジニアからの提言：人間を信じるな、システムを信じろ
GitLabのProtected Branchesは、強力な武器だが、運用が形骸化すれば単なる足枷になる。重要なのは「なぜその制約が必要なのか」をチーム全員が理解し、それをAPIやInfrastructure as Codeで自動化し続けることだ。
自動化できない設定は、脆弱性の温床となる。
今日からGUIの画面を閉じ、APIで保護を管理せよ。それが、システムを聖域に変える唯一の道だ。
—
「自動化は、怠惰のためではなく、人間が人間らしく、よりクリエイティブな課題に集中するための唯一の手段である。」