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

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

概要

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

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

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

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

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

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

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

GitLabカスタムリソースを満たすためにオペレーターによってデプロイされたポッドは、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セキュリティコンテキスト制約を適用します。