この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

これは未公開の文書です Admission Controller 1.34-dev.

クイックスタート

SUSE Security Admission Controllerスタックは次のように構成されています。

  • 1つ以上のClusterAdmissionPolicyリソース：これはKubernetesクラスターのポリシーを定義します。

  • 1つ以上のPolicyServerリソース：これはAdmission Controller `PolicyServer`のデプロイを表します。Admission Controller `PolicyServer`は、管理者のポリシーを読み込み、評価します。

  • 1つ以上のAdmissionPolicyリソース：定義されたネームスペースのポリシーです。

  • `kubewarden-controller`のデプロイ：このコントローラーはClusterAdmissionPolicyリソースを監視し、Admission Controller PolicyServerコンポーネントと相互作用します。

Admission ControllerはそのKubernetesカスタムリソース定義（CRD）をここで説明します。

このチュートリアルおよび他のドキュメントで言及されているAdmission Controller CRDは、使用しやすい短い名前を持っています。これらはCRDの短い名前です。

リソースの作成 shortName

AdmissionPolicies

ap

ClusterAdmissionPolicies

cap

AdmissionPolicyGroups

apg

ClusterAdmissionPolicyGroups

capg

PolicyServers

ps

インストール

認証

Admission Controllerポリシーは、https://ghcr.io.のGitHubコンテナレジストリから取得できます。リポジトリをAdmission Controller CLIで使用するには認証が必要で、https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens[GitHub個人アクセストークン] (PAT) が必要です。ドキュメントでは、まだ作成していない場合の作成手順が案内されています。 次に、次のようなコマンドで認証します。

echo $PAT | docker login ghcr.io --username <my-gh-username> --password-stdin

Admission Controllerスタックを次のように`helm`チャートを使ってデプロイします。

helm repo add kubewarden https://charts.kubewarden.io
helm repo update kubewarden

Kubernetesクラスターの`kubewarden`ネームスペースに次のHelmチャートをインストールします。

  • `kubewarden-crds`は、ClusterAdmissionPolicy、AdmissionPolicy、およびPolicyServerカスタムリソース定義を登録します。また、監査スキャナーで使用される{report}カスタムリソース定義もあります。

  • `kubewarden-controller`は、Admission Controllerコントローラーと監査スキャナーをインストールします。

    監査スキャナーコンポーネントを無効にする必要がある場合は、監査スキャナーのインストールドキュメントページを確認してください。

  • kubewarden-defaults`は、`PolicyServer`リソース（名前：`default）を作成します。また、よく知られたベストプラクティスを強制することで、クラスターを保護するための推奨ポリシーセットをインストールすることもできます。

helm install --wait -n kubewarden --create-namespace kubewarden-crds kubewarden/kubewarden-crds
helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller
helm install --wait -n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults

v0.4.0のため、`kubewarden-controller`チャートを使用しても、`default`という名前の`PolicyServer`リソースは作成されません。`kubewarden-defaults`というHelmチャートが、デフォルトのポリシーサーバーをインストールします。

これは、kubewarden-controller`の最新バージョンを使用していない場合、アップグレードするまたは削除する際に、デフォルトのポリシーサーバーがアップグレードされず、または削除されないことを意味します。したがって、同じポリシーサーバー名など、矛盾する情報で`kubewarden-defaults`をインストールしようとすると問題が発生する可能性があります。将来の`kubewarden-defaults Helmチャートのアップグレードをインストールするには、新しいチャートをインストールする前に、`kubewarden-controller`によって作成された既存の`PolicyServer`リソースを削除する必要があります。これで、リソースの競合なしにHelmでアップグレードすることでポリシーサーバーを更新できます。`PolicyServer`を削除すると、それにバインドされたすべてのポリシーも削除されます。

デフォルトの設定値は、ほとんどのデプロイメントに対して十分です。https://charts.kubewarden.io/#configuration[ドキュメント]は、すべてのオプションを説明しています。

主要コンポーネント

Admission Controllerには、操作する三つの主要なコンポーネントがあります。

PolicyServer

`kubewarden-controller`は、Admission Controller `PolicyServer`を管理します。同じKubernetesクラスター内に複数のPolicyServerをデプロイすることができます。

`PolicyServer`は、受信リクエストに対してAdmission Controllerポリシーを実行することによって、リクエストを検証します。

これはデフォルトの`PolicyServer`設定です：

apiVersion: policies.kubewarden.io/v1
kind: PolicyServer
metadata:
  name: reserved-instance-for-tenant-a
