Container Service for Kubernetes：[非推奨] Pod セキュリティポリシーの使用 - Container Service for Kubernetes

警告

Kubernetes 1.25 より前のバージョンを実行している ACK クラスターにのみ適用されます。Kubernetes 1.25 以降を実行しているクラスターの場合は、代わりに Pod Security Admission を使用してください。PSP から移行するには、「Pod セキュリティポリシーから組み込みのPodSecurityアドミッションコントローラーへの移行」をご参照ください。

Pod セキュリティポリシー (PSP) アドミッションコントローラーは、定義したルールに基づいて Pod の作成および更新リクエストを検証します。リクエストがルールに一致しない場合、システムはリクエストを拒否し、エラーを返します。このトピックでは、Container Service for Kubernetes (ACK) で Pod セキュリティポリシーを使用する方法について説明します。

前提条件

次のものがあることを確認してください：

1.25 より前のバージョンの Kubernetes クラスターが作成されていること。
kubectl がクラスターに接続するように設定されていること。

デフォルトの ACK Pod セキュリティポリシー

Kubernetes 1.16.6 を実行する標準の ACK 専用クラスターおよびマネージドクラスターでは、PSP アドミッションコントローラーがデフォルトで有効になっており、ack.privileged という名前のポリシーが事前設定されています。

ack.privileged は、認証されたすべてのユーザーに完全かつ無制限のアクセスを付与します。これは、PSP アドミッションコントローラーを無効にすることに相当します。ワークロードはすぐに実行できますが、より厳格なポリシーを適用する場合は、このベースラインを置き換えてください。

デフォルトのポリシーを確認します：

kubectl get psp ack.privileged

期待される出力：

NAME             PRIV   CAPS   SELINUX    RUNASUSER   FSGROUP    SUPGROUP   READONLYROOTFS   VOLUMES
 ack.privileged   true   *      RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            *

詳細については、次のコマンドを実行します：

kubectl describe psp ack.privileged

期待される出力：

Name:  ack.privileged

設定：
  Allow Privileged:                       true
  Allow Privilege Escalation:             true
  Default Add Capabilities:               <none>
  Required Drop Capabilities:             <none>
  Allowed Capabilities:                   *
  Allowed Volume Types:                   *
  Allow Host Network:                     true
  Allow Host Ports:                       0-65535
  Allow Host PID:                         true
  Allow Host IPC:                         true
  Read Only Root Filesystem:              false
  SELinux Context Strategy: RunAsAny
    User:                                 <none>
    Role:                                 <none>
    Type:                                 <none>
    Level:                                <none>
  Run As User Strategy: RunAsAny
    Ranges:                               <none>
  FSGroup Strategy: RunAsAny
    Ranges:                               <none>
  Supplemental Groups Strategy: RunAsAny
    Ranges:                               <none>

デフォルトのポリシー、ClusterRole、および ClusterRoleBinding の完全な YAML を表示します。

---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: ack.privileged
  annotations:
    kubernetes.io/description: 'privileged は、PodSecurityPolicy コントローラーが有効になっていない場合と同様に、Pod の機能への完全で無制限のアクセスを許可します。'
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
  labels:
    kubernetes.io/cluster-service: "true"
    ack.alicloud.com/component: pod-security-policy
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
  readOnlyRootFilesystem: false

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ack:podsecuritypolicy:privileged
  labels:
    kubernetes.io/cluster-service: "true"
    ack.alicloud.com/component: pod-security-policy
rules:
- apiGroups:
  - policy
  resourceNames:
  - ack.privileged
  resources:
  - podsecuritypolicies
  verbs:
  - use

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ack:podsecuritypolicy:authenticated
  annotations:
    kubernetes.io/description: 'すべての認証済みユーザーに特権 Pod の作成を許可します。'
  labels:
    kubernetes.io/cluster-service: "true"
    ack.alicloud.com/component: pod-security-policy
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ack:podsecuritypolicy:privileged
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: system:authenticated

カスタム Pod セキュリティポリシーの適用

より厳格なポリシーを適用するには、デフォルトの ClusterRoleBinding を削除して、ack.privileged がすべての認証済みユーザーに適用されないようにします。すべての Pod の作成がロックアウトされるのを防ぐため、この操作は 2 段階で実行してください。

重要

ack.privileged ポリシーまたは ack:podsecuritypolicy:privileged ClusterRole は、削除または変更しないでください。これらのリソースは、ACK クラスターが機能するために必要です。削除するのは、ClusterRoleBinding (ack:podsecuritypolicy:authenticated) のみです。

ステージ 1：カスタムポリシーと RBAC バインディングの作成

デフォルトの ClusterRoleBinding を削除する前に、カスタム Pod セキュリティポリシーを作成してバインドします。そうしないと、ユーザー、コントローラー、またはサービスアカウントは Pod を作成または更新できなくなります。

ステージ 2：デフォルトの ClusterRoleBinding の削除

カスタムポリシーとその RBAC バインディングを配置した後、デフォルトの ClusterRoleBinding を削除します：

デフォルトの ClusterRoleBinding を削除するコマンドは次のとおりです。

cat <<EOF | kubectl delete -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ack:podsecuritypolicy:authenticated
  annotations:
    kubernetes.io/description: 'すべての認証済みユーザーに特権 Pod の作成を許可します。'
  labels:
    kubernetes.io/cluster-service: "true"
    ack.alicloud.com/component: pod-security-policy
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ack:podsecuritypolicy:privileged
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: system:authenticated
EOF

