Requisitos previos Registro del clúster local Registro de clústeres remotos Clústeres entre cuentas Comprobación del registro del clúster Clústeres privados Requisitos de control de acceso basado en roles de la entrada de acceso Restricción del acceso al clúster con proyectos Recursos adicionales

Registro de clústeres de destino

Registre los clústeres para que Argo CD pueda implementar aplicaciones en ellos. Puede registrar el mismo clúster en el que se ejecuta Argo CD (clúster local) o clústeres remotos en cuentas o regiones diferentes. Una vez que se registre un clúster, permanecerá en estado de conexión “Desconocido” hasta que cree una aplicación dentro de ese clúster. Para crear una aplicación de Argo CD después de que el clúster esté registrado, consulte Creación de aplicaciones.

Requisitos previos

Un clúster de EKS con la capacidad de Argo CD creada
kubectl configurado para comunicarse con el clúster
Para clústeres remotos: permisos de IAM y entradas de acceso adecuados

Registro del clúster local

Para implementar aplicaciones en el mismo clúster en el que se ejecuta Argo CD, regístrelo como destino de implementación.

importante

La capacidad de Argo CD no registra automáticamente el clúster local. Debe registrarlo de forma explícita para implementar aplicaciones en el mismo clúster. Puede utilizar el nombre del clúster in-cluster para garantizar la compatibilidad con la mayoría de los ejemplos de Argo CD disponibles en línea.

nota

Se crea automáticamente una entrada de acceso de EKS para el clúster local con el rol de la capacidad de Argo CD, pero no se conceden permisos de control de acceso basado en roles de Kubernetes de forma predeterminada. Esto sigue el principio de privilegio mínimo; debe configurar explícitamente los permisos que Argo CD necesita según el caso de uso. Por ejemplo, si solo utiliza este clúster como centro de Argo CD para administrar clústeres remotos, no necesita permisos de implementación locales. Consulte la sección Requisitos de control de acceso basado en roles (RBAC) de la entrada de acceso que figura a continuación para conocer las opciones de configuración.

Uso de la CLI de Argo CD:


argocd cluster add <cluster-context-name> \
  --aws-cluster-name arn:aws:eks:us-west-2:111122223333:cluster/my-cluster \
  --name local-cluster

Uso de un secreto de Kubernetes:


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

Aplique la configuración:


kubectl apply -f local-cluster.yaml

nota

Use el ARN del clúster de EKS en el campo server, no la URL del servidor de API de Kubernetes. La capacidad administrada requiere que los ARN identifiquen los clústeres. El kubernetes.default.svc predeterminado no es compatible.

Registro de clústeres remotos

Para implementar en clústeres remotos:

Paso 1: creación de la entrada de acceso en el clúster remoto

Reemplace region-code por la región de AWS en la que está el clúster remoto, sustituya remote-cluster por el nombre del clúster remoto y el ARN por el ARN del rol de capacidad de Argo CD.


aws eks create-access-entry \
  --region region-code \
  --cluster-name remote-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --type STANDARD

Paso 2: Asociar una política de acceso con permisos de control de acceso basado en roles de Kubernetes

La entrada de acceso requiere permisos de control de acceso basado en roles de Kubernetes para que Argo CD pueda implementar aplicaciones. Para comenzar rápidamente, puede utilizar la AmazonEKSClusterAdminPolicy:


aws eks associate-access-policy \
  --region region-code \
  --cluster-name remote-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

importante

La AmazonEKSClusterAdminPolicy proporciona acceso completo de administrador del clúster (equivalente a system:masters). Esto resulta conveniente para comenzar, pero no se debe utilizar en entornos de producción. Para entornos de producción, utilice permisos más restrictivos mediante la asociación de la entrada de acceso con grupos personalizados de Kubernetes y la creación de las vinculaciones adecuadas de Role o ClusterRole. Consulte la sección de configuración para entornos de producción que figura a continuación para aplicar el principio de privilegio mínimo.

Paso 3: registro del clúster en Argo CD

Uso de la CLI de Argo CD:


argocd cluster add <cluster-context-name> \
  --aws-cluster-name arn:aws:eks:us-west-2:111122223333:cluster/remote-cluster \
  --name remote-cluster

Uso de un secreto de Kubernetes:


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

Aplique la configuración:


kubectl apply -f remote-cluster.yaml

Clústeres entre cuentas

Para implementar en clústeres de diferentes cuentas de AWS:

En la cuenta de destino, cree una entrada de acceso en el clúster de EKS de destino y use como entidad principal el ARN del rol de IAM de la capacidad de Argo CD de la cuenta de origen.
Asocie una política de acceso con los permisos adecuados de control de acceso basado en roles de Kubernetes
Registre el clúster en Argo CD con su ARN de clúster de EKS

No es necesario crear roles de IAM adicionales ni configurar ninguna política de confianza: las entradas de acceso de EKS gestionan el acceso entre cuentas.

El formato del ARN del clúster incluye la región, por lo que las implementaciones entre regiones siguen el mismo proceso que las implementaciones en la misma región.

Comprobación del registro del clúster

Consulte los clústeres registrados:


kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=cluster

O bien, compruebe el estado del clúster en la interfaz de usuario de Argo CD, en Configuración → Clústeres.

Clústeres privados

La capacidad de Argo CD proporciona un acceso transparente a clústeres de EKS totalmente privados sin necesidad de emparejamiento de VPC ni una configuración de red especializada.

