セキュリティ・コンテキスト制約
概要
OpenShift のポッドは、セキュリティコンテキスト制約に基づいて権限を受け取ります。セキュリティコンテキスト制約は、しばしば _SCC_と略されることが多く、大規模デプロイで使用するロールベースのアクセス制御メカニズムを単純化します。管理者は、セキュリティコンテキスト制約がどのように機能し、OpenShiftにおいてどのような位置づけにあるかについて、よりインサイトを得るために、アップストリームのドキュメントを参照することができます。
管理者は以下のリソースも参照してください：
GitLab デプロイ内のセキュリティコンテキスト制約
gitlab-controller-manager デプロイは、Operatorプロセスを含むポッドを作成・管理します。このポッドと、このポッドが作成・管理するその他のポッドは _制限付き_セキュリティコンテキスト制約で実行されます。
Operatorは、GitLabアプリケーションに必要なすべてのリソースを管理できるように、堅牢な権限を持つServiceAccountを使用します。
Operatorは、Cloud Native GitLabを構成するコンポーネントサービスを管理します。Operatorによって指定されたUIDに適合しないポッドを積極的に終了して置き換えます。このメカニズムは最小特権の原則を強制します。
GitLabアプリケーションのカスタムリソース定義
GitLabカスタムリソースを満たすためにオペレーションによってデプロイされたポッドは _anyuid_セキュリティコンテキスト制約を使います。サードパーティオペレータとリソースのセキュリティコンテキスト制約については、次のセクションで説明します。
gitlab-app-anyuid 、gitlab-app-nonroot ServiceAccountsには付与された権限はありません。これらは _をバインドするためだけに存在します。_と _非 root_セキュリティコンテキスト制約を GitLab アプリケーションポッドにバインドするためだけに存在します。
GitLabアプリケーションの完全な_読み取り/書き込み_動作がOpenShiftセキュリティモデル内で検証されるにつれて、セキュリティコンテキスト制約は将来のリリースで強化される予定です。
sudo で実行されるLinuxパッケージのインストールタスクは、OpenShiftと基盤となるKubernetesエンジンによって処理されることに注意する必要があります。ポッドは、Linuxパッケージのインストールでは、アプリケーション固有のユーザーとして実行する権限をドロップする個々のサービスです。Operatorは、期待される UID でオペレーションしていないポッドを終了します。サードパーティのリソース定義
イングレスコントローラ
GitLab は、Cloud Native GitLab をデプロイする際にnginx-ingress-controller を使ったデプロイを推奨し、テストしています。独自のnginx-ingress-scc セキュリティコンテキスト制約を使用します。
別のIngressコントローラを選択する場合は、関連するドキュメントを参照して、そのセキュリティコンテキスト制約の詳細を確認してください。
SSL暗号化
Operatorは JetStackからcert-manager-operatorをデプロイし、GitLabアプリケーション全体でSSL証明書を管理します。cert-manager-operatorはセキュアコンテキスト制約を直接設定しないため、OpenShiftはSSL証明書に対して _制限付き_セキュリティコンテキスト制約をデフォルトで適用します。