**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Configuración de los permisos de Argo CD
La capacidad administrada de Argo CD se integra con AWS Identity Center para la autenticación y utiliza roles de RBAC integrados para la autorización. En este tema, se explica cómo configurar los permisos para los usuarios y los equipos.
## Cómo funcionan los permisos con Argo CD
La capacidad de Argo CD utiliza AWS Identity Center para la autenticación y proporciona tres roles de RBAC integrados para la autorización.
Cuando un usuario accede a Argo CD:
1. Se autentican mediante AWS Identity Center (que puede federarse con su proveedor de identidad corporativa)
1. AWS Identity Center proporciona información sobre los usuarios y grupos a Argo CD
1. Argo CD asigna usuarios y grupos a roles de RBAC en función de su configuración
1. Los usuarios solo ven las aplicaciones y los recursos a los que tienen permiso de acceso
## Roles de RBAC integrados
La capacidad de Argo CD proporciona tres roles integrados que se asignan a los usuarios y grupos de AWS Identity Center. Son **roles con alcance global** que controlan el acceso a recursos de Argo CD, como proyectos, clústeres y repositorios.
**importante**
Los roles globales controlan el acceso a Argo CD en sí, no a recursos con alcance de proyecto, como las aplicaciones. Los usuarios Editor y Visualizador no pueden ver ni administrar aplicaciones de forma predeterminada; necesitan roles de proyecto para acceder a recursos con alcance de proyecto. Consulte [Roles de proyecto y acceso con alcance de proyecto](#project-roles) para obtener más información sobre cómo conceder acceso a las aplicaciones y a otros recursos con alcance de proyecto.
**ADMIN**
Acceso completo a todos los recursos y configuraciones de Argo CD:
+ Crear, actualizar y eliminar aplicaciones y ApplicationSets en cualquier proyecto
+ Administración de la configuración de Argo CD
+ Registro y administración de los clústeres de destino de la implementación
+ Configuración del acceso al repositorio
+ Crear y administrar proyectos
+ Visualización del estado y el historial de todas las aplicaciones
+ Enumerar y acceder a todos los clústeres y repositorios
**EDITOR**
Puede actualizar proyectos y configurar roles de proyecto, pero no puede modificar la configuración global de Argo CD:
+ Actualizar proyectos existentes (no puede crear ni eliminar proyectos)
+ Configurar roles y permisos de proyecto
+ Ver claves GPG y certificados
+ No puede modificar la configuración global de Argo CD
+ No puede administrar clústeres ni repositorios directamente
+ No puede ver ni administrar aplicaciones sin roles de proyecto
**VIEWER**
Acceso de solo lectura a los recursos de Argo CD:
+ Ver configuraciones de proyectos
+ Enumerar todos los proyectos (incluidos los proyectos a los que el usuario no está asignado)
+ Ver claves GPG y certificados
+ No puede enumerar clústeres ni repositorios
+ Imposibilidad de hacer cambios
+ No puede ver ni administrar aplicaciones sin roles de proyecto
**nota**
Para conceder a los usuarios Editor o Visualizador acceso a las aplicaciones, un Administrador o un Editor debe crear roles de proyecto que asignen grupos de Identity Center a permisos específicos dentro de un proyecto.
## Roles de proyecto y acceso con alcance de proyecto
Los roles globales Administrador, Editor y Visualizador controlan el acceso a Argo CD en sí. Los roles de proyecto controlan el acceso a los recursos y las capacidades dentro de un proyecto específico, incluidos:
+ **Recursos**: aplicaciones, ApplicationSets, credenciales de repositorios y credenciales de clústeres
+ **Capacidades**: acceso a registros y acceso de ejecución (exec) a los pods de aplicaciones
**Explicación del modelo de permisos de dos niveles**:
+ **Alcance global**: los roles integrados determinan lo que los usuarios pueden hacer con los proyectos, los clústeres, los repositorios y la configuración de Argo CD
+ **Alcance de proyecto**: los roles de proyecto determinan lo que los usuarios pueden hacer con los recursos y las capacidades dentro de un proyecto específico
Esto significa:
+ Los usuarios Administrador pueden acceder a todos los recursos y capacidades de los proyectos sin configuración adicional
+ Los usuarios Editor y Visualizador deben recibir roles de proyecto para acceder a los recursos y las capacidades del proyecto
+ Los usuarios Editor pueden crear roles de proyecto para concederse a sí mismos y a otros acceso dentro de los proyectos que pueden actualizar
**Flujo de trabajo de ejemplo**:
1. Un Administrador asigna un grupo de Identity Center al rol Editor a nivel global
1. Un Administrador crea un proyecto para un equipo
1. El Editor configura roles de proyecto dentro de ese proyecto para conceder a los miembros del equipo acceso a recursos con alcance de proyecto
1. Los miembros del equipo (que pueden tener el rol global Visualizador) ahora pueden ver y administrar aplicaciones en ese proyecto según los permisos de su rol de proyecto
Para obtener más información sobre la configuración de roles de proyecto, consulte [Control de acceso basado en proyectos](#_project_based_access_control).
## Configuración de las asignaciones de roles
Asigne los usuarios y grupos de AWS Identity Center a los roles de Argo CD al crear o actualizar la capacidad.
**Ejemplo de asignación de roles**:
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**nota**
Los nombres de los roles distinguen entre mayúsculas y minúsculas y deben estar en mayúsculas (ADMIN, EDITOR, VIEWER).
**importante**
La integración de capacidades de EKS con AWS Identity Center admite hasta 1000 identidades por capacidad de Argo CD. Una identidad puede ser un usuario o un grupo.
**Actualice las asignaciones de roles**:
```
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" }
]
}
]
}
}
}'
```
## Uso de la cuenta de administrador
La cuenta de administrador está diseñada para la configuración inicial y las tareas administrativas, como el registro de clústeres y la configuración de repositorios.
**Cuándo es adecuado usar la cuenta de administrador**:
+ Configuración inicial de la capacidad
+ Desarrollo individual o demostraciones rápidas
+ Tareas administrativas (registro de clústeres, configuración de repositorios, creación de proyectos)
**Prácticas recomendadas para la cuenta de administrador**:
+ No asigne tokens de la cuenta al control de versiones.
+ Cambie los tokens inmediatamente si se han expuesto.
+ Limite el uso de los tokens de la cuenta a las tareas administrativas y de configuración.
+ Establezca tiempos de vencimiento cortos (máximo 12 horas).
+ Solo se pueden crear 5 tokens de la cuenta en un momento determinado.
**Cuándo se usa el acceso basado en proyectos**:
+ Entornos de desarrollo compartidos con varios usuarios
+ Cualquier entorno que se asemeje al de producción
+ Cuando necesite registros de auditoría sobre quién llevó a cabo las acciones
+ Cuando necesite aplicar restricciones de recursos o límites de acceso
Para entornos de producción y escenarios de varios usuarios, utilice el control de acceso basado en proyectos con roles de RBAC dedicados asignados a grupos de AWS Identity Center.
## Control de acceso basado en proyectos
Utilice proyectos de Argo CD (AppProject) para proporcionar un control del acceso y un aislamiento de los recursos detallados para los equipos.
**importante**
Antes de asignar usuarios o grupos a roles específicos de proyecto, primero debe asignarlos a un rol global de Argo CD (Administrador, Editor o Visualizador) en la configuración de la capacidad. Los usuarios no pueden acceder a Argo CD sin una asignación a un rol global, incluso si están asignados a roles de proyecto.
Considere asignar a los usuarios el rol Visualizador a nivel global y, posteriormente, conceder permisos adicionales mediante roles específicos de proyecto. Esto proporciona un acceso básico y permite un control detallado a nivel de proyecto.
Los proyectos proporcionan lo siguiente:
+ **Restricciones de origen**: limite los repositorios de Git que se pueden usar.
+ **Restricciones de destino**: limite los clústeres y espacios de nombres que se pueden usar como destino.
+ **Restricciones de recursos**: limite los tipos de recursos de Kubernetes que se pueden implementar.
+ **Integración con RBAC**: asigne los proyectos a grupos de AWS Identity Center o roles de Argo CD.
**Ejemplo de proyecto para el aislamiento de equipos**:
```
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
```
### Espacios de nombres de origen
Cuando se utiliza la capacidad de Argo CD en EKS, el campo `spec.sourceNamespaces` es obligatorio en las definiciones de AppProject. Este campo especifica qué espacio de nombres puede contener aplicaciones o ApplicationSets que hagan referencia a este proyecto.
**importante**
La capacidad de Argo CD en EKS solo admite un único espacio de nombres para las aplicaciones y los ApplicationSets: el espacio de nombres que especificó al crear la capacidad (normalmente, `argocd`). Esto difiere de Argo CD de código abierto, que admite múltiples espacios de nombres.
**Configuración de AppProject**
Todos los AppProjects deben incluir el espacio de nombres configurado de la capacidad en `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
```
**nota**
Si omite el espacio de nombres de la capacidad en `sourceNamespaces`, las aplicaciones o los ApplicationSets de ese espacio de nombres no podrán hacer referencia a este proyecto, lo que provocará errores en la implementación.
**Asigne usuarios a los proyectos**:
Los roles de proyecto conceden a los usuarios Editor y Visualizador acceso a los recursos del proyecto (aplicaciones, ApplicationSets y credenciales de repositorios y clústeres) y a las capacidades (registros y ejecución [exec]). Sin roles de proyecto, estos usuarios no pueden acceder a estos recursos, incluso si tienen acceso mediante un rol global.
Los usuarios Administrador tienen acceso a todas las aplicaciones sin necesidad de roles de proyecto.
**Ejemplo: concesión de acceso a aplicaciones a los miembros del equipo**
```
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
```
**nota**
Incluya `clusters, get, *, allow` en los roles de proyecto para permitir que los usuarios vean los nombres de los clústeres en la interfaz de usuario. Sin este permiso, el clúster de destino aparece como “desconocido”.
**Explicación sobre las políticas de los roles de proyecto**:
El formato de la política es: `p, proj::, , ,