AWS administra automáticamente la conectividad entre la capacidad de Argo CD y los clústeres remotos privados.

Solo tiene que registrar el clúster privado con su ARN, sin necesidad de aplicar ninguna configuración de red adicional.

Requisitos de control de acceso basado en roles de la entrada de acceso

Cuando crea una capacidad de Argo CD, se crea automáticamente una entrada de acceso de EKS para el rol de la capacidad, pero no se conceden permisos de control de acceso basado en roles de Kubernetes de forma predeterminada. Este diseño intencional sigue el principio de privilegio mínimo; los distintos casos de uso requieren permisos diferentes.

Por ejemplo: * Si utiliza el clúster solo como centro de Argo CD para administrar clústeres remotos, no necesita permisos de implementación locales. * Si implementa aplicaciones de forma local, necesita acceso de lectura en todo el clúster y acceso de escritura en espacios de nombres específicos. * Si necesita crear definiciones de recursos personalizados, requiere permisos adicionales de administrador del clúster.

Debe configurar explícitamente los permisos que Argo CD necesita según sus requisitos.

Permisos mínimos para Argo CD

Argo CD necesita dos tipos de permisos para funcionar sin errores:

Permisos de lectura (en todo el clúster): Argo CD debe poder leer todos los tipos de recursos y las definiciones de recursos personalizados (CRD) en el clúster para:

Detección de recursos y comprobaciones de estado
Detección de desviaciones entre el estado deseado y el estado real
Validación de los recursos antes de la implementación

Permisos de escritura (específicos de espacio de nombres): Argo CD necesita permisos para crear, actualizar y eliminar recursos definidos en las aplicaciones para:

Implementar cargas de trabajo de aplicaciones (implementaciones, servicios, ConfigMaps, etc.)
Aplicar recursos personalizados (CRD específicos de las aplicaciones)
Administrar el ciclo de vida de las aplicaciones

Configuración rápida

Para comenzar rápidamente, realizar pruebas o trabajar en entornos de desarrollo, utilice AmazonEKSClusterAdminPolicy:


aws eks associate-access-policy \
  --region region-code \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

importante

La AmazonEKSClusterAdminPolicy proporciona acceso completo de administrador del clúster (equivalente a system:masters), incluida la capacidad de crear definiciones de recursos personalizados, modificar recursos en todo el clúster e implementar en cualquier espacio de nombres. Esto resulta conveniente para desarrollo y pruebas de concepto, pero no se debe utilizar en producción. Para producción, utilice la configuración de privilegio mínimo que figura a continuación.

Configuración para producción con privilegio mínimo

Para entornos de producción, cree una configuración personalizada de control de acceso basado en roles de Kubernetes que conceda:

Acceso de lectura en todo el clúster a todos los recursos (para detección y comprobaciones de estado)
Acceso de escritura específico de espacio de nombres (para implementaciones)

Paso 1: Asocie la entrada de acceso a un grupo personalizado de Kubernetes


aws eks associate-access-policy \
  --region region-code \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \
  --access-scope type=namespace,namespaces=app-namespace

Paso 2: Cree un ClusterRole para el acceso de lectura


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: argocd-read-all
rules:
# Read access to all resources for discovery and health checks
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

Paso 3: Cree un rol para el acceso de escritura en los espacios de nombres de la aplicación


apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: argocd-deploy
  namespace: app-namespace
rules:
# Full access to deploy application resources
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Paso 4: Vincule los roles al grupo de Kubernetes


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: argocd-read-all
subjects:
- kind: Group
  name: eks-access-entry:arn:aws:iam::111122223333:role/ArgoCDCapabilityRole
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: argocd-read-all
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: argocd-deploy
  namespace: app-namespace
subjects:
- kind: Group
  name: eks-access-entry:arn:aws:iam::111122223333:role/ArgoCDCapabilityRole
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: argocd-deploy
  apiGroup: rbac.authorization.k8s.io

nota

El formato del nombre de grupo para las entradas de acceso es eks-access-entry: seguido del ARN de la entidad principal. Repita el RoleBinding para cada espacio de nombres en el que Argo CD deba implementar aplicaciones.

importante

Argo CD debe poder leer todos los tipos de recursos en el clúster para realizar comprobaciones de estado y detección, incluso si solo implementa en espacios de nombres específicos. Sin acceso de lectura en todo el clúster, Argo CD generará errores al verificar el estado de las aplicaciones.

Restricción del acceso al clúster con proyectos

Utilice los proyectos para controlar en qué clústeres y espacios de nombres se pueden implementar las aplicaciones mediante la configuración de los clústeres y espacios de nombres de destino permitidos en spec.destinations:


apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  destinations:
  - server: arn:aws:eks:us-west-2:111122223333:cluster/prod-cluster
    namespace: '*'
  - server: arn:aws:eks:eu-west-1:111122223333:cluster/prod-eu-cluster
    namespace: '*'
  sourceRepos:
  - 'https://github.com/example/production-apps'

Para obtener más información, consulte Uso de proyectos de Argo CD.

Recursos adicionales

Uso de proyectos de Argo CD: organización de las aplicaciones y aplicación de los límites de seguridad
Creación de aplicaciones: implementación de su primera aplicación
Uso de ApplicationSets: implementación en varios clústeres con ApplicationSets
Consideraciones sobre Argo CD: patrones de varios clústeres y configuración entre cuentas
Declarative Cluster Setup: referencia de la configuración del clúster ascendente

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Configuración de repositorios

Proyectos