**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. # 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](argocd-create-application.md). ## 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 \ --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 \ --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: 1. 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. 1. Asocie una política de acceso con los permisos adecuados de control de acceso basado en roles de Kubernetes 1. 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: \$1 Si utiliza el clúster solo como centro de Argo CD para administrar clústeres remotos, no necesita permisos de implementación locales. \$1 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. \$1 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](argocd-projects.md). ## Recursos adicionales + [Uso de proyectos de Argo CD](argocd-projects.md): organización de las aplicaciones y aplicación de los límites de seguridad + [Creación de aplicaciones](argocd-create-application.md): implementación de su primera aplicación + [Uso de ApplicationSets](argocd-applicationsets.md): implementación en varios clústeres con ApplicationSets + [Consideraciones sobre Argo CD](argocd-considerations.md): patrones de varios clústeres y configuración entre cuentas + [Declarative Cluster Setup](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#clusters): referencia de la configuración del clúster ascendente