Sécurité du pod - Amazon EKS
Fonctionnalités de LinuxSolutions de sécurité pour les podsRecommandationsOutils et ressources

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sécurité du pod

La spécification du module inclut une variété d'attributs différents qui peuvent renforcer ou affaiblir votre posture de sécurité globale. En tant que praticien de Kubernetes, votre principale préoccupation devrait être d'empêcher un processus exécuté dans un conteneur d'échapper aux limites d'isolation du runtime du conteneur et d'accéder à l'hôte sous-jacent.

Fonctionnalités de Linux

Les processus exécutés dans un conteneur s'exécutent par défaut dans le contexte de l'utilisateur root [Linux]. Bien que les actions du root au sein d'un conteneur soient partiellement limitées par l'ensemble des fonctionnalités Linux que le moteur d'exécution du conteneur attribue aux conteneurs, ces privilèges par défaut peuvent permettre à un attaquant d'augmenter ses privilèges et/ou d'accéder à des informations sensibles liées à l'hôte, notamment Secrets et. ConfigMaps Vous trouverez ci-dessous une liste des fonctionnalités par défaut attribuées aux conteneurs. Pour plus d'informations sur chaque fonctionnalité, consultez http://man7. org/linux/man-pages/man7/capabilities7.html.

CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETUID, CAP_SETFCAP, CAP_SETPCAP, CAP_SYS_CHROOT

EC2 et les pods Fargate se voient attribuer les fonctionnalités susmentionnées par défaut. De plus, les fonctionnalités Linux ne peuvent être supprimées que depuis les pods Fargate.

Les pods exécutés en tant que privilèges héritent de toutes les fonctionnalités Linux associées au root sur l'hôte. Cela doit être évité dans la mesure du possible.

Autorisation du nœud

Tous les nœuds de travail Kubernetes utilisent un mode d'autorisation appelé Node Authorization. L'autorisation de nœud autorise toutes les demandes d'API provenant du kubelet et permet aux nœuds d'effectuer les actions suivantes :

Opérations de lecture :

  • services

  • points de terminaison

  • nœuds

  • gousses

  • secrets, configmaps, réclamations de volumes persistants et volumes persistants liés aux pods liés au nœud du kubelet

