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

Considérations relatives à la sécurité pour les fonctionnalités EKS

Cette rubrique couvre les considérations de sécurité importantes relatives aux fonctionnalités EKS, notamment la configuration des rôles IAM, les autorisations Kubernetes et les modèles architecturaux pour les déploiements multi-clusters et la gestion des ressources entre comptes. AWS

Les fonctionnalités EKS utilisent une combinaison de rôles IAM, d'entrées d'accès EKS et de Kubernetes RBAC pour fournir un accès sécurisé aux AWS services, aux ressources Kubernetes intégrées au cluster et à des intégrations avec Secrets Manager et d'autres services. AWS CodeConnections AWS AWS

Capacité : rôle IAM

Lorsque vous créez une fonctionnalité, vous fournissez un rôle de capacité IAM qu'EKS utilise pour effectuer des actions en votre nom. Ce rôle doit :

Il est recommandé de prendre en compte l'étendue des privilèges requis pour votre cas d'utilisation spécifique et de n'accorder que les autorisations nécessaires pour répondre à vos besoins. Par exemple, lorsque vous utilisez la fonctionnalité EKS pour Kube Resource Orchestrator, aucune autorisation IAM n'est peut-être requise, tandis que lorsque vous utilisez la fonctionnalité EKS pour les AWS contrôleurs pour Kubernetes, vous pouvez accorder un accès complet à un ou plusieurs services. AWS

Pour des informations détaillées sur la création et la configuration de rôles IAM de capacité, consultezFonctionnalité Amazon EKS : rôle IAM.

Entrées d'accès EKS

Lorsque vous créez une fonctionnalité avec un rôle IAM, Amazon EKS crée automatiquement une entrée d'accès pour ce rôle sur votre cluster. Cette entrée d'accès accorde à Kubernetes les autorisations de fonctionnement de base des capacités.

L'entrée d'accès comprend :

Politiques d'entrée d'accès par défaut par fonctionnalité

Chaque type de capacité accorde au rôle de capacité les autorisations requises, en définissant différentes politiques d'entrée d'accès par défaut comme suit :

Voir Vérification des autorisations des stratégies d’accès pour des informations plus détaillées.

Autorisations Kubernetes supplémentaires

Certaines fonctionnalités peuvent nécessiter des autorisations Kubernetes supplémentaires au-delà des politiques d'entrée d'accès par défaut. Vous pouvez accorder ces autorisations en utilisant l'une des méthodes suivantes :

Autorisations du lecteur secret ACK

Certains contrôleurs ACK ont besoin de lire les secrets Kubernetes pour récupérer des données sensibles telles que les mots de passe des bases de données. Les contrôleurs ACK suivants nécessitent un accès secret en lecture :

Pour accorder des autorisations de lecture secrètes :

autorisations de ressources arbitraires kro

Par défaut, kro peut surveiller et gérer ResourceGraphDefinitions (RGD) et leurs instances. Pour gérer des ressources composées telles que des déploiements, des services ou configurer des ConfigMaps autorisations Kubernetes supplémentaires.

Pour accorder à KRO des autorisations lui permettant de créer des ressources, procédez comme suit :

Option 1 : politiques d'accès

Associez des politiques d'entrée d'accès prédéfinies telles que AmazonEKSAdminPolicy ou AmazonEKSEditPolicy à l'entrée d'accès de la fonctionnalité.

Option 2 : Kubernetes RBAC

Créez un ClusterRoleBinding qui accorde à l'utilisateur Kubernetes de la fonctionnalité les autorisations nécessaires :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kro-cluster-admin
subjects:
- kind: User
  name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Autorisations IAM requises par fonctionnalité

Bonnes pratiques de sécurité

Le moindre privilège de l'IAM

Accordez à vos ressources capacitaires uniquement les autorisations requises pour votre cas d'utilisation. Cela ne signifie pas que vous ne pouvez pas accorder des autorisations administratives étendues à vos capacités si nécessaire. Dans de tels cas, vous devez réglementer l'accès à ces ressources de manière appropriée.

Rôles liés aux capacités  :

Exemple  : Spécifiez plutôt "Resource": "*" des modèles pour des ressources ou des groupes de ressources spécifiques.

"Resource": [
  "arn:aws:s3:::my-app-*",
  "arn:aws:rds:us-west-2:111122223333:db:prod-*"
]

Utilisez les clés de condition IAM pour restreindre davantage l'accès :

"Condition": {
  "StringEquals": {
    "aws:ResourceTag/Environment": "production"
  }
}

Pour plus d'informations sur la configuration IAM, consultez la section Considérations pour chaque fonctionnalité.

Isolation de l'espace de noms pour les secrets Argo CD

La fonctionnalité Argo CD gérée a accès à tous les secrets Kubernetes dans son espace de noms configuré (par défaut :). argocd Pour maintenir une posture de sécurité optimale, suivez ces pratiques d'isolation des espaces de noms :

Cette isolation garantit que l'accès secret d'Argo CD est limité aux seules informations d'identification dont il a besoin pour l'authentification du référentiel Git et d'autres opérations Argo CD-specific .

Kubernetes RBAC

Contrôlez quels utilisateurs et comptes de service peuvent créer et gérer des ressources de fonctionnalités. Il est recommandé de déployer des ressources de fonctionnalités dans des espaces de noms dédiés avec des politiques RBAC appropriées.

Exemple : rôle RBAC pour fonctionner avec ACK, permettant la gestion des ressources du compartiment S3 dans l'espace de app-team noms :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ack-s3-manager
  namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
  resources: ["buckets"]
  verbs: ["get", "list", "create", "update", "delete"]

Journaux d’audit

CloudTrail: Toutes les opérations de l'API EKS Capability (création, mise à jour, suppression) sont enregistrées AWS CloudTrail.

Activez la CloudTrail journalisation pour suivre :

Accès réseau et points de terminaison VPC

Accès privé à l'API Argo CD

Vous pouvez restreindre l'accès au serveur Argo CD API en associant un ou plusieurs points de terminaison VPC au point de terminaison Argo CD hébergé. Cela permet une connectivité privée depuis votre VPC sans passer par l'Internet public. Le point de terminaison VPC permet d'accéder à la fois à l'interface utilisateur Web d'Argo CD et à l'API Argo CD (y compris l'accès à la CLI).

Déploiement sur des clusters privés

La fonctionnalité Argo CD permet de déployer des applications sur des clusters EKS entièrement privés, offrant un avantage opérationnel significatif en éliminant le besoin de peering VPC ou de configurations réseau complexes. Toutefois, lors de la conception de cette architecture, considérez qu'Argo CD extraira la configuration des référentiels Git (qui peuvent être publics) et l'appliquera à vos clusters privés.

Assurez-vous de :

Conformité d’

Les fonctionnalités EKS sont entièrement gérées et possèdent les certifications de conformité d'Amazon EKS.

Pour les informations de conformité actuelles, consultez la section AWS Services concernés par le programme de conformité.

Étapes suivantes