保護された環境
環境はテストと本番の両方の理由で使用できます。
デプロイジョブは異なるロールを持つ異なるユーザーによって実行される可能性があるため、権限のないユーザーの影響から特定の環境を保護できるようにすることが重要です。
デフォルトでは、保護された環境は、適切な権限を持つ人だけがその環境にデプロイできるようにし、環境を安全に保ちます。
環境を保護・更新・保護解除するには、少なくともメンテナーのロールが必要です。
環境の保護
前提条件：
- グループまたはサブグループにデプロイ許可権限を付与する場合、保護環境を設定するユーザーが追加するグループまたはサブグループの直接のメンバーである必要があります。そうでない場合、グループまたはサブグループはドロップダウンリストに表示されません。詳しくは、イシュー#345140を参照してください。
環境を保護するには
- 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
- Settings > CI/CDを選択します。
- 保護された環境を展開します。
- 環境の保護] を選択します。
- 環境リストから、保護する環境を選択します。
-
デプロイ許可リストで、デプロイアクセスを許可するロール、ユーザー、またはグループを選択します。以下の点に注意してください：
- 選択できるロールは2つあります：
- メンテナー：メンテナーのロールを持つプロジェクトのすべてのユーザーへのアクセスを許可します。
- 開発者：メンテナーと開発者ロールを持つプロジェクトのすべてのユーザーへのアクセスを許可します。
- すでにプロジェクトに関連付けられているグループのみを選択できます。
- Allowed to deployリストに表示されるには、ユーザーは少なくとも Developer ロールを持っている必要があります。
- 選択できるロールは2つあります：
-
承認者]リストで、デプロイへのアクセス権を与えたいロール、ユーザー、またはグループを選択します。以下の点に注意してください：
- 選択できるロールは2つあります：
- メンテナー：メンテナーのロールを持つプロジェクトのすべてのユーザーへのアクセスを許可します。
- 開発者：メンテナーと開発者ロールを持つプロジェクトのすべてのユーザーへのアクセスを許可します。
- すでにプロジェクトに関連付けられているグループのみを選択できます。
- 承認者リストに表示されるユーザーは、少なくとも開発者ロールを持っている必要があります。
- 選択できるロールは2つあります：
-
承認ルールセクションで
- この数がルールのメンバー数以下であることを確認します。
- この機能の詳細については、「デプロイ承認者」を参照してください。
- 保護]を選択します。
保護された環境が保護された環境のリストに表示されます。
API を使用して環境を保護します。
APIを使って環境を保護することもできます：
-
環境を作成するCIを持つプロジェクトを使います。例えば
stages: - test - deploy test: stage: test script: - 'echo "Testing Application: ${CI_PROJECT_NAME}"' production: stage: deploy when: manual script: - 'echo "Deploying to ${CI_ENVIRONMENT_NAME}"' environment: name: ${CI_JOB_NAME} -
UI を使用して新しいグループを作成します。たとえば、このグループは
protected-access-groupと呼ばれ、グループ ID は9899826です。この手順の残りの例では、このグループを使用することに注意してください。
-
APIを使用して、レポーターとしてグループにユーザーを追加します：
$ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \ --data "user_id=3222377&access_level=20" "https://gitlab.com/api/v4/groups/9899826/members" {"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://gitlab.com/sfcarroll","access_level":20,"created_at":"2020-10-26T17:37:50.309Z","expires_at":null} -
API を使用して、グループをレポーターとしてプロジェクトに追加します：
$ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \ --request POST "https://gitlab.com/api/v4/projects/22034114/share?group_id=9899826&group_access=20" {"id":1233335,"project_id":22034114,"group_id":9899826,"group_access":20,"expires_at":null} -
API を使用して、保護された環境アクセス権を持つグループを追加します：
curl --header 'Content-Type: application/json' --request POST --data '{"name": "production", "deploy_access_levels": [{"group_id": 9899826}], "required_approval_count": 0}' \ --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.com/api/v4/projects/22034114/protected_environments"
これでグループにアクセス権が付与され、UIで確認できるようになります。
グループメンバーによる環境アクセス
ユーザーは、グループ メンバーシップの一部として保護された環境へのアクセスを許可される場合があります。レポーターロールを持つユーザーは、この方法でのみ保護された環境へのアクセスを許可されます。
デプロイブランチアクセス
開発者ロールを持つユーザーは、以下のいずれかの方法で保護された環境へのアクセスを許可されます：
- 個人の貢献者として、ロールを通して。
- グループメンバーとして。
ユーザーが本番環境にデプロイされたブランチへのプッシュまたはマージアクセス権も持っている場合、以下の権限を持ちます：
- 環境を停止します。
- 環境を削除します。
- 環境ターミナルを作成します。
保護された環境へのデプロイ専用アクセス
保護された環境へのアクセス権は付与されているが、その環境にデプロイされたブランチへのプッシュやマージへのアクセス権は付与されていないユーザーには、その環境をデプロイするアクセス権のみが付与されます。プロジェクトにレポーターロールで追加された招待グループは、デプロイ専用アクセスのドロップダウンリストに表示されます。
デプロイ専用アクセスを追加するには
- 保護された環境へのアクセスを許可するメンバーを持つグループがまだ存在しない場合は、そのグループを作成します。
- レポーターロールでグループをプロジェクトに招待します。
- 環境の保護」の手順に従ってください。
環境の変更と保護解除
メンテナーは以下のことができます：
- デプロイ許可] ドロップダウン リストでアクセス権を変更することにより、既存の保護環境をいつでも更新できます。
- 保護されている環境の [保護解除] ボタンを選択して、保護されている環境の保護を解除します。
環境が保護解除されると、すべてのアクセスエントリが削除されます。
詳しくは、「展開の安全性」をご覧ください。
グループレベルの保護環境
通常、大規模な企業組織では、開発者とオペレータの間に明確な権限境界があります。開発者はコードをビルドしてテストし、オペレータはアプリケーションをデプロイして監視します。グループレベルの保護環境では、オペレータは開発者からクリティカルな環境へのアクセスを制限することができます。グループレベルの保護環境は、プロジェクトレベルの保護環境をグループレベルに拡張します。
デプロイの権限を次の表に示します：
| 環境 | 開発者 | オペレーション | カテゴリ |
|---|---|---|---|
| 開発者向け | 許可 | 許可 | 低環境 |
| テスト | 許可 | 許可 | 低環境 |
| ステージング | 不可 | 許可 | より高い環境 |
| 生産 | 不可 | 許可 | より高い環境 |
(参考：Wikipediaのデプロイ環境)
グループレベルの保護環境名
プロジェクトレベルの保護環境とは逆に、グループレベルの保護環境はデプロイ階層を名前として使用します。
グループは固有の名前を持つ多くのプロジェクト環境で構成されることがあります。たとえば、プロジェクト A にはgprd 環境があり、プロジェクト B にはProduction 環境があるため、特定の環境名を保護してもうまく機能しません。デプロイ ティアを使用することで、どちらもproduction デプロイ ティアとして認識され、同時に保護されます。
グループレベルメンバーシップの設定
グループレベルの保護環境の効果を最大にするためには、グループレベルのメンバーシップを正しく設定する必要があります：
- オペレーションは最上位グループのオーナーロールを与えられるべきです。オペレーターは、グループレベルの保護環境、グループレベルのランナー、グループレベルのクラスターを含むグループレベルの設定ページで、上位環境（本番環境など）のCI/CD設定をメンテナーすることができます。これらの設定は読み取り専用項目として子プロジェクトに継承されます。これにより、オペレーション担当者だけが組織全体のデプロイ ルールセットを設定できるようになります。
- 開発者には、トップレベルグループのDeveloperロール以上を与えないか、子プロジェクトのOwnerロールを明示的に与える必要があります。開発者はトップレベルグループの CI/CD 設定にアクセスできないため、重要な設定が開発者によって誤って変更されることはありません。
- サブグループと子プロジェクトの場合：
- サブグループについては、上位グループがグループレベルの保護環境を設定した場合、下位グループがそれを上書きすることはできません。
- プロジェクト レベルの保護環境は、グループ レベルの設定と組み合わせることができます。グループ レベルとプロジェクト レベルの両方の環境設定が存在する場合、デプロイ ジョブを実行するには、ユーザーが両方のルールセットで許可されている必要があります。
- プロジェクトまたは最上位グループのサブグループでは、開発者にメンテナー ロールを安全に割り当てて、下位環境 (
testingなど) を調整できます。
この設定を行うことで
- ユーザーがプロジェクトでデプロイジョブを実行しようとしていて、環境へのデプロイが許可されている場合、デプロイジョブは進行します。
- ユーザーがプロジェクトでデプロイ ジョブを実行しようとしているが環境へのデプロイが許可されていない場合、デプロイ ジョブはエラー メッセージとともに失敗します。
グループの下でクリティカルな環境を保護
グループレベルの環境を保護するには、.gitlab-ci.ymlで定義されているdeployment_tier が正しいことを確認してください。
UIの使い方
GitLab 15.1で導入されました。
- 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
- Settings > CI/CDを選択します。
- 保護された環境を展開します。
- 環境]リストから、保護する環境のデプロイ階層を選択します。
- デプロイ許可] リストで、デプロイ アクセスを許可するサブグループを選択します。
- 保護]を選択します。
API の使用
REST API を使用して、グループレベルの保護環境を設定します。
デプロイの承認者
保護された環境を使用して、デプロイ前に手動による承認者を要求することもできます。詳しくは、デプロイの承認者を参照してください。
トラブルシューティング
レポーターがダウンストリームパイプラインで保護された環境にデプロイするトリガージョブを実行できません。
保護された環境へのデプロイ専用のアクセス権を持っているユーザーが、trigger キーワードを持つジョブを実行できないことがあります。これは、ジョブを保護された環境に関連付けるためのenvironment キーワード定義がないため、ジョブが通常の CI/CD 権限モデルを使用する標準的なジョブとして認識されるためです。
trigger キーワードによるenvironment キーワードのサポートに関する詳細については、このイシューを参照してください。