**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.

# Trabalho com o Argo CD Projects
<a name="argocd-projects"></a>

O Argo CD Projects (AppProject) oferece agrupamento lógico e controle de acesso para Applications. Os projetos definem quais repositórios do Git, clusters de destino e namespaces podem ser usados pelas Applications, viabilizando multilocação e limites de segurança em instâncias compartilhadas do Argo CD.

## Situações para o uso do Argo CD Projects
<a name="_when_to_use_projects"></a>

Use o Projects para:
+ Separar aplicações por equipe, ambiente ou unidade de negócio
+ Restringir de quais repositórios as equipes podem realizar a implantação
+ Limitar para quais clusters e namespaces as equipes podem realizar a implantação
+ Aplicar cotas de recursos e tipos de recursos permitidos
+ Fornecer implantação de aplicações de autoatendimento com barreiras de proteção

## Projeto padrão
<a name="_default_project"></a>

Cada funcionalidade do Argo CD inclui um projeto `default` que permite acesso a todos os repositórios, clusters e namespaces. Apesar de ser útil para testes iniciais, crie Argo CD Projects dedicados com restrições específicas para o uso em produção.

Para obter detalhes sobre a configuração do projeto padrão e como restringi-lo, consulte [The Default Project](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#the-default-project) na documentação do Argo CD.

## Criar um projeto
<a name="_create_a_project"></a>

Crie um Argo CD Project por meio da aplicação de um recurso `AppProject` em seu cluster.

 **Exemplo: projeto específico por equipe** 

```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  description: Applications for Team A

  # Source repositories this project can deploy from
  sourceRepos:
    - 'https://github.com/my-org/team-a-*'
    - 'https://github.com/my-org/shared-libs'

  # Destination clusters and namespaces
  destinations:
    - name: dev-cluster
      namespace: team-a-dev
    - name: prod-cluster
      namespace: team-a-prod

  # Allowed resource types
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace

  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service
    - group: ''
      kind: ConfigMap
```

Aplique o Project:

```
kubectl apply -f team-a-project.yaml
```

## Configuração de projetos
<a name="_project_configuration"></a>

### Repositórios de origem
<a name="_source_repositories"></a>

Controle quais repositórios do Git podem ser usados por Applications neste projeto:

```
spec:
  sourceRepos:
    - 'https://github.com/my-org/app-*'  # Wildcard pattern
    - 'https://github.com/my-org/infra'  # Specific repo
```

É possível empregar caracteres curinga e padrões de negação (prefixo `!`) para permitir ou bloquear repositórios específicos. Para obter detalhes, consulte [Managing Projects](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#managing-projects) na documentação do Argo CD.

### Restrições de destinos
<a name="_destination_restrictions"></a>

Limite o local em que as Applications podem ser implantadas:

```
spec:
  destinations:
    - name: prod-cluster  # Specific cluster by name
      namespace: production
    - name: '*'  # Any cluster
      namespace: team-a-*  # Namespace pattern
```

**Importante**  
Use nomes de clusters específicos e padrões de namespace em vez de caracteres curingas para Projects destinados a ambientes de produção. Isso impede a implantação acidental em clusters ou namespaces não autorizados.

É possível usar caracteres curinga e padrões de negação para controlar os destinos. Para obter detalhes, consulte [Managing Projects](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#managing-projects) na documentação do Argo CD.

### Restrições de recursos
<a name="_resource_restrictions"></a>

Controle quais tipos de recursos do Kubernetes podem ser implantados:

 **Recursos com escopo de cluster**:

```
spec:
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
    - group: 'rbac.authorization.k8s.io'
      kind: Role
```

 **Recursos com escopo de namespace**:

```
spec:
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service
    - group: ''
      kind: ConfigMap
    - group: 's3.services.k8s.aws'
      kind: Bucket
```

Use listas de restrições para negar recursos específicos:

```
spec:
  namespaceResourceBlacklist:
    - group: ''
      kind: Secret  # Prevent direct Secret creation
```

## Atribuição de Applications a Projects
<a name="_assign_applications_to_projects"></a>

Ao criar uma Application, especifique o projeto no campo `spec.project`:

```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: team-a  # Assign to team-a project
  source:
    repoURL: https://github.com/my-org/my-app
    path: manifests
  destination:
    name: prod-cluster
    namespace: team-a-prod
```

As Applications sem um projeto especificado usam o projeto `default`.

## Perfis de projeto e RBAC
<a name="_project_roles_and_rbac"></a>

Os Projects podem definir perfis personalizados para um controle de acesso mais preciso. Mapeie os perfis do projeto para usuários e grupos do Centro de Identidade da AWS na configuração de funcionalidades para controlar as pessoas com permissões para sincronizar, atualizar ou excluir aplicações.

 **Exemplo: Project com perfis de desenvolvedor e de administrador** 

```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  sourceRepos:
    - '*'
  destinations:
    - name: '*'
      namespace: 'team-a-*'

  roles:
    - name: developer
      description: Developers can sync applications
      policies:
        - p, proj:team-a:developer, applications, sync, team-a/*, allow
        - p, proj:team-a:developer, applications, get, team-a/*, allow
      groups:
        - team-a-developers

    - name: admin
      description: Admins have full access
      policies:
        - p, proj:team-a:admin, applications, *, team-a/*, allow
      groups:
        - team-a-admins
```

Para obter detalhes sobre os perfis de projeto, tokens JWT para pipelines de CI/CD e configuração de RBAC, consulte [Project Roles](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-roles) na documentação do Argo CD.

## Padrões comuns
<a name="_common_patterns"></a>

### Projects com base no ambiente
<a name="_environment_based_projects"></a>

Crie projetos separados para cada ambiente:

```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/*'
  destinations:
    - name: prod-cluster
      namespace: '*'
  # Strict resource controls for production
  clusterResourceWhitelist: []
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service
```

### Projects com base em equipe
<a name="_team_based_projects"></a>

Isole as equipes com projetos dedicados:

```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform-team
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/platform-*'
  destinations:
    - name: '*'
      namespace: 'platform-*'
  # Platform team can manage cluster resources
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'
```

### Projects com vários clusters
<a name="_multi_cluster_projects"></a>

Faça a implantação em vários clusters utilizando políticas consistentes:

```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: global-app
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/global-app'
  destinations:
    - name: us-west-cluster
      namespace: app
    - name: eu-west-cluster
      namespace: app
    - name: ap-south-cluster
      namespace: app
```

## Práticas recomendadas
<a name="_best_practices"></a>

 **Comece com Projects restritivos**: comece com permissões limitadas e expanda conforme necessário, em vez de começar com acesso amplo.

 **Use padrões de namespace**: use curingas nas restrições de namespace (como `team-a-*`) para permitir flexibilidade e, ao mesmo tempo, manter os limites.

 **Projetos separados para ambientes de produção**: use projetos dedicados para produção com controles mais rigorosos e políticas de sincronização manual.

 **Documente os objetivos do Project**: use o campo `description` para explicar a finalidade de cada projeto e quem deve usá-lo.

 **Analise as permissões do Project regularmente**: audite os Projects periodicamente para garantir que as restrições ainda estejam alinhadas com as necessidades da equipe e os requisitos de segurança.

## Recursos adicionais
<a name="_additional_resources"></a>
+  [Configuração das permissões do Argo CD](argocd-permissions.md): configure o RBAC e a integração com o Centro de Identidade
+  [Criação de Applications](argocd-create-application.md): crie Applications em Projects
+  [Uso de ApplicationSets](argocd-applicationsets.md): use ApplicationSets com os Projects para realizar implantações em vários clusters
+  [Documentação do Argo CD Projects](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/): acesse a referência oficial completa