spec:
  image: ghcr.io/kubewarden/policy-server:v1.3.0
  replicas: 2
  serviceAccountName: ~
  env:
    - name: KUBEWARDEN_LOG_LEVEL
      value: debug

最新リリースの`PolicyServer`バージョンを確認し、タグを一致させて変更してください。

`PolicyServer`リソースの属性の概要：

必須 Placeholder 説明

Y

image

コンテナイメージの名前

Y

replicas

希望するインスタンスの数

N

serviceAccountName

`ServiceAccount`の名前を、`PolicyServer`デプロイメントに使用します。提供された値がない場合、`kubewarden-controller`のインストールネームスペースからのデフォルトの`ServiceAccount`が使用されます。

N

env

環境変数のリスト

N

annotations

アノテーションのリスト

これらの属性のいずれかを変更すると、新しい設定で`PolicyServer`デプロイメントが発生します。

ClusterAdmissionPolicy

ClusterAdmissionPolicyリソースは、Admission Controllerスタックのコアです。ポリシーがリクエストを評価する方法を定義します。

ポリシーの強制は、Kubernetes管理者が行う最も一般的な操作です。必要なだけ多くのポリシーを宣言することができ、それぞれが一つ以上のKubernetesリソース（すなわち、pods、Custom Resource`など）を対象とします。対象リソースに適用される操作のタイプも指定します。利用可能な操作は`CREATE、UPDATE、`DELETE`および`CONNECT`です。

既定のClusterAdmissionPolicy設定:

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-capabilities
spec:
  policyServer: reserved-instance-for-tenant-a
  module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.9
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
        - CREATE
        - UPDATE
  mutating: true
  settings:
    allowed_capabilities:
      - CHOWN
    required_drop_capabilities:
      - NET_ADMIN

ClusterAdmissionPolicyリソースの属性の概要：

必須 Placeholder 説明

N

policy-server

既存の`PolicyServer`オブジェクトを識別します。この`PolicyServer`インスタンスのみがポリシーを提供します。名前が`default`のポリシーサーバーは、明示的な`PolicyServer`なしでClusterAdmissionPolicyを提供します。

Y

module

Admission Controllerポリシーの場所。次のスキームが許可されています:

N

- registry:https://github.com/opencontainers/artifacts[OCIアーティファクト]に準拠したコンテナレジストリからのポリシーのダウンロード。例: registry://<OCI registry/policy URL>

N

- http, https:通常のHTTP(s)サーバーからのポリシーのダウンロード。 例: https://<website/policy URL>

N

- file:コンピュータのファイルシステム内のファイルからポリシーを読み込みます。 例: file:///<policy WASM binary full path>

Y

resources

ポリシーによって評価されるKubernetesリソース

Y

operations

APIサーバーは、評価のために、以前に指定されたタイプの操作をこのAdmissionPolicyに転送すべきです。

Y

mutating

受信リクエストを変更できるポリシーのために、このブール値`true`を設定します。

N

settings

ポリシー設定値を含む自由形式のオブジェクト

N

failurePolicy

ポリシーによって評価されたリクエストがエラーを引き起こした場合に取るべきアクション。 次のオプションが許可されています。

N

- Ignore: ウェブフックの呼び出しでエラーを無視し、APIリクエストが続行されます。

N

- Fail: ウェブフック呼び出し時にエラーが発生すると、Admissionが失敗し、APIリクエストが拒否されます。

コントローラーは、ClusterAdmissionPolicyリソースの`*`ウェブフック`scope`を登録します。これは、登録されたウェブフックが、指定された`resources`および`operations`に一致するすべてのリクエストを、ネームスペースまたはクラスター全体のリソースとして転送することを意味します。

AdmissionPolicy

AdmissionPolicyはネームスペース全体のリソースです。ポリシーは、AdmissionPolicyが定義されたネームスペースをターゲットにしたリクエストのみを処理します。 それ以外には、AdmissionPolicyとClusterAdmissionPolicyリソースの間に機能的な違いはありません。

AdmissionPolicyはKubernetes 1.21.0以上が必要です。これは、Admission ControllerがKubernetes 1.21.0で導入された`kubernetes.io/metadata.name`ラベルを使用しているためです。

これらのカスタムリソースの完全なドキュメントはhttps://github.com/kubewarden/kubewarden-controller/blob/main/docs/crds/README.asciidoc[こちら]またはhttps://doc.crds.dev/github.com/kubewarden/kubewarden-controller[docs.crds.dev]にあります。

