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

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

Admission Controller ウェブフックのハードニング

SUSE Security Admission Controller スタックは、Kubernetes クラスター内でポリシーを強制するためにウェブフックを使用します。各 PolicyServer インスタンスは、Kubernetes API サーバーがリソースを検証および変更するために呼び出すウェブフックを公開します。さらに、kubewarden-controller は、Admission Controller プロジェクトによって提供されるカスタムリソースを検証および変更するためのウェブフックを公開します。

攻撃面を減らすために、これらのウェブフックへのアクセスを有効な呼び出し元のみに制限する必要があります：

Kubernetes API サーバー
監査スキャナーコンポーネント。

これをネットワークポリシーと認証を独立して、または一緒に使用して、ウェブフックを攻撃から強化することができます。

ネットワークポリシーを使用して外部トラフィックをブロックする

ウェブフックは、Kubernetes API サーバーおよび監査スキャナーコンポーネントからのリクエストのみを受け入れることが期待されています。ただし、デフォルトでは、ウェブフックは任意のソースからのトラフィックを受け入れることができます。API サーバーから発信されないトラフィックをブロックするポリシーを作成するには、ネットワークポリシーをサポートするネットワークインタフェース (CNI) を使用している場合、ポリシーを作成できます。

Kubernetes のビルトイン NetworkPolicy リソースは、クラスターのホストからのトラフィックをブロックまたは許可することはできません。また、kube-apiserver プロセスは常にホストネットワーク上で実行されています。したがって、使用中の CNI からの高度なネットワークポリシーリソースを使用する必要があります。Calico と Cilium の例が続きます。CNIの詳細については、ドキュメントを参照してください。

Calico

crd.projectcalico.org/v1 APIグループのNetworkPolicyリソースを使用して、次のようなネットワークポリシーを定義します:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-k8s-and-audit-scanner
  namespace: kubewarden
spec:
  selector: 'app.kubernetes.io/component in {"kubewarden-controller", "policy-server"}'
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      source:
        nets:
        - 192.168.42.0/24
      destination:
        selector: 'app.kubernetes.io/component in {"kubewarden-controller", "policy-server"}'
    - action: Allow
      protocol: TCP
      source:
        namespaceSelector: 'kubernetes.io/metadata.name == "kubewarden"'
      destination:
        selector: 'app.kubernetes.io/component in {"kubewarden-controller", "policy-server"}'

このネットワークポリシーは、Admission Controller 1.23.0で導入されたラベルセレクターを使用しています。古いバージョンを使用している場合は、ポリシー内のラベルをデプロイメントに合わせて更新してください。

より具体的には、次のようにセレクターを記述します:

selector: 'app.kubernetes.io/component in {"kubewarden-controller", "policy-server"}'

セレクターを次のように記述します:

selector: 'app.kubernetes.io/name == "kubewarden-controller" || has(kubewarden/policy-server)'

Cilium

cilium.io/v2 APIグループのCiliumNetworkPolicyリソースを使用して、次のようなネットワークポリシーを定義します:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-k8s-and-audit-scanner
  namespace: kubewarden
spec:
  endpointSelector:
    matchExpressions:
      - key: app.kubernetes.io/component
        operator: In
        values:
          - policy-server
          - controller
  ingress:
    - fromEntities:
      - host
      - remote-node
    - fromEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kubewarden

より具体的には、次のように式を記述します:

matchExpressions:
  - key: app.kubernetes.io/component
    operator: In
    values:
      - policy-server
      - controller

式を次のように記述します:

endpointSelector:
matchExpressions:
  - key: app.kubernetes.io/name
    operator: In
    values:
      - kubewarden-controller
  - key: kubewarden/policy-server
    operator: Exists

Kubernetes APIサーバーがWebhookに対して認証を行うことを要求します。

Webhook mTLSハウツーを参照して、K3sのKubernetes APIサーバーがWebhookに対して認証を行うための手順を確認してください。

Admission Controllerスタックによって公開されるWebhookは、Kubernetes APIサーバーまたは監査スキャナーコンポーネントからのリクエストのみを受け入れるべきです。デフォルトでは、これらのWebhookはクライアントに対して認証を要求しません。任意のリクエストを受け入れます。

Webhookに認証情報を要求するように設定することで、APIサーバーと監査スキャナープロセスのみがアクセスできるようにすることができます。詳細については、https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers[Kubernetesドキュメント]を参照してください。

APIサーバーを設定して、Webhookにクライアント証明書を提示し、`AdmissionConfiguration`ファイルを指して`ValidatingAdmissionWebhook`および`MutatingAdmissionWebhook`プラグインを設定します:

次の内容を含む`admission.yaml`という名前のファイルを作成します:
```
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
 configuration:
   apiVersion: apiserver.config.k8s.io/v1
   kind: WebhookAdmissionConfiguration
   kubeConfigFile: "/etc/k8s/admission/kubeconfig"
- name: MutatingAdmissionWebhook
 configuration:
   apiVersion: apiserver.config.k8s.io/v1
   kind: WebhookAdmissionConfiguration
   kubeConfigFile: "/etc/k8s/admission/kubeconfig"
```
これは、他のプラグイン（例えば`PodSecurity`）を設定するために使用される同じ設定ファイルです。配布版やセットアップが追加のアドミッションプラグインを使用している場合は、それらも設定する必要があります。
`kubeconfig`プラグインが参照するファイルを作成します。Admission Controllerはクライアント証明書認証のみをサポートしているため、TLSキーのペアを生成し、kubeconfigをクライアント証明書とクライアントキー、またはクライアント証明書データとクライアントキーのデータのいずれかを使用するように設定します。

次に例を示します。
```
apiVersion: v1
kind: Config
users:
- name: '*.kubewarden.svc'
  user:
    client-certificate: /path/to/client/cert
    client-key: /path/to/client/key
```
kube-apiserver`バイナリをフラグ--admission-control-config-file`を使用して、あなたの`AdmissionConfiguration`ファイルを指すように起動します。これを行う方法はディストリビューションによって異なり、ホスティングされたKubernetesプロバイダーのように普遍的にはサポートされていません。あなたのKubernetesディストリビューションのドキュメントを参照してください。
APIサーバークライアント証明書を発行したルートCAの証明書をAdmission Controllerスタックで利用可能にします。

その内容を`kubewarden`ネームスペースの下にある`ConfigMap`に、`client-ca.crt`という名前のキーを使用して配置します。

ルートCAが`/etc/k8s/admission/certs/rootCA.crt`で利用可能であると仮定し、次のコマンドで`ConfigMap`を作成します：
```
kubectl create configmap -n kubewarden api-server-mtls \
   --from-file=client-ca.crt=/etc/k8s/admission/certs/rootCA.crt
```
最後に、kubewarden-controller Helmチャートをインストールする際には、以下の値を有効にすることを確認してください：
- `mTLS.enable`を`true`に設定します。
- `mTLS.configMapName`を以前に作成した`ConfigMap`の名前に設定します。
  
  `ConfigMap`の名前は`api-server-mtls`であるため、`kubewarden-controller`をインストールするためのHelmコマンドは次のとおりです:
  helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller \ --set mTLS.enable=true \ --set mTLS.configMapName=api-server-mtls
  Admission Controllerコントローラーは、監査スキャナーコンポーネントが使用するためのクライアント証明書を作成します。証明書は必要に応じてコントローラーによって自動的にローテーションされます。