はじめに

OpenShiftクラスターの運用において、「意図しない設定のリソースがデプロイされてしまう」「特定のネームスペースのリソースには必須のラベルを付与したいが、手動だと漏れがあるので自動化したい」といった課題はありませんか？

本記事では、Kubernetesネイティブなポリシーエンジンである Open Policy Agent (OPA) と、それをKubernetesに適用するGatekeeper をOpenShift環境に導入する手順を解説します。さらに、非接続環境での考慮事項も取り上げることでエンタープライズ環境に即した知見を共有します。

OpenShiftには専用のGatekeeper Operatorが存在し、簡単にGatekeeperを導入できるメリットがありますが、本記事ではOSS版Gatekeeperの導入に焦点を当てて解説します。

OPA/Gatekeeperについて

Open Policy Agent (OPA) は、一般的なポリシーエンジンです。アプリケーションやシステムを問わず、統一された方法でポリシーを定義・適用することを可能にします。一方、Gatekeeper は、そのOPAをKubernetesのAdmission Controllerとして利用するためのツールです。

Gatekeeperの動作イメージは図のようになります。ユーザーがKubernetesリソースをデプロイしようとすると、Gatekeeperはそのリクエストをインターセプトし、事前に定義されたOPAのポリシー（Regoと呼ばれる言語で記述）に照らして評価します。リクエストがポリシーに違反していなければ、APIサーバーはリソースをデプロイします。一方、違反していればデプロイは拒否されます。これにより、継続的なポリシー制御でクラスター内のリソース設定を強制し、組織全体で統一したポリシー運用が可能になります。

事前作業（非接続環境での準備）

インターネット接続環境と異なり、非接続環境では外部のコンテナレジストリに直接アクセスできません。そのため、Gatekeeperのコンテナイメージをプライベートなイメージレジストリに用意する事前作業が必要です。インターネット接続環境に導入する際はこの事前作業は不要です。

前提条件

以下のようなOpenShift非接続環境を前提として構築準備を行います。

外部インターネットに接続できない OpenShift クラスター
OpenShift用のミラーレジストリーサーバー
OS：RHEL9
- Gatekeeperのコンテナイメージを取得できること
作業用サーバー兼踏み台サーバー
OS：RHEL9
OpenShiftクラスターにアクセス可能であり、以下の役割を兼任：
- 内部DNSサーバー、ロードバランサー

※本記事では Gatekeeper の構築に焦点を当てており、作業用サーバーや OpenShift クラスターの構築手順については割愛しています。

イメージレジストリへのイメージ取得

ミラーレジストリサーバーでイメージレジストリにGatekeeperが必要とするコンテナイメージを取得します。

ミラーレジストリ構築時に使用したImageSetConfigurationファイルを編集します。additionalImagesにname: docker.io/openpolicyagent/gatekeeper:<バージョン>を追加します。今回は2025年8月時点で最新のv3.20.0を導入します。

apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    channels:
    ...
  operators:
  additionalImages:
    ...
    - name: docker.io/openpolicyagent/gatekeeper:v3.20.0
  helm:
    ...

リポジトリのミラーリングを実施します。

例：$ oc mirror -c ImageSetConfiguration.yaml --workspace file:///$HOME/work/mirror-image docker://<ミラーレジストリーサーバーのホスト名>:8443 --v2

Gatekeeperのイメージ参照先を変更

OpenShiftクラスターにGatekeeperをデプロイする際、マニフェストファイル内のイメージ参照先を、準備したプライベートなイメージレジストリに変更します。

作業用サーバーでGatekeeperのマニフェストファイルをダウンロードします。

$ curl -O https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.20.0/deploy/gatekeeper.yaml

Deploymentのimageの取得先を表示例のように全て変更します。
Deploymentはgatekeeper-auditとgatekeeper-controller-managerの2つが存在しています。

$ vi gatekeeper.yaml
変更前
image: openpolicyagent/gatekeeper:v3.20.0

変更後
image: <ミラーレジストリーサーバーのホスト名>:8443/openpolicyagent/gatekeeper:v3.20.0

構築作業

2025年8月時点で最新のGatekeeper：v3.20.0をOpenShiftクラスターに導入していきます。

Gatekeeperの導入

作業用サーバーでGatekeeperのデプロイを実施します。

インターネット接続環境の場合は以下のコマンドで簡単にデプロイ可能です。

$ oc apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.20.0/deploy/gatekeeper.yaml

非接続環境の場合は、「Gatekeeperのイメージ参照先を変更」で取得したマニフェストファイルを適用します。

$ oc apply -f gatekeeper.yaml

Gatekeeperのサービスアカウントにcluster-admin権限を付与します。特に、GatekeeperのサービスアカウントがCRDを作成できる権限を設定する必要があるため、今回は簡易にcluster-adminを付与していますが、本番等での運用では適切に権限を設計することを推奨します。

$ oc adm policy add-cluster-role-to-user cluster-admin -z gatekeeper-admin -n gatekeeper-system

Gatekeeperの導入確認

Gatekeeperの以下のPodが立ち上がっていることを確認します。

gatekeeper-audit
gatekeeper-controller-manager

$ oc get pods -n gatekeeper-system
NAME READY STATUS RESTARTS AGE
gatekeeper-audit-7c84869dbf-r5p87 1/1 Running 0 2m34s
gatekeeper-controller-manager-ff58b6688-9tbxx 1/1 Running 0 3m23s
gatekeeper-controller-manager-ff58b6688-njfnd 1/1 Running 0 2m54s
gatekeeper-controller-manager-ff58b6688-vlrsl 1/1 Running 0 3m11s

Gatekeeperのポリシー適用範囲の設定

Gatekeeperは、クラスター内のすべてのリソースをチェックするのがデフォルトの動作です。しかし、システムが管理するネームスペース（kube-systemやopenshift-で始まるものなど）には、Gatekeeperのポリシーを適用したくない場合があります。これらのネームスペースにポリシーが適用されると、システムの重要なコンポーネントがデプロイできなくなるなどの問題が発生する可能性があります。この考慮漏れで私はOpenShiftクラスターを壊してしまった経験があります。とほほ…。

この問題を解決するために、Configリソースを使ってexcludedNamespaces（除外するネームスペース）を定義します。Gatekeeper導入前からある、ポリシーの適用範囲外にしたいネームスペースをexcludedNamespacesに列挙してください。

$ vi gatekeeper_config.yaml

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: "gatekeeper-system"
spec:
  match:
  - excludedNamespaces: ["assisted-installer", "default", "gatekeeper-system", "kube-*", "openshift*"]
    processes: ["*"]