Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Container Service for Kubernetes:[Deprecated] Use pod security policies

Dernière mise à jour :Sep 12, 2026
Avertissement

S'applique uniquement aux clusters ACK exécutant une version de Kubernetes antérieure à la 1,26. Pour les clusters exécutant Kubernetes 1.25 ou une version ultérieure, utilisez Pod Security Admission à la place. Pour migrer depuis PSP, consultez Migrate from PodSecurityPolicy to the built-in PodSecurity admission controller.

Le contrôleur d'admission Pod Security Policy (PSP) valide les requêtes de création et de mise à jour des pods par rapport aux règles que vous définissez. Si une requête ne correspond pas aux règles, le système la rejette et renvoie une erreur. Cette rubrique décrit comment utiliser les politiques de sécurité des pods dans Container Service for Kubernetes (ACK).

Prérequis

Assurez-vous d'avoir :

Politique de sécurité des pods ACK par défaut

Les clusters ACK dédiés et gérés standard exécutant Kubernetes 1.16.6 activent le contrôleur d'admission PSP par défaut. Une politique nommée ack.privileged est préconfigurée.

ack.privileged accorde à tous les utilisateurs authentifiés un accès complet et illimité, ce qui équivaut à désactiver le contrôleur d'admission PSP. Les charges de travail s'exécutent dès le déploiement ; remplacez cette configuration de base lorsque vous appliquez des politiques plus strictes.

Inspectez la politique par défaut :

kubectl get psp ack.privileged

Sortie attendue :

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

Pour obtenir tous les détails :

kubectl describe psp ack.privileged

Sortie attendue :

Name:  ack.privileged

Settings:
  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>

Consultez le fichier YAML complet pour la politique par défaut, ClusterRole et ClusterRoleBinding

---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: ack.privileged
  annotations:
    kubernetes.io/description: 'privileged allows full unrestricted access to
      pod features, as if the PodSecurityPolicy controller was not enabled.'
    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: 'Allow all authenticated users to create privileged pods.'
  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

Appliquer une politique de sécurité des pods personnalisée

Pour appliquer une politique plus stricte, supprimez le ClusterRoleBinding par défaut afin que ack.privileged ne s'applique plus à tous les utilisateurs authentifiés. Procédez en deux étapes pour éviter de bloquer toute création de pod.

Important

Ne supprimez ni ne modifiez jamais la politique ack.privileged ou le ClusterRole ack:podsecuritypolicy:privileged . Ces ressources sont nécessaires au bon fonctionnement du cluster ACK. Seul le ClusterRoleBinding (ack:podsecuritypolicy:authenticated) doit être supprimé.

Étape 1 : Créez votre politique personnalisée et la liaison RBAC

Créez et liez une politique de sécurité des pods personnalisée avant de supprimer le ClusterRoleBinding par défaut. Sinon, aucun utilisateur, contrôleur ou compte de service ne pourra créer ou mettre à jour des pods.

Étape 2 : Supprimez le ClusterRoleBinding par défaut

Une fois votre politique personnalisée et sa liaison RBAC en place, supprimez le ClusterRoleBinding par défaut :

Consultez la commande pour supprimer le ClusterRoleBinding par défaut

cat <<EOF | kubectl delete -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ack:podsecuritypolicy:authenticated
  annotations:
    kubernetes.io/description: 'Allow all authenticated users to create privileged pods.'
  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

Restaurer la politique de sécurité des pods par défaut

Si la politique ack.privileged par défaut ou son ClusterRoleBinding est accidentellement supprimé, restaurez-le.

Consultez la commande pour restaurer la politique par défaut et sa liaison RBAC

cat <<EOF | kubectl apply -f -
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: ack.privileged
  annotations:
    kubernetes.io/description: 'privileged allows full unrestricted access to
      pod features, as if the PodSecurityPolicy controller was not enabled.'
    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: 'Allow all authenticated users to create privileged pods.'
  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

FAQ

La création du pod échoue avec l'erreur « no providers available to validate pod request »

L'erreur complète est no providers available to validate pod request ou unable to validate against any pod security policy. Cela se produit lorsque ack.privileged est accidentellement supprimé.

Consultez la section Restaurer la politique de sécurité des pods par défaut.

La création du pod échoue avec l'erreur « Forbidden: unsafe sysctl »

L'erreur complète ressemble à ceci :

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

Par défaut, les clusters n'autorisent pas les paramètres sysctl non sécurisés. Pour accorder cette autorisation à une charge de travail spécifique, créez une nouvelle politique de sécurité des pods — ne modifiez pas la politique prédéfinie ack.privileged ni aucune ressource dont le nom commence par ack:podsecuritypolicy:.

Avertissement

Ne modifiez ni ne supprimez ces ressources prédéfinies. Le cluster ACK dépend de ces ressources pour son fonctionnement normal. Des modifications non autorisées peuvent interrompre les fonctionnalités du cluster ou déclencher des réinitialisations automatiques :

  • La politique de sécurité des pods nommée ack.privileged

  • Les rôles, ClusterRoles, RoleBindings et ClusterRoleBindings dont le nom commence par ack:podsecuritypolicy:

Étape 1 : Créez une politique de sécurité des pods qui autorise les paramètres sysctl non sécurisés.

Créez le fichier unsafe-sysctl-psp.yaml avec le contenu suivant. Ajustez allowedUnsafeSysctls selon vos besoins.

---
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

Étape 2 : Appliquez la politique.

kubectl create -f unsafe-sysctl-psp.yaml

Sortie attendue :

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

Étape 3 : Configurez le pool de nœuds pour autoriser les paramètres sysctl non sécurisés.

Personnalisez les paramètres kubelet pour le pool de nœuds de la charge de travail. Consultez la section Supported custom kubelet parameters.

Étape 4 : Vérifiez avec un pod de test.

Déployez un pod de test avec des paramètres sysctl non sécurisés. Si le kubelet est configuré uniquement sur des nœuds spécifiques (par exemple, un pool de nœuds), ajoutez un nodeSelector pour planifier le pod sur ces nœuds.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
spec:
#  nodeSelector:
#    alibabacloud.com/nodepool-id: npd912756***  # Replace with the target node pool 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

Sortie attendue :

pod/sysctl-example created

Un événement SysctlForbidden signifie que le kubelet sur le nœud planifié n'autorise pas les paramètres sysctl non sécurisés. Ajustez le nodeSelector du pod pour cibler un nœud disposant de la configuration kubelet appropriée.

Références