正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

セキュリティコンテキストの制約

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed

概要

OpenShiftのポッドは、セキュリティコンテキスト制約に基づいて権限を受け取ります。セキュリティコンテキスト制約(略称SCC)は、大規模なデプロイで使用するために、ロールベースのアクセス制御メカニズムを簡素化します。管理者はアップストリームドキュメントを参照して、セキュリティコンテキスト制約の仕組みとOpenShiftでの役割についてより深く理解することができます

管理者は、次のリソースも参照できます:

  1. OpenShiftでのセキュリティコンテキスト制約の管理
  2. OpenShiftとUIDのガイド

GitLabデプロイ内のセキュリティコンテキスト制約

gitlab-controller-managerデプロイは、Operatorプロセスを含むポッドを作成および管理します。これと、それが作成および管理する他のポッドは、restrictedセキュリティコンテキスト制約で実行されます。

Operatorは、GitLabアプリケーションに必要なすべてのリソースを管理できるようにする、堅牢な権限を持つServiceAccountを使用します。

Operatorは、Cloud Native GitLabを構成するコンポーネントサービスを管理します。これは、Operatorによって指定されたUIDに準拠しないポッドを積極的に終了および置換します。このメカニズムは、最小特権の原則を強化します。

GitLabアプリケーションのカスタムリソース定義

GitLabカスタムリソースを満たすためにOperatorによってデプロイされたポッドは、non-root-v2セキュリティコンテキスト制約を使用します。サードパーティのオペレーターおよびリソースのセキュリティコンテキスト制約については、次のセクションで説明します

gitlab-app-nonroot ServiceAccountには、権限が付与されておらず、GitLabアプリケーションポッドにnonroot-v2セキュリティコンテキスト制約をバインドするためだけに存在します。

OpenShiftセキュリティモデル内でGitLabアプリケーションの完全な読み取り/書き込み動作が検証されるため、セキュリティコンテキスト制約は今後のリリースで強化されます。

LinuxパッケージインストールからCloud Native GitLabに移行する管理者は、sudoで実行されるLinuxパッケージインストールのタスクは、OpenShiftおよび基盤となるKubernetesエンジンによって処理されることに注意してください。ポッドは個々のサービスであり、Linuxパッケージインストールでは、アプリケーション固有のユーザーとして実行する権限を削除します。Operatorは、予期されるUIDで動作していないポッドを終了します

サードパーティのリソース定義

Ingressコントローラー

GitLabは、Cloud Native GitLabをデプロイするときに、nginx-ingress-controllerを使用したデプロイを推奨し、テストします。独自のnginx-ingress-sccセキュリティコンテキスト制約を使用します。

代替のIngressコントローラーを選択する場合は、関連ドキュメントを参照して、そのセキュリティコンテキスト制約の詳細を確認してください。

SSL暗号化

Operatorは、GitLabアプリケーション全体でSSL証明書を管理するために、JetStackのcert-manager-operatorをデプロイします。cert-manager-operatorは、セキュアコンテキスト制約を直接設定しないため、OpenShiftはrestrictedセキュリティコンテキスト制約をデフォルトで適用します。