**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. # Enregistrer les clusters cibles Enregistrez les clusters pour permettre à Argo CD d'y déployer des applications. Vous pouvez enregistrer le même cluster sur lequel Argo CD est en cours d'exécution (cluster local) ou des clusters distants dans différents comptes ou régions. Une fois qu'un cluster est enregistré, il reste dans un état de connexion inconnu jusqu'à ce que vous créiez une application au sein de ce cluster. Pour créer une application Argo CD après l'enregistrement de votre cluster, consultez[Création d'applications](argocd-create-application.md). ## Conditions préalables + Création d'un cluster EKS doté de la fonctionnalité Argo CD + `kubectl`configuré pour communiquer avec votre cluster + Pour les clusters distants : autorisations IAM et entrées d'accès appropriées ## Enregistrez le cluster local Pour déployer des applications sur le même cluster que celui sur lequel Argo CD est exécuté, enregistrez-le en tant que cible de déploiement. **Important** La fonctionnalité Argo CD n'enregistre pas automatiquement le cluster local. Vous devez l'enregistrer explicitement pour déployer des applications sur le même cluster. Vous pouvez utiliser le nom du cluster `in-cluster` pour assurer la compatibilité avec la plupart des exemples de CD Argo en ligne. **Note** Une entrée d'accès EKS est automatiquement créée pour le cluster local avec le rôle Argo CD Capability, mais aucune autorisation RBAC Kubernetes n'est accordée par défaut. Cela suit le principe du moindre privilège : vous devez configurer explicitement les autorisations dont Argo CD a besoin en fonction de votre cas d'utilisation. Par exemple, si vous utilisez ce cluster uniquement comme hub Argo CD pour gérer des clusters distants, il n'a pas besoin d'autorisations de déploiement local. Consultez la section relative aux exigences RBAC relatives aux entrées d'accès ci-dessous pour connaître les options de configuration. **À l'aide de l'Argo CD CLI** : ``` argocd cluster add \ --aws-cluster-name arn:aws:eks:us-west-2:111122223333:cluster/my-cluster \ --name local-cluster ``` **À l'aide d'un secret Kubernetes** : ``` apiVersion: v1 kind: Secret metadata: name: local-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: local-cluster server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster project: default ``` Appliquez la configuration : ``` kubectl apply -f local-cluster.yaml ``` **Note** Utilisez l'ARN du cluster EKS `server` sur le terrain, et non l'URL du serveur d'API Kubernetes. La fonctionnalité gérée nécessite des ARN pour identifier les clusters. La valeur par défaut n'`kubernetes.default.svc`est pas prise en charge. ## Enregistrer des clusters distants Pour effectuer un déploiement sur des clusters distants : **Étape 1 : créer l'entrée d'accès sur le cluster distant** Remplacez {{region-code}} par la AWS région dans laquelle se trouve votre cluster distant, remplacez {{remote-cluster}} par le nom de votre cluster distant et remplacez l'ARN par l'ARN de votre rôle de fonctionnalité Argo CD. ``` aws eks create-access-entry \ --region {{region-code}} \ --cluster-name {{remote-cluster}} \ --principal-arn {{arn:aws:iam::111122223333:role/ArgoCDCapabilityRole}} \ --type STANDARD ``` **Étape 2 : associer une politique d'accès aux autorisations Kubernetes RBAC** L'entrée d'accès nécessite des autorisations RBAC Kubernetes pour qu'Argo CD puisse déployer des applications. Pour démarrer rapidement, vous pouvez utiliser `AmazonEKSClusterAdminPolicy` : ``` aws eks associate-access-policy \ --region {{region-code}} \ --cluster-name {{remote-cluster}} \ --principal-arn {{arn:aws:iam::111122223333:role/ArgoCDCapabilityRole}} \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \ --access-scope type=cluster ``` **Important** `AmazonEKSClusterAdminPolicy`Fournit un accès complet à l'administrateur du cluster (équivalent à). `system:masters` C'est pratique pour démarrer mais ne doit pas être utilisé en production. Pour les environnements de production, utilisez des autorisations plus restrictives en associant l'entrée d'accès à des groupes Kubernetes personnalisés et en créant un rôle ou des liaisons appropriés. ClusterRole Consultez la section relative à la configuration de production ci-dessous pour la configuration du moindre privilège. **Étape 3 : enregistrer le cluster dans Argo CD** **À l'aide de l'Argo CD CLI** : ``` argocd cluster add \ --aws-cluster-name arn:aws:eks:us-west-2:111122223333:cluster/remote-cluster \ --name remote-cluster ``` **À l'aide d'un secret Kubernetes** : ``` apiVersion: v1 kind: Secret metadata: name: remote-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: remote-cluster server: arn:aws:eks:us-west-2:111122223333:cluster/remote-cluster project: default ``` Appliquez la configuration : ``` kubectl apply -f remote-cluster.yaml ``` ## Cross-account clusters Pour effectuer un déploiement sur des clusters appartenant à différents AWS comptes, procédez comme suit : 1. Dans le compte cible, créez une entrée d'accès sur le cluster EKS cible en utilisant l'Argo CD IAM Capability Role (ARN) du compte source comme principal 1. Associer une politique d'accès aux autorisations Kubernetes RBAC appropriées 1. Enregistrez le cluster dans Argo CD à l'aide de son ARN de cluster EKS Aucune création de rôle IAM ou configuration de politique de confiance supplémentaire n'est requise : les entrées d'accès EKS gèrent l'accès entre comptes. Le format ARN du cluster inclut la région, de sorte que les déploiements entre régions utilisent le même processus que les déploiements dans la même région. ## Vérifier l'enregistrement du cluster Afficher les clusters enregistrés : ``` kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=cluster ``` Ou vérifiez l'état du cluster dans l'interface utilisateur d'Argo CD sous Paramètres → Clusters. ## Clusters privés La fonctionnalité Argo CD fournit un accès transparent à des clusters EKS entièrement privés sans nécessiter de peering VPC ou de configuration réseau spécialisée. AWS gère automatiquement la connectivité entre la fonctionnalité Argo CD et les clusters distants privés. Enregistrez simplement le cluster privé à l'aide de son ARN, aucune configuration réseau supplémentaire n'est requise. ## Exigences RBAC d'entrée d'accès Lorsque vous créez une fonctionnalité Argo CD, une entrée d'accès EKS est automatiquement créée pour le rôle de capacité, mais aucune autorisation RBAC Kubernetes n'est accordée par défaut. Cette conception intentionnelle suit le principe du moindre privilège : différents cas d'utilisation nécessitent des autorisations différentes. Par exemple :\* Si vous utilisez le cluster uniquement comme hub Argo CD pour gérer des clusters distants, il n'a pas besoin d'autorisations de déploiement local \* Si vous déployez des applications localement, il a besoin d'un accès en lecture à l'échelle du cluster et d'un accès en écriture à des espaces de noms spécifiques \* Si vous devez créer des CRD, des autorisations d'administrateur de cluster supplémentaires sont nécessaires Vous devez configurer explicitement les autorisations dont Argo CD a besoin en fonction de vos besoins. ### Autorisations minimales pour Argo CD Argo CD a besoin de deux types d'autorisations pour fonctionner sans erreur : **Autorisations de lecture (à l'échelle du cluster)** : Argo CD doit être capable de lire tous les types de ressources et les définitions de ressources personnalisées (CRD) du cluster pour : + Découverte des ressources et bilans de santé + Détection de la dérive entre l'état souhaité et l'état réel + Validation des ressources avant le déploiement **Autorisations d'écriture (spécifiques à l'espace de noms)** : Argo CD a besoin d'autorisations de création, de mise à jour et de suppression pour les ressources définies dans Applications : + Déployez les charges de travail des applications (déploiements, services ConfigMaps, etc.) + Appliquer des ressources personnalisées (CRD spécifiques à vos applications) + Gérer le cycle de vie des applications ### Configuration rapide Pour une mise en route rapide, des environnements de test ou de développement, utilisez `AmazonEKSClusterAdminPolicy` : ``` aws eks associate-access-policy \ --region {{region-code}} \ --cluster-name {{my-cluster}} \ --principal-arn {{arn:aws:iam::111122223333:role/ArgoCDCapabilityRole}} \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \ --access-scope type=cluster ``` **Important** `AmazonEKSClusterAdminPolicy`Il fournit un accès complet aux administrateurs du cluster (équivalent à`system:masters`), y compris la possibilité de créer des CRD, de modifier les ressources à l'échelle du cluster et de les déployer dans n'importe quel espace de noms. C'est pratique pour le développement et les POC, mais ne doit pas être utilisé en production. Pour la production, utilisez la configuration de moindre privilège ci-dessous. ### Configuration de production avec le moins de privilèges Pour les environnements de production, créez un RBAC Kubernetes personnalisé qui accorde : + Cluster-wide accès en lecture à toutes les ressources (pour les découvertes et les bilans de santé) + Namespace-specific accès en écriture (pour les déploiements) **Étape 1 : associer l'entrée d'accès à un groupe Kubernetes personnalisé** ``` aws eks associate-access-policy \ --region {{region-code}} \ --cluster-name {{my-cluster}} \ --principal-arn {{arn:aws:iam::111122223333:role/ArgoCDCapabilityRole}} \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \ --access-scope type=namespace,namespaces={{app-namespace}} ``` **Étape 2 : Création ClusterRole pour un accès en lecture** ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: argocd-read-all rules: # Read access to all resources for discovery and health checks - apiGroups: ["*"] resources: ["*"] verbs: ["get", "list", "watch"] ``` **Étape 3 : créer un rôle pour l'accès en écriture aux espaces de noms des applications** ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: argocd-deploy namespace: app-namespace rules: # Full access to deploy application resources - apiGroups: ["*"] resources: ["*"] verbs: ["*"] ``` **Étape 4 : lier les rôles au groupe Kubernetes** ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: argocd-read-all subjects: - kind: Group name: eks-access-entry:arn:aws:iam::111122223333:role/ArgoCDCapabilityRole apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: argocd-read-all apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: argocd-deploy namespace: app-namespace subjects: - kind: Group name: eks-access-entry:arn:aws:iam::111122223333:role/ArgoCDCapabilityRole apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: argocd-deploy apiGroup: rbac.authorization.k8s.io ``` **Note** Le format du nom de groupe pour les entrées d'accès est `eks-access-entry:` suivi par l'ARN principal. Répétez cette opération RoleBinding pour chaque espace de noms dans lequel Argo CD doit déployer des applications. **Important** Argo CD doit être capable de lire tous les types de ressources du cluster à des fins de vérification de l'état et de découverte, même s'il n'est déployé que dans des espaces de noms spécifiques. Sans accès en lecture à l'échelle du cluster, Argo CD affichera des erreurs lors de la vérification de l'état de l'application. ## Restreindre l'accès au cluster avec Projects Utilisez les projets pour contrôler les clusters et les espaces de noms dans lesquels les applications peuvent être déployées en configurant les clusters et espaces de noms cibles autorisés dans : `spec.destinations` ``` apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: production namespace: argocd spec: destinations: - server: arn:aws:eks:us-west-2:111122223333:cluster/prod-cluster namespace: '*' - server: arn:aws:eks:eu-west-1:111122223333:cluster/prod-eu-cluster namespace: '*' sourceRepos: - 'https://github.com/example/production-apps' ``` Pour en savoir plus, consultez [Travailler avec des projets Argo CD](argocd-projects.md). ## Ressources supplémentaires + [Travailler avec des projets Argo CD](argocd-projects.md)- Organisez les applications et appliquez les limites de sécurité + [Création d'applications](argocd-create-application.md)- Déployez votre première application + [Utiliser ApplicationSets](argocd-applicationsets.md)- Déployez sur plusieurs clusters avec ApplicationSets + [Considérations relatives à Argo CD](argocd-considerations.md)- Multi-cluster modèles et configuration entre comptes + Configuration [déclarative du cluster - Référence de configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#clusters) du cluster en amont