Considérations relatives à Argo CD

Cette rubrique aborde les considérations importantes relatives à l'utilisation de la fonctionnalité EKS pour Argo CD, notamment la planification, les autorisations, l'authentification et les modèles de déploiement multi-clusters.

Planification

Avant de déployer Argo CD, tenez compte des points suivants :

Stratégie de dépôt  : déterminez où les manifestes de votre application seront stockés (CodeCommit, GitHub, GitLab, Bitbucket). Planifiez la structure de votre référentiel et votre stratégie de branchement pour différents environnements.

Stratégie RBAC  : planifiez les équipes ou les utilisateurs qui doivent avoir un accès administrateur, éditeur ou spectateur. Associez-les à des groupes AWS Identity Center ou à des rôles Argo CD.

Multi-cluster architecture  : déterminez si vous allez gérer plusieurs clusters à partir d'une seule instance Argo CD. Envisagez d'utiliser un cluster de gestion dédié pour Argo CD.

Organisation des applications  : planifiez la façon dont vous allez structurer les applications et ApplicationSets. Envisagez d'utiliser des projets pour organiser les applications par équipe ou par environnement.

Politiques de synchronisation  : décidez si les applications doivent être synchronisées automatiquement ou si elles doivent être approuvées manuellement. La synchronisation automatique est courante pour le développement, manuelle pour la production.

Permissions

Pour obtenir des informations détaillées sur les rôles de capacité IAM, les politiques de confiance et les meilleures pratiques de sécurité, consultez Fonctionnalité Amazon EKS : rôle IAM etConsidérations relatives à la sécurité pour les fonctionnalités EKS.

Présentation du rôle de capacité IAM

Lorsque vous créez une ressource de fonctionnalité Argo CD, vous fournissez un rôle de capacité IAM. Contrairement à ACK, Argo CD gère principalement les ressources Kubernetes, et non les ressources directement. AWS Cependant, le rôle de capacité IAM est requis pour :

CodeCommit intégration

Si vous utilisez des CodeCommit référentiels, joignez une politique avec des autorisations de lecture :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codecommit:GitPull"
      ],
      "Resource": "*"
    }
  ]
}

"Resource": "arn:aws:codecommit:us-west-2:111122223333:my-app-repo"

Intégration de Secrets Manager

Si vous stockez les informations d'identification du référentiel dans Secrets Manager, joignez la politique gérée pour l'accès en lecture :

arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess

Cette politique inclut les autorisations nécessaires : secretsmanager:GetSecretValuesecretsmanager:DescribeSecret, et les autorisations de déchiffrement KMS.

Configuration de base

Pour les fonctionnalités de base d'Argo CD avec des référentiels Git publics, aucune politique IAM supplémentaire n'est requise au-delà de la politique de confiance.

Authentification

AWS Intégration à Identity Center

La fonctionnalité gérée d'Argo CD s'intègre directement à AWS Identity Center (anciennement AWS SSO), ce qui vous permet d'utiliser votre fournisseur d'identité existant pour l'authentification.

Lorsque vous configurez AWS l'intégration d'Identity Center :

Simplification de l'accès grâce aux ensembles d'autorisations Identity Center

AWS Identity Center propose deux voies d'authentification distinctes lorsque vous travaillez avec Argo CD :

Authentification par API Argo CD  : Identity Center fournit une authentification SSO à l'interface utilisateur et à l'API Argo CD. Ceci est configuré via les mappages de rôles RBAC de la fonctionnalité Argo CD.

Accès au cluster EKS  : la fonctionnalité Argo CD utilise le rôle IAM fourni par le client pour s'authentifier auprès des clusters EKS via des entrées d'accès. Ces entrées d'accès peuvent être configurées manuellement pour ajouter ou supprimer des autorisations.

Vous pouvez utiliser les ensembles d'autorisations Identity Center pour simplifier la gestion des identités en permettant à une seule identité d'accéder à la fois aux clusters Argo CD et EKS. Cela réduit les frais généraux en vous obligeant à ne gérer qu'une seule identité sur les deux systèmes, au lieu de conserver des informations d'identification distinctes pour l'accès à Argo CD et l'accès au cluster.

Mappages de rôles RBAC

Argo CD possède des rôles intégrés que vous pouvez associer aux utilisateurs et aux groupes AWS d'Identity Center :

ADMIN  : accès complet à toutes les applications et à tous les paramètres. Peut créer, mettre à jour et supprimer des applications. Peut gérer la configuration d'Argo CD.

EDITEUR  : Peut créer et modifier des applications. Impossible de modifier les paramètres d'Argo CD ni de supprimer des applications.

VIEWER  : Read-only accès aux applications. Peut consulter l'état et l'historique des demandes. Impossible d'apporter des modifications.

Multi-cluster déploiements

La fonctionnalité gérée d'Argo CD prend en charge les déploiements multi-clusters, ce qui vous permet de gérer des applications sur des clusters de développement, de test et de production à partir d'une seule instance Argo CD.

Comment fonctionne le multi-cluster

Lorsque vous enregistrez des clusters supplémentaires avec Argo CD :

Prérequis pour le multicluster

Avant d'enregistrer des clusters supplémentaires :

Enregistrer un cluster

Enregistrez les clusters à l'aide de Kubernetes Secrets dans l'espace de noms. argocd