デフォルトの Pod セキュリティポリシーの復元

デフォルトの ack.privileged ポリシーまたはその ClusterRoleBinding が誤って削除された場合は、復元してください。

デフォルトのポリシーとその RBAC バインディングを復元するコマンドは次のとおりです。

cat <<EOF | kubectl apply -f -
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: ack.privileged
  annotations:
    kubernetes.io/description: 'privileged は、PodSecurityPolicy コントローラーが有効になっていない場合と同様に、Pod の機能への完全で無制限のアクセスを許可します。'
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
  labels:
    kubernetes.io/cluster-service: "true"
    ack.alicloud.com/component: pod-security-policy
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
  readOnlyRootFilesystem: false

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ack:podsecuritypolicy:privileged
  labels:
    kubernetes.io/cluster-service: "true"
    ack.alicloud.com/component: pod-security-policy
rules:
- apiGroups:
  - policy
  resourceNames:
  - ack.privileged
  resources:
  - podsecuritypolicies
  verbs:
  - use

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ack:podsecuritypolicy:authenticated
  annotations:
    kubernetes.io/description: 'すべての認証済みユーザーに特権 Pod の作成を許可します。'
  labels:
    kubernetes.io/cluster-service: "true"
    ack.alicloud.com/component: pod-security-policy
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ack:podsecuritypolicy:privileged
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: system:authenticated
EOF

よくある質問

「no providers available to validate pod request」というエラーで Pod の作成が失敗する

エラーの全文は no providers available to validate pod request または unable to validate against any pod security policy です。このエラーは、ack.privileged が誤って削除された場合に発生します。

「デフォルトの Pod セキュリティポリシーの復元」をご参照ください。

「Forbidden: unsafe sysctl」というエラーで Pod の作成が失敗する

完全なエラーは次のようになります：

PodSecurityPolicy: unable to admit pod: [pod.spec.securityContext.sysctls[0]: Forbidden: unsafe sysctl "***" is not allowed]

クラスターは、デフォルトでは安全でない sysctl パラメーターを許可しません。特定のワークロードにこの権限を付与するには、プリセットの ack.privileged ポリシーや、名前が ack:podsecuritypolicy: で始まるリソースは変更せず、新しい Pod セキュリティポリシーを作成してください。

警告

これらのプリセットリソースを変更または削除しないでください。ACK クラスターは、正常な運用のためにこれらのリソースに依存しています。不正な変更は、クラスターの機能を損なうか、自動リセットをトリガーする可能性があります：

Pod セキュリティポリシー ack.privileged
名前が ack:podsecuritypolicy: で始まる Role、ClusterRole、RoleBinding、および ClusterRoleBinding

ステップ 1：安全でない sysctl パラメーターを許可する Pod セキュリティポリシーの作成

以下の内容で unsafe-sysctl-psp.yaml を作成します。必要に応じて allowedUnsafeSysctls を調整します。

---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp.allow-unsafe-sysctls
spec:
  allowedUnsafeSysctls:
  - '*'
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
  readOnlyRootFilesystem: false

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: podsecuritypolicy:allow-unsafe-sysctls
rules:
- apiGroups:
  - policy
  resourceNames:
  - psp.allow-unsafe-sysctls
  resources:
  - podsecuritypolicies
  verbs:
  - use

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: podsecuritypolicy:allow-unsafe-sysctls:authenticated
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: podsecuritypolicy:allow-unsafe-sysctls
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: system:authenticated

ステップ 2：ポリシーの適用

kubectl create -f unsafe-sysctl-psp.yaml

期待される出力：

podsecuritypolicy.policy/psp.allow-unsafe-sysctls created
clusterrole.rbac.authorization.k8s.io/podsecuritypolicy:allow-unsafe-sysctls created
clusterrolebinding.rbac.authorization.k8s.io/podsecuritypolicy:allow-unsafe-sysctls:authenticated created

ステップ 3：安全でない sysctl パラメーターを許可するためのノードプールの設定

ワークロードのノードプールの kubelet パラメーターをカスタマイズします。詳細については、「サポートされているカスタムkubeletパラメーター」をご参照ください。

ステップ 4：テスト Pod での検証

安全でない sysctl パラメーターを使用してテストポッドをデプロイします。 kubelet が特定のノード (たとえば、ノードプール) のみで設定されている場合は、nodeSelector を追加して、ポッドをそれらのノードにスケジューリングします。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
spec:
#  nodeSelector:
#    alibabacloud.com/nodepool-id: npd912756***  # ターゲットノードプール ID に置き換えます
  securityContext:
    sysctls:
    - name: net.ipv4.tcp_syncookies
      value: "1"
    - name: net.core.somaxconn
      value: "1024"
    - name: net.ipv4.tcp_max_syn_backlog
      value: "65536"
  containers:
  - name: test
    image: nginx
EOF

期待される出力：

pod/sysctl-example created

SysctlForbidden イベントは、スケジュールされたノードの kubelet が安全でない sysctl パラメーターを許可しないことを意味します。Pod の nodeSelector を調整して、正しい kubelet 設定のノードをターゲットにしてください。

参考資料

Pod セキュリティポリシー