例:最初のポリシーを強制します。

私たちはhttps://github.com/kubewarden/pod-privileged-policy[pod-privileged]ポリシーを使用します。 このポリシーを強制することで、Kubernetesクラスター内で特権コンテナの作成を防ぎたいと考えています。

それを行うためにClusterAdmissionPolicyを定義しましょう：

kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: privileged-pods
spec:
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.2.2
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  mutating: false
EOF

これにより、次の出力が生成されます：

clusteradmissionpolicy.policies.kubewarden.io/privileged-pods created

ClusterAdmissionPolicyをインスタンス化した後、ステータスは`pending`になり、ターゲットの`PolicyServer`のロールアウトを強制します。例では、`PolicyServer`という名前の`default`です。次のコマンドを実行することで、ロールアウトを監視できます：

kubectl get clusteradmissionpolicy.policies.kubewarden.io/privileged-pods

次の出力が表示されます：

NAME              POLICY SERVER   MUTATING   STATUS
privileged-pods   default         false      pending

新しいポリシーが準備できたら、`kubewarden-controller`はhttps://kubernetes.io/docs/reference/generated/kubernetes-api/v1.33/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io[ValidatingWebhookConfiguration]オブジェクトを登録してそれを提供します。

すべての`PolicyServer`インスタンスのデプロイメントが完了すると、ClusterAdmissionPolicyのステータスは`active`になります。次のコマンドでValidatingWebhookConfigurationを表示します：

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l kubewarden

次の出力が表示されます：

NAME                          WEBHOOKS   AGE
clusterwide-privileged-pods   1          9s

ClusterAdmissionPolicyがアクティブになり、ValidatingWebhookConfigurationが登録されると、ポリシーをテストできます。

まず、`privileged`モードでコンテナ_not_を持つポッドを作成できます：

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: unprivileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
EOF

これにより、次の出力が生成されます：

pod/unprivileged-pod created

ポッドが正常に作成されました。

今、少なくとも1つのコンテナ`privileged`フラグを持つポッドを作成できます：

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      securityContext:
          privileged: true
EOF

ポリシーはポッドの作成を拒否し、次のメッセージが表示されるはずです：

Error from server: error when creating "STDIN": admission webhook "clusterwide-privileged-pods.kubewarden.admission" denied the request: Privileged container is not allowed

両方の例では`namespace`が定義されていなかったため、`default`ネームスペースがターゲットであったことを意味します。しかし、2番目の例で見たように、ポリシーは依然として適用されています。前述の通り、これはスコープがクラスター全体に及び、特定のネームスペースをターゲットにしていないためです。

アンインストール

次のように`helm`チャートをアンインストールすることで作成されたリソースを削除できます：

helm uninstall --namespace kubewarden kubewarden-defaults
helm uninstall --namespace kubewarden kubewarden-controller
helm uninstall --namespace kubewarden kubewarden-crds

`helm`チャートを削除した後、Admission Controllerスタックをデプロイするために使用されたKubernetesネームスペースを削除します：

kubectl delete namespace kubewarden

Admission Controllerには、すべての`PolicyServer`と`kubewarden-controller`を削除するhelmのプレ削除フックが含まれています。その後、`kubewarden-controller`はすべてのリソースを削除するため、helm uninstallが実行されるときに`kubewarden-controller`が実行中であることが重要です。

Admission ControllerはValidatingWebhookConfigurationとMutatingWebhookConfigurationを削除します。これを次のように確認します：

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"

これらのリソースが自動的に削除されない場合は、次のコマンドを使用して手動で削除します：

kubectl delete -l "kubewarden" validatingwebhookconfigurations.admissionregistration.k8s.io
kubectl delete -l "kubewarden" mutatingwebhookconfigurations.admissionregistration.k8s.io

まとめ

ClusterAdmissionPolicyはクラスターオペレーターが管理しなければならないコアリソースです。`kubewarden-controller`モジュールは、ポリシーを実行するために必要な他のリソースの設定を自動的に処理します。

次の手順

これで、Admission Controllerをデプロイする準備ができました！https://artifacthub.io/packages/search?kind=13[artifacthub.io]のポリシー、https://github.com/topics/kubewarden-policy[GitHub]のポリシー、または次の章に示されている既存のRegoポリシーを再利用してください。

ArtifactHubで利用可能なポリシーの完全なリスト