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.

Considérations relatives à la sécurité relatives aux fonctionnalités EKS

Cette rubrique aborde les principales considérations de sécurité 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 d'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 du 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 fonctionnalité 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 d'accorder uniquement les autorisations nécessaires pour répondre à vos exigences. Par exemple, lorsque vous utilisez la fonctionnalité EKS pour Kube Resource Orchestrator, aucune autorisation IAM 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 des rôles IAM liés aux fonctionnalités, 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 à la base de capacités Kubernetes l'autorisation de fonctionner.

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

Politiques de saisie 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 de saisie 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 doivent lire les secrets de 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ète, procédez comme suit :

autorisations de ressources arbitraires kro

kro a besoin d'autorisations pour créer et gérer les ressources définies dans votre ResourceGraphDefinitions. Par défaut, Kro ne peut que se surveiller et RGDs se gérer lui-même.

Pour accorder à Kro l'autorisation de créer des ressources, procédez comme suit :

Option 1 : accéder aux politiques d'entrée

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 de capacité uniquement les autorisations requises pour votre cas d'utilisation. Cela ne signifie pas que vous ne pouvez pas accorder des autorisations administratives étendues à vos fonctionnalités si nécessaire. Dans de tels cas, vous devez gérer l'accès à ces ressources de manière appropriée.

Rôles liés aux capacités :

Exemple : au lieu de"Resource": "*", spécifiez 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 des considérations relatives à chaque fonctionnalité.

Isolation de l'espace de noms pour les secrets d'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 les pratiques d'isolation des espaces de noms suivantes :

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 pour d'autres opérations spécifiques à Argo CD.

RBAC Kubernetes

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

Exemple : rôle RBAC compatible avec ACK, permettant de gérer les 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 au réseau et points de terminaison VPC

Accès privé à l'API Argo CD

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

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 ainsi un avantage opérationnel significatif en éliminant le besoin de peering VPC ou de configurations réseau complexes. Cependant, 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 d'EKS sont entièrement gérées et possèdent les certifications de conformité d'Amazon EKS.

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

Étapes suivantes