Obtenez l'ARN du cluster cible. region-codeRemplacez-la par la AWS région dans laquelle se trouve votre cluster cible et target-cluster remplacez-la par le nom de votre cluster cible.

aws eks describe-cluster \
  --region region-code \
  --name target-cluster \
  --query 'cluster.arn' \
  --output text

Créez un secret de cluster à l'aide de l'ARN du cluster :

apiVersion: v1
kind: Secret
metadata:
  name: target-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
  name: target-cluster
  server: arn:aws:eks:us-west-2:111122223333:cluster/target-cluster
  project: default

Appliquez le secret :

kubectl apply -f cluster-secret.yaml

Configurer l'entrée d'accès sur le cluster cible

Le cluster cible doit disposer d'une entrée d'accès qui accorde au rôle de capacité Argo CD l'autorisation de déployer des applications. Remplacez region-code par la AWS région dans laquelle se trouve votre cluster cible, remplacez target-cluster par le nom de votre cluster cible et remplacez l'ARN par l'ARN de votre rôle de capacité Argo CD.

aws eks create-access-entry \
  --region region-code \
  --cluster-name target-cluster \
  --principal-arn arn:aws:iam::111122223333:role/ArgoCDCapabilityRole \
  --type STANDARD \
  --kubernetes-groups system:masters

Accès au cluster privé

La fonctionnalité gérée d'Argo CD peut être déployée sur 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. Assurez-vous que les contrôles d'accès au référentiel et les politiques Argo CD RBAC sont correctement configurés.

Cross-account déploiements

Pour les déploiements entre comptes, ajoutez le rôle de capacité Argo CD IAM depuis le compte source à l'entrée d'accès EKS du cluster cible :

Aucune création de rôle IAM supplémentaire ou configuration de politique de confiance n'est requise : EKS Access Entries gère l'accès entre comptes.

Bonnes pratiques

Utilisez des sources déclaratives comme source de vérité  : stockez tous les manifestes de votre application dans des sources déclaratives (dépôts Git, registres Helm ou images OCI), ce qui permet le contrôle des versions, les pistes d'audit et la collaboration.

Implémentez un RBAC approprié  : utilisez AWS l'intégration d'Identity Center pour contrôler qui peut accéder aux applications et les gérer dans Argo CD. Argo CD permet un contrôle d'accès précis aux ressources au sein des applications (déploiements, pods, ConfigMaps secrets).

Utilisation ApplicationSets pour les déploiements multi-environnements  : permet ApplicationSets de déployer des applications sur plusieurs clusters ou espaces de noms avec différentes configurations.

Gestion du cycle de vie

Politiques de synchronisation des applications

Contrôlez la façon dont Argo CD synchronise les applications :

Synchronisation manuelle  : les applications nécessitent une approbation manuelle pour synchroniser les modifications. Recommandé pour les environnements de production.

Synchronisation automatique  : les applications se synchronisent automatiquement lorsque des modifications de Git sont détectées. Commun pour les environnements de développement et de mise en scène.

Self-healing: annule automatiquement les modifications manuelles apportées au cluster. Garantit que l'état du cluster correspond à Git.

Elagage  : supprimez automatiquement les ressources supprimées de Git. À utiliser avec prudence car cela peut supprimer des ressources.

État de santé des applications

Argo CD surveille en permanence l'état de santé des applications :

Fenêtres de synchronisation

Configurez les fenêtres de synchronisation pour contrôler le moment où les applications peuvent être synchronisées :

Configuration du Webhook pour une synchronisation plus rapide

Par défaut, Argo CD interroge les dépôts Git toutes les 6 minutes pour détecter les modifications. Pour des déploiements plus réactifs, configurez les webhooks Git pour déclencher des synchronisations immédiates lorsque des modifications sont apportées.

Les webhooks offrent plusieurs avantages :

Point de terminaison Webhook

L'URL du webhook suit le modèle${serverUrl}/api/webhook, où se serverUrl trouve l'URL de votre serveur Argo CD. Pour trouver l'URL de votre serveur, consultezURL du point de terminaison Argo CD.

Par exemple, si l'URL de votre serveur Argo CD esthttps://my-argocd-dc855fdf-111122223333.eks-capabilities.us-west-2.amazonaws.com, l'URL du webhook est la suivante :

https://my-argocd-dc855fdf-111122223333.eks-capabilities.us-west-2.amazonaws.com/api/webhook

Configurer les webhooks par fournisseur Git

GitHub: Dans les paramètres de votre référentiel, ajoutez un webhook avec l'URL du webhook Argo CD. Définissez le type de contenu sur application/json et sélectionnez « Uniquement l'événement push ».

GitLab: Dans les paramètres de votre projet, ajoutez un webhook avec l'URL du webhook Argo CD. Activez « Événements push » et éventuellement « Tag événements push ».

Bitbucket  : dans les paramètres de votre référentiel, ajoutez un webhook avec l'URL du webhook Argo CD. Sélectionnez « Repository push » comme déclencheur.

CodeCommit: créez une EventBridge règle Amazon qui se déclenche en cas de modification de l'état CodeCommit du référentiel et envoie des notifications au point de terminaison du webhook Argo CD.

Pour obtenir des instructions détaillées sur la configuration du webhook, consultez la section Configuration du webhook Argo CD.

Étapes suivantes