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.

Configurer les autorisations d'Argo CD

La fonctionnalité gérée d'Argo CD s'intègre à AWS Identity Center pour l'authentification et utilise les 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 :

Built-in Rôles RBAC

La fonctionnalité Argo CD fournit trois rôles intégrés que vous associez 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 paramètres d'Argo CD :

RÉDACTEUR

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

VISIONNEUR

Read-only accès aux ressources d'Argo CD :

Rôles du projet et accès limité au 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 fonctionnalités 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 de projet, consultezProject-based contrôle d'accès.

Configuration des mappages de rôles

Associez les utilisateurs et les groupes AWS 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  :

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

Mettez à jour les mappages de rôles :

aws eks update-capability \
  --region us-east-1 \
  --cluster-name cluster \
  --capability-name capname \
  --role-arn "arn:aws:iam::111122223333:role/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é  :

Meilleures pratiques pour le compte administrateur  :

Quand utiliser plutôt l'accès basé sur les projets :

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

Project-based contrôle d'accès

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 les équipes  :

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é de 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

Attribuez des utilisateurs à des projets  :

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

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 relatives aux capacités  :

Modèles d'autorisation courants

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

{
  "rbacRoleMappings": {
    "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 des rôles de projet

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

Modèle 3 : Team-based accès avec rôles de projet

{
  "rbacRoleMappings": {
    "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 minimum 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 d'Argo CD, mais ne correspond pas au RBAC Kubernetes. Les utilisateurs ayant 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 AWS les 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 la section pour en savoir plus sur l'utilisation de ces intégrations.

Étapes suivantes