

 **Ajudar a melhorar esta página** 

Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.

# Registro de clusters de destino
<a name="argocd-register-clusters"></a>

Registre clusters para permitir que o Argo CD implante aplicações neles. É possível registrar o mesmo cluster em que o Argo CD está em execução (cluster local) ou clusters remotos em diferentes contas ou regiões. Depois que um cluster for registrado, ele permanecerá em um estado de conexão desconhecido até que você crie uma aplicação dentro desse cluster. Para criar uma aplicação do Argo CD após o registro do cluster, consulte [Criação de Applications](argocd-create-application.md).

## Pré-requisitos
<a name="_prerequisites"></a>
+ Um cluster de EKS com a funcionalidade para o Argo CD criada
+  `kubectl` configurado para o estabelecimento de comunicação com o cluster
+ Para clusters remotos: permissões do IAM e entradas de acesso adequadas

## Registro do cluster local
<a name="_register_the_local_cluster"></a>

Para implantar aplicações no mesmo cluster em que o Argo CD está em execução, registre-o como um destino de implantação.

**Importante**  
A funcionalidade do Argo CD não realiza o registro automático do cluster local. É necessário registrá-lo explicitamente para fazer a implantação de aplicações no mesmo cluster. É possível usar o nome `in-cluster` do cluster para compatibilidade com a maioria dos exemplos do Argo CD online.

**nota**  
Uma entrada de acesso EKS é criada automaticamente para o cluster local com o perfil de funcionalidade do Argo CD, mas nenhuma permissão RBAC do Kubernetes é concedida por padrão. Isso segue o princípio do privilégio mínimo, sendo necessário configurar explicitamente as permissões que o Argo CD precisa com base no seu caso de uso. Por exemplo, se você usar esse cluster apenas como um hub do Argo CD para gerenciar clusters remotos, ele não precisará de nenhuma permissão de implantação local. Consulte a seção Requisitos de entrada de acesso do RBAC abaixo para ver as opções de configuração.

 **Com a CLI do Argo CD**:

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

 **Com um Kubernetes Secret**:

```
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 a configuração:

```
kubectl apply -f local-cluster.yaml
```

**nota**  
Use o ARN do cluster de EKS no campo `server`, e não o URL do servidor da API do Kubernetes. A funcionalidade gerenciada requer ARNs para identificar os clusters. O valor padrão `kubernetes.default.svc` não é compatível.

## Registro de clusters remotos
<a name="_register_remote_clusters"></a>

Para implantar em clusters remotos:

 **Etapa 1: criação da entrada de acesso no cluster remoto** 

Substitua *region-code* pela região da AWS em que seu cluster remoto está, substitua *remote-cluster* pelo nome do cluster remoto e substitua o ARN pelo ARN do perfil da funcionalidade para o 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
```

 **Etapa 2: associar uma política de acesso às permissões de RBAC do Kubernetes** 

A entrada de acesso requer permissões do Kubernetes RBAC para o Argo CD implantar aplicações. Para começar a usar rapidamente, é possível utilizar a `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**  
A `AmazonEKSClusterAdminPolicy` fornece acesso total ao administrador do cluster (equivalente a `system:masters`). Isso é conveniente para começar, mas não deve ser usado em produção. Para ambientes de produção, use permissões mais restritivas associando a entrada de acesso a grupos personalizados do Kubernetes e criando associações apropriadas de Role ou ClusterRole. Consulte a seção de configuração de produção abaixo para ver a configuração de privilégios mínimos.

 **Etapa 3: registro do cluster no Argo CD** 

 **Com a CLI do Argo CD**:

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

 **Com um Kubernetes Secret**:

```
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 a configuração:

```
kubectl apply -f remote-cluster.yaml
```

## Clusters entre contas
<a name="_cross_account_clusters"></a>

Para realizar a implantação em clusters localizados em contas da AWS distintas:

1. Na conta de destino, crie uma entrada de acesso no cluster de destino do EKS usando o ARN do perfil da funcionalidade do IAM do Argo CD da conta de origem como a entidade principal

1. Associe uma política de acesso com as permissões RBAC apropriadas do Kubernetes

1. Registre o cluster no Argo CD usando o ARN do cluster de EKS

Não é necessária a criação de perfis do IAM adicionais nem a configuração de política de confiança. As entradas de acesso do EKS gerenciam o acesso entre contas.

O formato do ARN do cluster inclui a região; portanto, implantações entre regiões seguem o mesmo processo das implantações na mesma região.

## Verificação do registro do cluster
<a name="_verify_cluster_registration"></a>

Consulte os clusters que estão registrados:

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

Como opção, verifique o status do cluster na interface do Argo CD em Configurações → Clusters.

## Clusters privados
<a name="_private_clusters"></a>

