View a markdown version of this page

Renforcez Kubernetes RBAC dans Amazon EKS - Amazon EKS

Aidez à améliorer cette page

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

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.

Renforcez Kubernetes RBAC dans Amazon EKS

Le contrôle d'accès basé sur les rôles (RBAC) Kubernetes contrôle les actions que les identités peuvent effectuer au sein d'un cluster. De nombreux composants du cluster, notamment les pilotes CSI et autres modules complémentaires installés DaemonSets, nécessitent des autorisations étendues pour fonctionner. L'examen et la définition de ces autorisations réduisent la portée potentielle de tout accès involontaire.

Cette rubrique décrit les considérations relatives aux autorisations pour les composants de cluster courants et les contrôles recommandés.

DaemonSet autorisations relatives aux comptes de service

DaemonSet Les pods s'exécutent sur tous les nœuds du cluster, de sorte que leurs jetons de compte de service et les autorisations RBAC que ces jetons accordent sont présents sur chaque nœud.

Un processus non autorisé sur un nœud peut accéder aux jetons de compte de service d'autres pods exécutés sur le même nœud, y compris les DaemonSet pods. Les autorisations RBAC accordées aux comptes DaemonSet de service sont les mêmes sur tous les nœuds du cluster.

Les composants couramment déployés DaemonSets sont les suivants :

  • Pilotes de nœuds CSI (ebs-csi-node,efs-csi-node,mountpoint-s3-csi-node)

  • Le plug-in Amazon VPC CNI () aws-node

  • kube-proxy

Si un DaemonSet pod possède des informations d'identification AWS IAM via EKS Pod Identity ou IAM Roles for Service Accounts (IRSA), un processus qui obtient un accès en dehors de son conteneur sur le même nœud peut également accéder à ces informations d'identification. Cela étend l'étendue de l'impact au-delà de Kubernetes RBAC à toutes les autorisations d' AWS API accordées au rôle IAM d'un DaemonSet utilisateur.

Important

Lorsque vous passez en revue les autorisations, considérez les autorisations Kubernetes RBAC et les autorisations IAM de chaque compte de DaemonSet service comme étant accessibles depuis chaque nœud du cluster.

Périmètre RBAC du pilote CSI

Les pilotes CSI détiennent généralement des autorisations RBAC étendues car ils interagissent avec les nœuds, les volumes persistants et le stockage. APIs

Autorisations relatives aux objets du nœud

Les pilotes CSI peuvent avoir besoin d'autorisations RBAC pour modifier les objets du nœud afin de prendre en charge des fonctionnalités telles que la suppression des taches ou d'autres tâches de gestion des nœuds. En raison des limites du RBAC de Kubernetes, ces autorisations s'appliquent à tous les objets Node du cluster, et pas uniquement au nœud local sur lequel le pilote est exécuté.

Pour le pilote EBS CSI, le graphique Helm fournit un paramètre (node.serviceAccount.disableMutation) qui supprime l'autorisation de modification du nœud du compte de ebs-csi-node service. L'activation de cette option désactive la fonction de suppression des taches.

Exposition aux jetons des comptes de service

Les pods de pilotes CSI peuvent utiliser des jetons de compte de service projetés pour s'authentifier. Sur un nœud auquel un processus non autorisé a obtenu un accès en dehors de son conteneur, ces jetons peuvent être accessibles via le système de fichiers du conteneur ou l'API kubelet. Si le compte de service est également associé à un rôle IAM via EKS Pod Identity ou IRSA, un jeton exposé peut être utilisé pour obtenir des informations d'identification AWS IAM.

Étendre le RBAC au moindre privilège

  • Passez en revue les comptes de chauffeur et de DaemonSet service ClusterRoles liés au CSI. Supprimez les autorisations qui ne sont pas requises pour vos charges de travail.

  • Pour le pilote EBS CSI, réglez sur true si node.serviceAccount.disableMutation vous n'utilisez pas la fonction de suppression des taches.

  • kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:SERVICE_ACCOUNTÀ utiliser pour vérifier les autorisations effectives.

Appliquer les normes de sécurité des Pod

Appliquez les normes de sécurité Kubernetes Pod à l'aide du contrôleur d'admission Pod Security intégré ou d'un moteur de politiques. Appliquez au minimum le profil à l'échelle du cluster et le baseline restricted profil pour les espaces de noms de charge de travail. Cela limite la possibilité de créer des conteneurs privilégiés en dehors des espaces de noms du système.

Utilisation des politiques réseau

Appliquez des politiques réseau pour limiter la sortie du pilote CSI et DaemonSet des pods aux seuls points de terminaison dont ils ont besoin (par exemple, le serveur d'API Kubernetes et les points de terminaison de service). AWS Cela réduit la portée des actions possibles.

Surveiller l'activité RBAC

Activez la journalisation des audits Kubernetes et surveillez les appels d'API inattendus provenant de DaemonSet comptes de service. Recherchez :

  • Modifications de nœuds depuis les comptes de service de pilotes CSI

  • Création de pods dans les espaces de noms du système

  • Insolite get ou list fait appel à des secrets

Pour de plus amples informations, veuillez consulter Envoyer les journaux du plan de contrôle à CloudWatch Logs.