Opérations d'écriture :

  • nœuds et état des nœuds (activez le plugin NodeRestriction d'admission pour limiter un kubelet à modifier son propre nœud)

  • pods et statut des pods (activez le plugin NodeRestriction d'admission pour limiter un kubelet afin de modifier les pods liés à lui-même)

  • événements

Opérations liées à l'authentification :

  • Accès en lecture/écriture à l'API CertificateSigningRequest (CSR) pour le démarrage du protocole TLS

  • la capacité de créer TokenReview et de SubjectAccessReview déléguer authentication/authorization des contrôles

EKS utilise le contrôleur d'admission par restriction de nœud qui permet uniquement au nœud de modifier un ensemble limité d'attributs de nœud et d'objets de pod liés au nœud. Néanmoins, un attaquant parvenant à accéder à l'hôte sera toujours en mesure de glaner des informations sensibles sur l'environnement à partir de l'API Kubernetes, ce qui pourrait lui permettre de se déplacer latéralement au sein du cluster.

Solutions de sécurité pour les pods

Politique de sécurité des pods (PSP)

Dans le passé, les ressources de la politique de sécurité des pods (PSP) étaient utilisées pour spécifier un ensemble d'exigences auxquelles les pods devaient répondre avant de pouvoir être créés. Depuis la version 1.21 de Kubernetes, les PSP sont devenues obsolètes. Leur suppression est prévue dans la version 1.25 de Kubernetes.

Important

PSPs sont obsolètes dans la version 1.21 de Kubernetes. Vous aurez jusqu'à la version 1.25, soit environ 2 ans, pour passer à une alternative. Ce document explique les raisons de cette dépréciation.

Migration vers une nouvelle solution de sécurité des pods

Comme PSPs ils ont été supprimés à partir de Kubernetes v1.25, les administrateurs et les opérateurs de clusters doivent remplacer ces contrôles de sécurité. Deux solutions peuvent répondre à ce besoin :

Les solutions PAC et PSS peuvent coexister avec la PSP ; elles peuvent être utilisées dans des clusters avant le retrait de la PSP. Cela facilite l'adoption lors de la migration depuis PSP. Veuillez consulter ce document lorsque vous envisagez de migrer de PSP vers PSS.

Kyverno, l'une des solutions PAC décrites ci-dessous, propose des conseils spécifiques décrits dans un article de blog lors de la migration PSPs vers sa solution, notamment des politiques analogues, des comparaisons de fonctionnalités et une procédure de migration. Des informations et des conseils supplémentaires sur la migration vers Kyverno en ce qui concerne le Pod Security Admission (PSA) ont été publiés sur le blog AWS ici.

Policy-as-code (PAC)

Policy-as-code Les solutions (PAC) fournissent des garde-fous pour guider les utilisateurs du cluster et empêcher les comportements indésirables, grâce à des contrôles prescrits et automatisés. Le PAC utilise les contrôleurs d'admission dynamiques Kubernetes pour intercepter le flux de demandes du serveur d'API Kubernetes, via un appel webhook, et pour muter et valider les charges utiles des demandes, sur la base de politiques écrites et stockées sous forme de code. La mutation et la validation ont lieu avant que la demande du serveur d'API n'entraîne une modification du cluster. Les solutions PAC utilisent des politiques pour faire correspondre et agir sur les charges utiles des demandes du serveur d'API, en fonction de la taxonomie et des valeurs.

Plusieurs solutions PAC open source sont disponibles pour Kubernetes. Ces solutions ne font pas partie du projet Kubernetes ; elles proviennent de l'écosystème Kubernetes. Certaines solutions PAC sont répertoriées ci-dessous.

Pour plus d'informations sur les solutions PAC et sur la manière de vous aider à sélectionner la solution adaptée à vos besoins, consultez les liens ci-dessous.

Normes de sécurité des pods (PSS) et entrée de sécurité des pods (PSA)

En réponse à la dépréciation de la PSP et au besoin permanent de contrôler la sécurité des pods out-of-the-box, le Kubernetes Auth Special Interest Group a créé les normes de sécurité des pods (PSS) et Pod Security Admission (PSA) à l'aide d'une solution Kubernetes intégrée. L'effort du PSA inclut un projet de webhook pour le contrôleur d'admission qui implémente les contrôles définis dans le PSS. Cette approche du contrôleur d'admission ressemble à celle utilisée dans les solutions PAC.

Selon la documentation de Kubernetes, le PSS « définit trois politiques différentes pour couvrir largement le spectre de la sécurité. Ces politiques sont cumulatives et vont de très permissives à très restrictives. `»

Ces politiques sont définies comme suit :

  • Privilégié : politique illimitée (non sécurisée), fournissant le niveau d'autorisations le plus large possible. Cette politique autorise les augmentations de privilèges connues. C'est l'absence de politique. Cela convient aux applications telles que les agents de journalisation CNIs, les pilotes de stockage et les autres applications à l'échelle du système qui nécessitent un accès privilégié.

  • Base de référence : politique minimalement restrictive qui empêche les augmentations de privilèges connues. Permet la configuration par défaut (spécifiée au minimum) du pod. La politique de base interdit l'utilisation de HostNetwork, HostPID, HostPC, HostPath, HostPort, l'impossibilité d'ajouter des fonctionnalités Linux, ainsi que plusieurs autres restrictions.

  • Restreint : politique très restreinte, conforme aux meilleures pratiques actuelles en matière de renforcement des pods. Cette politique hérite de la ligne de base et ajoute des restrictions supplémentaires, telles que l'impossibilité de s'exécuter en tant que root ou en tant que groupe root. Les politiques restreintes peuvent avoir un impact sur le fonctionnement d'une application. Ils sont principalement destinés à exécuter des applications critiques en matière de sécurité.

Ces politiques définissent des profils pour l'exécution des pods, organisés en trois niveaux d'accès privilégié ou restreint.

Pour implémenter les contrôles définis par le PSS, le PSA fonctionne selon trois modes :

  • appliquer : les violations des politiques entraîneront le rejet du pod.

  • audit : les violations des politiques déclencheront l'ajout d'une annotation d'audit à l'événement enregistré dans le journal d'audit, mais elles sont par ailleurs autorisées.

  • avertissement : les violations des politiques déclencheront un avertissement destiné à l'utilisateur, mais elles sont autorisées dans le cas contraire.

Ces modes et les niveaux de profil (restriction) sont configurés au niveau de l'espace de noms Kubernetes, à l'aide d'étiquettes, comme indiqué dans l'exemple ci-dessous.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: restricted

Lorsqu'ils sont utilisés indépendamment, ces modes de fonctionnement ont des réponses différentes qui se traduisent par des expériences utilisateur différentes. Le mode d'application empêchera la création de pods si les PodSpecs respectifs enfreignent le niveau de restriction configuré. Toutefois, dans ce mode, les objets Kubernetes autres que des pods qui créent des pods, tels que les déploiements, ne seront pas empêchés d'être appliqués au cluster, même si le PodSpec qu'ils contiennent viole le PSS appliqué. Dans ce cas, le déploiement sera appliqué, tandis que le ou les pods ne pourront pas être appliqués.

Il s'agit d'une expérience utilisateur difficile, car rien n'indique dans l'immédiat que l'objet de déploiement correctement appliqué contredit l'échec de la création du pod. Les PodSpecs incriminés ne créeront pas de pods. L'inspection de la ressource de déploiement avec kubectl get deploy <DEPLOYMENT_NAME> -oyaml exposera le message provenant de l'.status.conditionsélément pod (s) défaillant, comme indiqué ci-dessous.

...
status:
  conditions:
    - lastTransitionTime: "2022-01-20T01:02:08Z"
      lastUpdateTime: "2022-01-20T01:02:08Z"
      message: 'pods "test-688f68dc87-tw587" is forbidden: violates PodSecurity "restricted:latest":
        allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false),
        unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]),
        runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true),
        seccompProfile (pod or container "test" must set securityContext.seccompProfile.type
        to "RuntimeDefault" or "Localhost")'
      reason: FailedCreate
      status: "True"
      type: ReplicaFailure
...

Dans les modes audit et avertissement, les restrictions relatives aux modules n'empêchent pas la création et le démarrage des modules non conformes. Toutefois, dans ces modes, les annotations d'audit sur les événements du journal d'audit du serveur d'API et les avertissements adressés aux clients du serveur d'API, tels que kubectl, sont déclenchés, respectivement, lorsque les pods, ainsi que les objets qui créent des pods, contiennent des PodSpecs présentant des violations. Un message kubectl d'avertissement est affiché ci-dessous.

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/test created

Les modes d'audit et d'avertissement du PSA sont utiles lors de l'introduction du PSS sans avoir d'impact négatif sur les opérations du cluster.

Les modes de fonctionnement du PSA ne s'excluent pas mutuellement et peuvent être utilisés de manière cumulative. Comme indiqué ci-dessous, les modes multiples peuvent être configurés dans un seul espace de noms.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Dans l'exemple ci-dessus, les avertissements et les annotations d'audit faciles à utiliser sont fournis lors de l'application des déploiements, tandis que l'application des violations est également fournie au niveau du module. En fait, plusieurs étiquettes PSA peuvent utiliser différents niveaux de profil, comme indiqué ci-dessous.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted

Dans l'exemple ci-dessus, le PSA est configuré pour autoriser la création de tous les pods qui répondent au niveau de profil de référence, puis pour avertir les pods (et les objets qui créent des pods) qui enfreignent le niveau de profil restreint. Il s'agit d'une approche utile pour déterminer les impacts possibles lors du passage de profils de référence à des profils restreints.

Pods existants

Si un espace de noms contenant des pods existants est modifié pour utiliser un profil PSS plus restrictif, les modes audit et avertissement produiront les messages appropriés ; toutefois, le mode Enforce ne supprimera pas les pods. Les messages d'avertissement sont affichés ci-dessous.

Warning: existing pods in namespace "policy-test" violate the new PodSecurity enforce level "restricted:latest"
Warning: test-688f68dc87-htm8x: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/policy-test configured

Dérogations

PSA utilise des exemptions pour exclure l'application de violations à l'encontre des pods qui auraient autrement été appliquées. Ces exemptions sont répertoriées ci-dessous.

  • Noms d'utilisateur : les demandes des utilisateurs dont le nom d'utilisateur authentifié (ou usurpé) est exempté sont ignorées.

  • RuntimeClassNames: les pods et les ressources de charge de travail spécifiant un nom de classe d'exécution exempté sont ignorés.

  • Espaces de noms : les pods et les ressources de charge de travail dans un espace de noms exempté sont ignorés.

Ces exemptions sont appliquées de manière statique dans la configuration du contrôleur d'admission PSA dans le cadre de la configuration du serveur d'API.

Dans l'implémentation de Validating Webhook, les exemptions peuvent être configurées au sein d'une ConfigMapressource Kubernetes montée sous forme de volume dans le conteneur. pod-security-webhook

apiVersion: v1
kind: ConfigMap
metadata:
  name: pod-security-webhook
  namespace: pod-security-webhook
data:
  podsecurityconfiguration.yaml: |
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "restricted"
      enforce-version: "latest"
      audit: "restricted"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: ["kube-system","policy-test1"]

Comme indiqué dans le ConfigMap YAML ci-dessus, le niveau PSS par défaut à l'échelle du cluster a été défini comme restreint pour tous les modes PSA, audit, application et avertissement. Cela affecte tous les espaces de noms, à l'exception de ceux exemptés :. namespaces: ["kube-system","policy-test1"] De plus, dans la ValidatingWebhookConfigurationressource présentée ci-dessous, l'espace de pod-security-webhooknoms est également exempté du PSS configuré.

...
webhooks:
  # Audit annotations will be prefixed with this name
  - name: "pod-security-webhook.kubernetes.io"
    # Fail-closed admission webhooks can present operational challenges.
    # You may want to consider using a failure policy of Ignore, but should
    # consider the security tradeoffs.
    failurePolicy: Fail
    namespaceSelector:
      # Exempt the webhook itself to avoid a circular dependency.
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["pod-security-webhook"]
...
Important

Pod Security Admissions est devenue stable dans Kubernetes v1.25. Si vous vouliez utiliser la fonction Pod Security Admission avant qu'elle ne soit activée par défaut, vous deviez installer le contrôleur d'admission dynamique (webhook mutant). Les instructions d'installation et de configuration du webhook se trouvent ici.

Choisir entre les normes de sécurité policy-as-code et celles des pods

Les Pod Security Standards (PSS) ont été développés pour remplacer la Pod Security Policy (PSP), en fournissant une solution intégrée à Kubernetes et ne nécessitant pas de solutions issues de l'écosystème Kubernetes. Cela étant dit, les solutions policy-as-code (PAC) sont considérablement plus flexibles.

La liste suivante des avantages et des inconvénients est conçue pour vous aider à prendre une décision plus éclairée concernant la solution de sécurité de votre pod.

Policy-as-code (par rapport aux normes de sécurité des pods)

Avantages :

  • Plus flexible et plus granulaire (jusqu'aux attributs des ressources si nécessaire)

  • Non seulement axé sur les pods, il peut être utilisé contre différentes ressources et actions

  • Pas seulement appliqué au niveau de l'espace de noms

  • Plus mature que les normes de sécurité du Pod

  • Les décisions peuvent être basées sur n'importe quel élément de la charge utile des demandes du serveur d'API, ainsi que sur les ressources du cluster existantes et les données externes (en fonction de la solution)

  • Prend en charge les requêtes mutantes du serveur d'API avant validation (dépend de la solution)

  • Peut générer des politiques complémentaires et des ressources Kubernetes (en fonction de la solution). À partir des politiques des modules, Kyverno peut générer automatiquement des politiques pour les contrôleurs de niveau supérieur, tels que les déploiements. Kyverno peut également générer des ressources Kubernetes supplémentaires « lorsqu'une nouvelle ressource est créée ou lorsque la source est mise à jour` » en utilisant Generate Rules.)

  • Peut être utilisé pour passer à gauche, dans les pipelines CICD, avant de passer des appels au serveur d'API Kubernetes (selon la solution)

  • Peut être utilisé pour mettre en œuvre des comportements qui ne sont pas nécessairement liés à la sécurité, tels que les meilleures pratiques, les normes organisationnelles, etc.

  • Peut être utilisé dans des cas d'utilisation autres que Kubernetes (selon la solution)

  • Grâce à la flexibilité, l'expérience utilisateur peut être adaptée aux besoins des utilisateurs

Inconvénients :

  • Non intégré à Kubernetes

  • Plus complexe à apprendre, à configurer et à prendre en charge

  • La création de politiques peut nécessiter de nouvelles skills/languages/capabilities

Accès sécurisé au pod (par rapport à policy-as-code)

Avantages :

  • Intégré à Kubernetes

  • Plus simple à configurer

  • Aucune nouvelle langue à utiliser ni aucune nouvelle politique à rédiger

  • Si le niveau d'admission par défaut du cluster est configuré sur privilégié, les libellés d'espace de noms peuvent être utilisés pour ajouter des espaces de noms aux profils de sécurité du module.

Inconvénients :

  • Pas aussi souple ou granuleux que policy-as-code

  • Seulement 3 niveaux de restrictions

  • Principalement axé sur les pods

Récapitulatif

Si vous ne disposez pas actuellement d'une solution de sécurité pour les pods, autre que la PSP, et que la posture de sécurité requise correspond au modèle défini dans les normes de sécurité des pods (PSS), il est peut-être plus facile d'adopter le PSS au lieu d'une solution. policy-as-code Toutefois, si la posture de sécurité de votre module ne correspond pas au modèle PSS, ou si vous envisagez d'ajouter des contrôles supplémentaires, au-delà de ceux définis par le PSS, une policy-as-code solution semble mieux adaptée.

Recommandations

Utilisez plusieurs modes Pod Security Admission (PSA) pour une meilleure expérience utilisateur

Comme indiqué précédemment, le mode d'application du PSA empêche l'application des pods présentant des violations du PSS, mais n'arrête pas les contrôleurs de niveau supérieur, tels que les déploiements. En fait, le déploiement sera appliqué avec succès sans aucune indication que les pods n'ont pas été appliqués. Bien que vous puissiez utiliser kubectl pour inspecter l'objet de déploiement et découvrir le message du PSA indiquant que les pods ont échoué, l'expérience utilisateur pourrait être meilleure. Pour améliorer l'expérience utilisateur, plusieurs modes PSA (audit, appliquer, avertir) doivent être utilisés.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Dans l'exemple ci-dessus, avec le mode d'application défini, lorsqu'un manifeste de déploiement contenant des violations du PSS dans le PodSpec correspondant est tenté d'être appliqué au serveur d'API Kubernetes, le déploiement sera correctement appliqué, mais pas les pods. Et comme les modes audit et avertissement sont également activés, le client du serveur d'API recevra un message d'avertissement et l'événement du journal d'audit du serveur d'API sera également annoté par un message.

Restreindre les conteneurs qui peuvent fonctionner en tant que privilégiés

Comme indiqué, les conteneurs qui s'exécutent en tant que privilèges héritent de toutes les fonctionnalités Linux attribuées au root sur l'hôte. Les conteneurs ont rarement besoin de ce type de privilèges pour fonctionner correctement. Plusieurs méthodes peuvent être utilisées pour restreindre les autorisations et les capacités des conteneurs.

Important

Fargate est un type de lancement qui vous permet d'exécuter des conteneurs « sans serveur » dans lesquels les conteneurs d'un pod sont exécutés sur une infrastructure gérée par AWS. Avec Fargate, vous ne pouvez pas exécuter un conteneur privilégié ni configurer votre pod pour utiliser HostNetwork ou HostPort.

Ne pas exécuter de processus dans des conteneurs en tant qu'utilisateur root

Tous les conteneurs s'exécutent en tant que root par défaut. Cela peut être problématique si un attaquant parvient à exploiter une vulnérabilité de l'application et à obtenir un accès shell au conteneur en cours d'exécution. Vous pouvez atténuer ce risque de différentes manières. Tout d'abord, en retirant la coque de l'image du conteneur. Ensuite, ajoutez la directive USER à votre Dockerfile ou exécutez les conteneurs du pod en tant qu'utilisateur non root. Le Kubernetes PodSpec inclut un ensemble de champs, sousspec.securityContext, qui vous permettent de spécifier le and/or groupe d'utilisateurs sous lequel exécuter votre application. Ces champs sont runAsUser runAsGroup respectivement.

Pour renforcer l'utilisation duspec.securityContext, et de ses éléments associés, dans le cadre de Kubernetes, PodSpec policy-as-code ou Pod Security Standards peuvent être ajoutés aux clusters. Ces solutions vous permettent d'écrire et/ou d'utiliser des politiques ou des profils capables de valider les charges utiles des demandes du serveur d'API Kubernetes entrantes, avant qu'elles ne soient conservées dans etcd. En outre, policy-as-code les solutions peuvent modifier les demandes entrantes et, dans certains cas, générer de nouvelles demandes.

N'exécutez jamais Docker dans Docker et ne montez jamais le socket dans le conteneur

Bien que cela vous permette facilement d'accéder à build/run des images dans des conteneurs Docker, vous abandonnez essentiellement le contrôle total du nœud au profit du processus exécuté dans le conteneur. Si vous avez besoin de créer des images de conteneur sur Kubernetes, utilisez plutôt Kaniko, buildah ou un service de génération similaire. CodeBuild

Note

Les clusters Kubernetes utilisés pour le traitement CICD, tels que la création d'images de conteneurs, doivent être isolés des clusters exécutant des charges de travail plus généralisées.

Limitez l'utilisation de HostPath ou, si HostPath est nécessaire, limitez les préfixes pouvant être utilisés et configurez le volume en lecture seule

hostPathest un volume qui monte un répertoire depuis l'hôte directement vers le conteneur. Les capsules auront rarement besoin de ce type d'accès, mais si c'est le cas, vous devez être conscient des risques. Par défaut, les pods qui s'exécutent en tant que root auront un accès en écriture au système de fichiers exposé par HostPath. Cela pourrait permettre à un attaquant de modifier les paramètres du kubelet, de créer des liens symboliques vers des répertoires ou des fichiers qui ne sont pas directement exposés par HostPath, par exemple /etc/shadow, d'installer des clés ssh, de lire des secrets montés sur l'hôte et d'autres éléments malveillants. Pour atténuer les risques liés à HostPath, configurez le spec.containers.volumeMounts commereadOnly, par exemple :

volumeMounts:
- name: hostPath-volume
    readOnly: true
    mountPath: /host-path

Vous devez également utiliser policy-as-code des solutions pour restreindre les répertoires qui peuvent être utilisés par les hostPath volumes ou empêcher complètement hostPath leur utilisation. Vous pouvez utiliser les politiques de base ou de restriction des normes de sécurité du Pod pour empêcher l'utilisation dehostPath.

Pour plus d'informations sur les dangers de l'escalade des privilèges, consultez le blog de Seth Art, Bad Pods : Kubernetes Pod Privilege Escalation.

Définissez des demandes et des limites pour chaque conteneur afin d'éviter les contentions de ressources et les attaques DoS

Un pod sans demandes ni limites peut théoriquement consommer toutes les ressources disponibles sur un hôte. Lorsque des pods supplémentaires sont programmés sur un nœud, le nœud peut subir une pression sur le processeur ou la mémoire, ce qui peut entraîner l'arrêt du Kubelet ou l'expulsion des pods du nœud. Bien que vous ne puissiez pas empêcher que cela se produise complètement, la définition de demandes et de limites permet de minimiser la contention des ressources et d'atténuer les risques liés à des applications mal conçues qui consomment une quantité excessive de ressources.

Vous podSpec permet de spécifier les demandes et les limites du processeur et de la mémoire. Le processeur est considéré comme une ressource compressible car il peut être sursouscrit. La mémoire est incompressible, c'est-à-dire qu'elle ne peut pas être partagée entre plusieurs conteneurs.

Lorsque vous spécifiez des demandes de processeur ou de mémoire, vous désignez essentiellement la quantité de mémoire que les conteneurs sont sûrs d'obtenir. Kubernetes agrège les demandes de tous les conteneurs d'un pod afin de déterminer sur quel nœud planifier le pod. Si un conteneur dépasse la quantité de mémoire demandée, il peut être mis hors service en cas de pression de mémoire sur le nœud.

Les limites sont la quantité maximale de ressources de processeur et de mémoire qu'un conteneur est autorisé à consommer et correspondent directement à la memory.limit_in_bytes valeur du cgroup créé pour le conteneur. Un conteneur qui dépasse la limite de mémoire sera détruit par OOM. Si un conteneur dépasse sa limite de CPU, il sera limité.

Note

Lors de l'utilisation d'un conteneur, resources.limits il est fortement recommandé que l'utilisation des ressources du conteneur (alias Resource Footprints) soit basée sur les données et précise, sur la base de tests de charge. En l'absence d'une empreinte de ressources précise et fiable, le conteneur resources.limits peut être rembourré. Par exemple, il resources.limits.memory peut être augmenté de 20 à 30 % par rapport aux maximums observables, afin de tenir compte d'éventuelles inexactitudes dans les limites des ressources de mémoire.

Kubernetes utilise trois classes de qualité de service (QoS) pour hiérarchiser les charges de travail exécutées sur un nœud. Il s’agit des licences suivantes :

  • garanti

  • éclatable

  • meilleur effort

Si les limites et les demandes ne sont pas définies, le pod est configuré comme le meilleur effort (priorité la plus basse). Les pods Best-Effort sont les premiers à être détruits lorsque la mémoire est insuffisante. Si des limites sont définies pour tous les conteneurs du pod, ou si les demandes et les limites sont définies sur les mêmes valeurs et non égales à 0, le pod est configuré comme garanti (priorité la plus élevée). Les pods garantis ne seront pas détruits à moins qu'ils ne dépassent les limites de mémoire configurées. Si les limites et les demandes sont configurées avec des valeurs différentes et différentes de 0, ou si un conteneur du pod définit des limites et les autres non, ou si des limites sont définies pour différentes ressources, les pods sont configurés en mode rafale (priorité moyenne). Ces pods ont certaines garanties en matière de ressources, mais peuvent être détruits une fois qu'ils dépassent la mémoire demandée.

Important

Les demandes n'affectent pas la memory_limit_in_bytes valeur du cgroup du conteneur ; la limite du cgroup est définie en fonction de la quantité de mémoire disponible sur l'hôte. Néanmoins, si la valeur des requêtes est trop faible, le kubelet peut cibler le pod pour être arrêté par le kubelet si le nœud subit une pression de mémoire.

Classe Priorité Condition État de destruction

Garantie

le plus élevé

limite = demande ! = 0

Ne dépassez que les limites de mémoire

Éclatable

medium

limite ! = demande ! = 0

Peut être tué en cas de dépassement de la mémoire de demande

Meilleur effort

le plus bas

limite et demande non définies

Premier à être tué lorsque la mémoire est insuffisante

Pour plus d'informations sur la QoS des ressources, consultez la documentation de Kubernetes.

Vous pouvez forcer l'utilisation de demandes et de limites en définissant un quota de ressources sur un espace de noms ou en créant une plage de limites. Un quota de ressources vous permet de spécifier la quantité totale de ressources, par exemple le processeur et la RAM, allouées à un espace de noms. Lorsqu'il est appliqué à un espace de noms, il vous oblige à spécifier des demandes et des limites pour tous les conteneurs déployés dans cet espace de noms. En revanche, les plages de limites vous permettent de contrôler de manière plus précise l'allocation des ressources. Avec les plages limites, vous pouvez définir min/max les ressources du processeur et de la mémoire par pod ou par conteneur au sein d'un espace de noms. Vous pouvez également les utiliser pour définir les valeurs de demande/limite par défaut si aucune n'est fournie.

Policy-as-code les solutions peuvent être utilisées pour appliquer les demandes et les limites, ou même pour créer des quotas de ressources et des plages de limites lors de la création d'espaces de noms.

Ne pas autoriser l'escalade privilégiée

L'escalade privilégiée permet à un processus de modifier le contexte de sécurité dans lequel il s'exécute. Sudo en est un bon exemple, tout comme les binaires avec le bit SUID ou SGID. L'escalade privilégiée est essentiellement un moyen pour les utilisateurs d'exécuter un fichier avec les autorisations d'un autre utilisateur ou groupe. Vous pouvez empêcher un conteneur d'utiliser l'escalade privilégiée en policy-as-code implémentant une politique mutante qui définit allowPrivilegeEscalation false ou securityContext.allowPrivilegeEscalation en définissant lepodSpec. Policy-as-code les politiques peuvent également être utilisées pour empêcher les demandes du serveur d'API de réussir si des paramètres incorrects sont détectés. Les normes de sécurité des pods peuvent également être utilisées pour empêcher les pods d'utiliser l'escalade de privilèges.

Désactiver les montages de ServiceAccount jetons

Pour les pods qui n'ont pas besoin d'accéder à l'API Kubernetes, vous pouvez désactiver le montage automatique d'un ServiceAccount jeton sur une spécification de pod, ou pour tous les pods utilisant un jeton en particulier. ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-automount
spec:
  automountServiceAccountToken: false
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-no-automount
automountServiceAccountToken: false

Désactiver la découverte de services

Pour les pods qui n'ont pas besoin de rechercher ou d'appeler des services intégrés au cluster, vous pouvez réduire la quantité d'informations fournies à un pod. Vous pouvez définir la politique DNS du pod de manière à ne pas utiliser CoreDNS et à ne pas exposer les services de l'espace de noms du pod en tant que variables d'environnement. Consultez la documentation Kubernetes sur les variables d'environnement pour plus d'informations sur les liens de service. La valeur par défaut de la politique DNS d'un pod est « ClusterFirst » qui utilise le DNS intégré au cluster, tandis que la valeur autre que la valeur par défaut « Default » utilise la résolution DNS du nœud sous-jacent. Consultez la documentation de Kubernetes sur la politique Pod DNS pour plus d'informations.

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-service-info
spec:
    dnsPolicy: Default # "Default" is not the true default value
    enableServiceLinks: false

Configurez vos images avec un système de fichiers racine en lecture seule

La configuration de vos images avec un système de fichiers racine en lecture seule empêche un attaquant de remplacer un fichier binaire sur le système de fichiers utilisé par votre application. Si votre application doit écrire dans le système de fichiers, pensez à écrire dans un répertoire temporaire ou à attacher et monter un volume. Vous pouvez appliquer cela en configurant les modules SecurityContext comme suit :

...
securityContext:
  readOnlyRootFilesystem: true
...

Policy-as-code et les normes de sécurité des pods peuvent être utilisées pour appliquer ce comportement.

Conformément à Windows, les conteneurs de Kubernetes securityContext.readOnlyRootFilesystem ne peuvent pas être définis sur un conteneur exécuté sous Windows car un accès en écriture est requis pour que les processus du registre et du système s'exécutent à l'intérieur du conteneur. true

Outils et ressources