A funcionalidade do Argo CD fornece acesso transparente a clusters de EKS totalmente privados, sem exigir emparelhamento da VPC ou configurações de rede especializadas.

 A AWS gerencia automaticamente a conectividade entre a funcionalidade do Argo CD e os clusters remotos privados.

Basta registrar o cluster privado usando seu ARN. Nenhuma configuração de rede adicional é necessária.

## Requisitos do RBAC de entrada de acesso
<a name="_access_entry_rbac_requirements"></a>

Quando você cria uma funcionalidade do Argo CD, uma entrada de acesso do EKS é criada automaticamente para o perfil de funcionalidade, mas nenhuma permissão de RBAC do Kubernetes é concedida por padrão. Esse design intencional segue o princípio de privilégio mínimo, em que diferentes casos de uso exigem permissões diferentes.

Por exemplo: \$1 Se você usar o cluster somente como um hub do Argo CD para gerenciar clusters remotos, ele não precisará de permissões de implantação locais \$1 Se você implantar aplicações localmente, ele precisará de acesso de leitura em todo o cluster e acesso de gravação a namespaces específicos \$1 Se for preciso criar CRDs, serão necessárias permissões adicionais de administrador de cluster

É necessário configurar explicitamente as permissões que o Argo CD precisa com base em seus requisitos.

### Permissões mínimas para o Argo CD
<a name="_minimum_permissions_for_argo_cd"></a>

O Argo CD precisa de dois tipos de permissões para funcionar sem erros:

 **Permissões de leitura (em todo o cluster)**: o Argo CD deve ser capaz de ler todos os tipos de recursos e definições de recursos personalizadas (CRDs) em todo o cluster para:
+ Descoberta de recursos e verificações de integridade
+ Detecção do desvio entre o estado desejado e o real
+ Validação de recursos antes da implantação

 **Permissões de gravação (específicas do namespace)**: o Argo CD precisa criar, atualizar e excluir permissões para recursos definidos em Applications:
+ Implantar workloads de aplicações (implantações, serviços, ConfigMaps etc.)
+ Aplicar recursos personalizados (CRDs específicos para suas aplicações)
+ Gerenciamento do ciclo de vida do aplicação

### Configuração rápida
<a name="_quick_setup"></a>

Para começar rapidamente, testar ou desenvolver ambientes, use a `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**  
A `AmazonEKSClusterAdminPolicy` fornece acesso total ao administrador do cluster (equivalente a `system:masters`), incluindo a capacidade de criar CRDs, modificar recursos em todo o cluster e implantar em qualquer namespace. Isso é conveniente para desenvolvimento e POCs, mas não deve ser usado em ambientes de produção. Para produção, use a configuração de privilégios mínimos abaixo.

### Configuração de produção com privilégio mínimo
<a name="_production_setup_with_least_privilege"></a>

Para ambientes de produção, crie um RBAC personalizado do Kubernetes que conceda:
+ Acesso de leitura em todo o cluster a todos os recursos (para descobertas e verificações de integridade)
+ Acesso de gravação específico ao namespace (para implantações)

 **Etapa 1: associar a entrada de acesso a um grupo de Kubernetes personalizado** 

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

 **Etapa 2: criar um ClusterRole para acesso de leitura** 

```
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"]
```

 **Etapa 3: criar um perfil para acesso de gravação aos namespaces da aplicação** 

```
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: ["*"]
```

 **Etapa 4: vincular perfis ao 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**  
O formato do nome do grupo para entradas de acesso é `eks-access-entry:` seguido pelo ARN principal. Repita o RoleBinding para cada namespace em que o Argo CD deva implantar aplicações.

**Importante**  
O Argo CD deve ser capaz de ler todos os tipos de recursos em todo o cluster para verificações de integridade e descoberta, mesmo que seja implantado apenas em namespaces específicos. Sem acesso de leitura em todo o cluster, o Argo CD mostrará erros ao verificar a integridade da aplicação.

## Restrição do acesso ao cluster com o Projects
<a name="_restrict_cluster_access_with_projects"></a>

Use Projects para controlar em quais clusters e namespaces as Applications podem ser implantadas configurando os clusters e namespaces de destino permitidos em `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 obter detalhes, consulte [Trabalho com o Argo CD Projects](argocd-projects.md).

## Recursos adicionais
<a name="_additional_resources"></a>
+  [Trabalho com o Argo CD Projects](argocd-projects.md): organize as Applications e aplique limites de segurança
+  [Criação de Applications](argocd-create-application.md): implante sua primeira aplicação
+  [Uso de ApplicationSets](argocd-applicationsets.md): realize implantações em vários clusters com ApplicationSets
+  [Considerações sobre o Argo CD](argocd-considerations.md): acesse padrões com vários clusters e a configuração entre contas
+  [Declarative Cluster Setup](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#clusters): acesse a referência de configuração da versão original do cluster