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.

ADMINISTRATEUR

Accès complet à toutes les applications et à tous les paramètres :

RÉDACTEUR

Peut créer et modifier des applications, mais ne peut pas modifier les paramètres d'Argo CD :

SPECTATEUR

Accès en lecture seule aux applications :

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 eksfe 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

  # 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

Affecter des utilisateurs à des projets :

Les utilisateurs dotés de rôles EDITOR ou VIEWER peuvent être limités à des projets spécifiques. Les utilisateurs ADMIN ont accès à tous les projets.

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

  # Map Identity Center groups to project roles
  roles:
  - name: developer
    description: Team A developers
    policies:
    - p, proj:team-a:developer, applications, *, team-a/*, allow
    groups:
    - TeamADevelopers

  - name: viewer
    description: Team A viewers
    policies:
    - p, proj:team-a:viewer, applications, get, team-a/*, allow
    groups:
    - TeamAViewers

Modèles d'autorisation courants

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

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

Schéma 2 : les développeurs peuvent déployer, les autres peuvent visualiser

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["PlatformTeam"],
    "EDITOR": ["DevelopmentTeam", "DevOpsTeam"],
    "VIEWER": ["AllEmployees"]
  }
}

Schéma 3 : isolement basé sur l'équipe avec les projets

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

Créez ensuite des projets avec des restrictions et des mappages de rôles spécifiques à l'équipe.

Bonnes pratiques

Utilisez des groupes plutôt que des utilisateurs individuels : associez des groupes AWS Identity Center à des rôles Argo CD plutôt qu'à des 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