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

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

生のポリシー

v1.9.0`以降、SUSE Security Admission ControllerはKubernetesクラスターの外部で、一般的なポリシー評価エンジンとしてポリシーを記述および実行する機能をサポートします。ポリシーサーバーは、任意のJSONドキュメントをAdmission Controllerポリシーに対して検証するために使用できる/validate_raw`エンドポイントを公開します。

このガイドでは、次の生ポリシーを使用します：

ポリシーの著者がメタデータでポリシーを`policyType: raw`としてマークしていることを確認してください。 `kwctl`を使用してメタデータを確認できます。

kwctl inspect ghcr.io/kubewarden/tests/raw-mutation-policy:v0.1.0

Kubernetesの外部でポリシーサーバーを実行する

ポリシーサーバーは、Kubernetesの外部でスタンドアロンコンテナとして実行できます。

次の内容が含まれる`policies.yml`ファイルを作成します：

raw-validation:
  module: ghcr.io/kubewarden/tests/raw-validation-policy:v0.1.0
  settings:
    validUsers:
      - alice
      - bob
    validActions:
      - read
      - write
    validResources:
      - orders
      - products

raw-mutation:
  module: ghcr.io/kubewarden/tests/raw-mutation-policy:v0.1.0
  allowedToMutate: true
  settings:
    forbiddenResources:
      - privateResource
      - secretResource
    defaultResource: publicResource

ポリシーサーバーを起動するには：

# Create a docker volume to store the policies
docker volume create --driver local \
                --opt type=tmpfs \
                --opt device=tmpfs \
                --opt o=ui=65533 \
                policy-store

# Start the policy server
docker run --rm -it \
    -p 3000:3000 \
    -v $(pwd)/policies.yml:/policies.yml \
    -v policy-store:/registry \
    ghcr.io/kubewarden/policy-server:1.9.0 \
    --ignore-kubernetes-connection-failure=true

Kubernetesなしでポリシーサーバーを起動するには、フラグ`--ignore-kubernetes-connection-failure=true`が必要です。ただし、Kubernetes内でポリシーサーバーを起動し、生の検証エンドポイントを使用することも可能です。生ポリシーは、標準ポリシーと同様に、コンテキストに応じた機能にアクセスできます。

Admission ControllerコントローラーなしでKubernetes内でポリシーサーバーを実行する

Admission Controllerコントローラーによって管理されているポリシーサーバーインスタンスを使用して生ポリシーをホストすることはできません。コントローラーは、ユーザーが生ポリシーを追加するためにPolicy Server ConfigMapを変更することを許可しません。なぜなら、変更を元に戻すように調整を試みるからです。そのため、専用のPolicy Serverを起動する必要があります。

次の内容が含まれる`policy-server.yaml`ファイルを作成します：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: policy-server-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: policy-server
  template:
    metadata:
      labels:
        app: policy-server
    spec:
      containers:
        - name: policy-server
          image: ghcr.io/kubewarden/policy-server:v1.9.0
          ports:
            - containerPort: 3000
          volumeMounts:
            - name: policy-store
              mountPath: /registry
            - name: policies-config
              mountPath: /policies.yml
              subPath: policies.yml
      volumes:
        - name: policy-store
          emptyDir: {}
        - name: policies-config
          configMap:
            name: policies-configmap
---
apiVersion: v1
kind: Service
metadata:
  name: policy-server-service
spec:
  selector:
    app: policy-server
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: policies-configmap
data:
  policies.yml: |
    raw-validation:
      module: ghcr.io/kubewarden/tests/raw-validation-policy:v0.1.0
      settings:
        validUsers:
          - alice
          - bob
        validActions:
          - read
          - write
        validResources:
          - orders
          - products
    raw-mutation:
      module: ghcr.io/kubewarden/tests/raw-mutation-policy:v0.1.0
      allowedToMutate: true
      settings:
        forbiddenResources:
          - privateResource
          - secretResource
        defaultResource: publicResource

設定を適用します。

kubectl apply -f policy-server.yaml

デプロイされたPolicy Serverインスタンスは、コンテキストに応じたポリシーで使用されるKubernetesリソースにアクセスできます。 Kubernetesリソースへのアクセスレベルは、Policy Serverワークロードを実行するために使用されるService Accountによって決まります。

前の例では、デプロイメント仕様内にService Accountが定義されていないため、default Service Accountが使用されます。

validate_rawエンドポイントを使用する

検証

生の検証エンドポイントは`/validate_raw`で公開され、`POST`リクエストを受け入れます。サービスをデプロイしたので、`kubectl port-forward service/policy-server-service 3000:3000 -n default`を使ってポートフォワードを設定できます。

`raw-validation`ポリシーに従ってJSONドキュメントを検証してみましょう：

curl -X POST \
  http://localhost:3000/validate_raw/raw-validation \
  -H 'Content-Type: application/json' \
  -d '{
  "request": {
    "user": "alice",
    "action": "read",
    "resource": "customers"
  }
}'

リクエストは受け入れられません。なぜなら、`alice`に`customers`リソースへのアクセスが付与されていないからです：

{
  "response": {
    "uid": "",
    "allowed": false,
    "auditAnnotations": null,
    "warnings": null
  }
}

有効なリソースで再試行してみましょう：

curl -X POST \
  http://localhost:3000/validate_raw/raw-validation \
  -H 'Content-Type: application/json' \
  -d '{
  "request": {
    "user": "alice",
    "action": "read",
    "resource": "orders"
  }
}'

今回は、リクエストが受け入れられます：

{
  "response": {
    "uid": "",
    "allowed": true,
    "auditAnnotations": null,
    "warnings": null
  }
}

リクエストペイロードに`uid`フィールドが提供されている場合、それはレスポンスの一部として返されます。

ミューテーション

では、`raw-mutation`ポリシーに従ってJSONドキュメントを変更してみましょう：

curl -X POST \
  http://localhost:3000/validate_raw/raw-mutation \
  -H 'Content-Type: application/json' \
  -d '{
  "request": {
    "user": "alice",
    "action": "read",
    "resource": "privateResource"
  }
}'

リクエストは変更され、レスポンスにはJSONPatchが含まれます：

{
  "response": {
    "uid": "",
    "allowed": true,
    "patchType": "JSONPatch",
    "patch": "W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9yZXNvdXJjZSIsInZhbHVlIjoicHVibGljUmVzb3VyY2UifV0=",
    "auditAnnotations": null,
    "warnings": null
  }
}

生のポリシーを書く

Kubernetesリソースを検証するポリシーと同様に、生ポリシーはAdmission Controller SDKを使用してWebAssemblyで記述されます。生ポリシーの作成に興味がある場合は、詳細について言語固有のドキュメントを参照してください：