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

概要

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

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

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

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

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

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

Operatorは、クラウドネイティブGitLabを構成するコンポーネントサービスを管理します。Operatorは、自身が指定したUIDに適合しないポッドを積極的に停止し、入れ替えます。この仕組みにより、最小権限の原則が強制されます。

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

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

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

OpenShiftのセキュリティモデルにおいてGitLabアプリケーションの完全な読み取り/書き込み動作が検証されるにつれて、今後のリリースでセキュリティコンテキスト制約はさらに厳格化される予定です。

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

Ingressコントローラー

GitLabは、クラウドネイティブGitLabをデプロイする際に、nginx-ingress-controllerを使用したデプロイを推奨し、テストを行っています。これは独自のnginx-ingress-sccセキュリティコンテキスト制約を使用します。

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

SSL暗号化

GitLab Operatorは、前提条件としてcert-managerを別途インストールする必要があります。GitLab Operatorは、cert-manager IssuerおよびCertificateを設定して、GitLabアプリケーション全体のTLSを管理します。cert-managerはセキュリティコンテキスト制約を直接設定しないため、OpenShiftはデフォルトでrestrictedセキュリティコンテキスト制約を適用します。