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.

Configurer les autorisations d'Argo CD

La fonctionnalité gérée par Argo CD s'intègre à AWS Identity Center pour l'authentification et utilise des rôles RBAC intégrés pour l'autorisation. Cette rubrique explique comment configurer les autorisations pour les utilisateurs et les équipes.

Comment fonctionnent les autorisations avec Argo CD

La fonctionnalité Argo CD utilise AWS Identity Center pour l'authentification et fournit trois rôles RBAC intégrés pour l'autorisation.

Lorsqu'un utilisateur accède à Argo CD :

Rôles RBAC intégrés

La fonctionnalité Argo CD fournit trois rôles intégrés que vous pouvez associer aux utilisateurs et aux groupes AWS d'Identity Center. Il s'agit de rôles de portée mondiale qui contrôlent l'accès aux ressources Argo CD telles que les projets, les clusters et les référentiels.

ADMINISTRATEUR

Accès complet à toutes les ressources et à tous les paramètres d'Argo CD :

RÉDACTEUR

Peut mettre à jour des projets et configurer les rôles des projets, mais ne peut pas modifier les paramètres globaux d'Argo CD :

SPECTATEUR

Accès en lecture seule aux ressources Argo CD :

Rôles du projet et accès délimité par le projet

Les rôles globaux (ADMIN, EDITOR, VIEWER) contrôlent l'accès à Argo CD lui-même. Les rôles de projet contrôlent l'accès aux ressources et aux capacités au sein d'un projet spécifique, notamment :

Comprendre le modèle d'autorisation à deux niveaux :

Autrement dit :

Exemple de flux de travail :

Pour plus de détails sur la configuration des rôles du projet, consultezContrôle d'accès basé sur le projet.

Configuration des mappages de rôles

Associez les utilisateurs et les groupes AWS d'Identity Center aux rôles Argo CD lors de la création ou de la mise à jour de la fonctionnalité.

Exemple de mappage des rôles :

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["AdminGroup", "alice@example.com"],
    "EDITOR": ["DeveloperGroup", "DevOpsTeam"],
    "VIEWER": ["ReadOnlyGroup", "bob@example.com"]
  }
}

Mettre à jour les mappages de rôles :

aws eks update-capability \
  --region us-east-1 \
  --cluster-name cluster \
  --capability-name capname \
  --endpoint "https://eks.ap-northeast-2.amazonaws.com" \
  --role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
  --configuration '{
    "argoCd": {
      "rbacRoleMappings": {
        "addOrUpdateRoleMappings": [
          {
            "role": "ADMIN",
            "identities": [
              { "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
            ]
          }
        ]
      }
    }
  }'

Utilisation du compte administrateur

Le compte administrateur est conçu pour la configuration initiale et les tâches administratives telles que l'enregistrement de clusters et la configuration de référentiels.

Lorsque le compte administrateur est approprié :

Bonnes pratiques pour le compte administrateur :

Quand utiliser plutôt l'accès basé sur le projet :

Pour les environnements de production et les scénarios multi-utilisateurs, utilisez le contrôle d'accès basé sur le projet avec des rôles RBAC dédiés mappés aux groupes Identity Center. AWS

Contrôle d'accès basé sur le projet

Utilisez Argo CD Projects (AppProject) pour fournir un contrôle d'accès précis et une isolation des ressources aux équipes.

Les projets fournissent :

Exemple de projet pour isoler une équipe :

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  description: Team A applications

  # Required: Specify which namespaces this project watches for Applications
  sourceNamespaces:
  - argocd

  # Source restrictions
  sourceRepos:
  - https://github.com/myorg/team-a-apps

  # Destination restrictions
  destinations:
  - namespace: team-a-*
    server: arn:aws:eks:us-west-2:111122223333:cluster/production

  # Resource restrictions
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceWhitelist:
  - group: 'apps'
    kind: Deployment
  - group: ''
    kind: Service
  - group: ''
    kind: ConfigMap

Espaces de noms sources

Lorsque vous utilisez la fonctionnalité EKS Argo CD, le spec.sourceNamespaces champ est obligatoire dans AppProject les définitions. Ce champ indique quel espace de noms peut contenir des applications ou ApplicationSets qui font référence à ce projet.

AppProject configuration

Tous AppProjects doivent inclure l'espace de noms configuré pour la fonctionnalité dans sourceNamespaces :

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a-project
  namespace: argocd
spec:
  description: Applications for Team A

  # Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
  sourceNamespaces:
    - argocd  # Must match your capability's namespace configuration

  # Source repositories this project can deploy from
  sourceRepos:
    - 'https://github.com/my-org/team-a-*'

  # Destination restrictions
  destinations:
    - namespace: 'team-a-*'
      server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster

Affecter des utilisateurs à des projets :

Les rôles de projet permettent aux utilisateurs de EDITOR et VIEWER d'accéder aux ressources du projet (applications ApplicationSets, informations d'identification du référentiel et du cluster) et aux fonctionnalités (journaux, exec) du projet. Sans rôles de projet, ces utilisateurs ne peuvent pas accéder à ces ressources même s'ils disposent d'un accès global aux rôles.

Les utilisateurs ADMIN ont accès à toutes les applications sans avoir besoin de rôles de projet.

Exemple : accorder l'accès à l'application aux membres de l'équipe

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  # ... project configuration ...

  sourceNamespaces:
  - argocd

  # Project roles grant Application-level access
  roles:
  - name: developer
    description: Team A developers - can manage Applications
    policies:
    - p, proj:team-a:developer, applications, *, team-a/*, allow
    - p, proj:team-a:developer, clusters, get, *, allow  # See cluster names in UI
    groups:
    - 686103e0-f051-7068-b225-e6392b959d9e  # Identity Center group ID

  - name: viewer
    description: Team A viewers - read-only Application access
    policies:
    - p, proj:team-a:viewer, applications, get, team-a/*, allow
    - p, proj:team-a:viewer, clusters, get, *, allow  # See cluster names in UI
    groups:
    - 786203e0-f051-7068-b225-e6392b959d9f  # Identity Center group ID

Comprendre les politiques relatives aux rôles du projet :

Le format de la politique est le suivant : p, proj:<project>:<role>, <resource>, <action>, <object>, <allow/deny>

Politiques relatives aux ressources :

Politiques de capacité :

Modèles d'autorisation courants

Modèle 1 : équipe d'administration avec accès complet

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["PlatformTeam", "SRETeam"]
  }
}

Les utilisateurs ADMIN peuvent voir et gérer toutes les ressources liées au projet sans configuration supplémentaire.

Schéma 2 : les chefs d'équipe gèrent les projets, les développeurs y accèdent via les rôles du projet

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["PlatformTeam"],
    "EDITOR": ["TeamLeads"],
    "VIEWER": ["AllDevelopers"]
  }
}

Modèle 3 : accès basé sur l'équipe avec des rôles de projet

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["PlatformTeam"],
    "EDITOR": ["TeamLeads"],
    "VIEWER": ["AllDevelopers"]
  }
}

Bonnes pratiques

Utilisez des groupes plutôt que des utilisateurs individuels : associez les groupes AWS Identity Center aux rôles Argo CD plutôt qu'aux utilisateurs individuels pour faciliter la gestion.

Commencez avec le moins de privilèges : commencez par l'accès VIEWER et accordez EDITOR ou ADMIN selon les besoins.

Utilisez des projets pour isoler les équipes : créez des projets distincts AppProjects pour les différentes équipes ou environnements afin de renforcer les limites.

Tirez parti de la fédération Identity Center : configurez AWS Identity Center pour qu'il soit fédéré avec votre fournisseur d'identité d'entreprise afin de centraliser la gestion des utilisateurs.

Révisions d'accès régulières : passez régulièrement en revue les mappages de rôles et les attributions de projets pour garantir des niveaux d'accès appropriés.

Limiter l'accès au cluster : n'oubliez pas qu'Argo CD RBAC contrôle l'accès aux ressources et aux opérations Argo CD, mais ne correspond pas au RBAC Kubernetes. Les utilisateurs disposant d'un accès à Argo CD peuvent déployer des applications sur des clusters auxquels Argo CD a accès. Limitez les clusters auxquels Argo CD peut accéder et utilisez les restrictions de destination du projet pour contrôler où les applications peuvent être déployées.

AWS autorisations de service

Pour utiliser les AWS services directement dans les ressources de l'application (sans créer de ressources de référentiel), associez les autorisations IAM requises au rôle de capacité.

ECR pour les cartes Helm :

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage"
      ],
      "Resource": "*"
    }
  ]
}

CodeCommit référentiels :

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codecommit:GitPull"
      ],
      "Resource": "arn:aws:codecommit:region:account-id:repository-name"
    }
  ]
}

CodeConnections (GitHub GitLab, Bitbucket) :

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codeconnections:UseConnection"
      ],
      "Resource": "arn:aws:codeconnections:region:account-id:connection/connection-id"
    }
  ]
}

Consultez Configuration de l'accès au référentiel pour plus de détails sur l'utilisation de ces intégrations.

Étapes suivantes