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

# Uso de proyectos de Argo CD
<a name="argocd-projects"></a>

Los proyectos de Argo CD (AppProjects) proporcionan agrupamiento lógico y control de acceso para las aplicaciones. Los proyectos definen qué repositorios de Git, clústeres de destino y espacios de nombres pueden usar las aplicaciones, lo que habilita la multitenencia y los límites de seguridad en las instancias de Argo CD compartidas.

## Cuándo se usan los proyectos
<a name="_when_to_use_projects"></a>

Use los proyectos en los siguientes casos:
+ Separación de aplicaciones por equipo, entorno o unidad de negocio
+ Restricción de los repositorios desde los que los equipos pueden implementar
+ Limitación de los clústeres y espacios de nombres en los que los equipos pueden implementar
+ Aplicación de cuotas de recursos y tipos de recursos permitidos
+ Concesión de acceso a la implementación de aplicaciones de autoservicio con barreras de protección

## Proyecto predeterminado
<a name="_default_project"></a>

Cada capacidad de Argo CD incluye un proyecto `default` que permite el acceso a todos los repositorios, clústeres y espacios de nombres. Si bien es útil para las pruebas iniciales, cree proyectos dedicados con restricciones explícitas para su uso en producción.

Para obtener más información sobre la configuración predeterminada del proyecto y cómo restringirla, consulte [The Default Project](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#the-default-project) en la documentación de Argo CD.

## Creación de un proyecto
<a name="_create_a_project"></a>

Para crear un proyecto, aplique un recurso de `AppProject` al clúster.

 **Ejemplo: proyecto específico de un equipo** 

```
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 el proyecto:

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

## Configuración del proyecto
<a name="_project_configuration"></a>

### Repositorios de código fuente
<a name="_source_repositories"></a>

Controle qué repositorios de Git pueden usar las aplicaciones de este proyecto:

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

Puede usar comodines y patrones de negación (prefijo `!`) para permitir o denegar repositorios específicos. Para obtener más información, consulte [Managing Projects](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#managing-projects) en la documentación de Argo CD.

### Restricciones de destino
<a name="_destination_restrictions"></a>

Limite dónde se pueden implementar las aplicaciones:

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

**importante**  
Utilice nombres de clústeres y patrones de espacios de nombres específicos en lugar de comodines para los proyectos de producción. De este modo, se impiden las implementaciones accidentales en clústeres o espacios de nombres no autorizados.

Puede utilizar comodines y patrones de negación para controlar los destinos. Para obtener más información, consulte [Managing Projects](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#managing-projects) en la documentación de Argo CD.

### Restricciones de recursos
<a name="_resource_restrictions"></a>

Controle qué tipos de recursos de Kubernetes se pueden implementar:

 **Recursos basados en clústeres**:

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

 **Recursos basados en espacios de nombres**:

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

Use listas de elementos prohibidos para denegar recursos específicos:

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

## Asignación de aplicaciones a proyectos
<a name="_assign_applications_to_projects"></a>

Al crear una aplicación, especifique el proyecto en el 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
```

Las aplicaciones sin un proyecto específico utilizan el proyecto `default`.

## Roles del proyecto y RBAC
<a name="_project_roles_and_rbac"></a>

Los proyectos pueden definir roles personalizados para el control de acceso detallado. Asigne roles del proyecto a los usuarios y grupos de AWS Identity Center según la configuración de la capacidad para controlar quién puede sincronizar, actualizar o eliminar aplicaciones.

 **Ejemplo: proyecto con roles de desarrollador y 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 obtener más información sobre los roles del proyecto, los tokens JWT para las canalizaciones de CI/CD y la configuración d RBAC, consulte [Project Roles](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-roles) en la documentación de Argo CD.

## Patrones comunes
<a name="_common_patterns"></a>

### Proyectos basados en entornos
<a name="_environment_based_projects"></a>

Cree proyectos separados para cada entorno:

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

### Proyectos basados en equipos
<a name="_team_based_projects"></a>

Aísle los equipos con proyectos específicos:

```
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: '*'
```

### Proyectos de varios clústeres
<a name="_multi_cluster_projects"></a>

Implemente en varios clústeres con políticas coherentes:

```
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ácticas recomendadas
<a name="_best_practices"></a>

 **Comience con proyectos restrictivos**: comience con permisos limitados y amplíelos según sea necesario en lugar de comenzar con un acceso amplio.

 **Utilice patrones de espacios de nombres**: use los comodines en las restricciones de los espacios de nombres (por ejemplo, `team-a-*`) para ofrecer flexibilidad mientras mantiene los límites.

 **Separe los proyectos de producción**: utilice proyectos específicos para la producción con controles más estrictos y políticas de sincronización manual.

 **Documente los propósitos del proyecto**: utilice el campo `description` para explicar para qué sirve cada proyecto y quién debe usarlo.

 **Revise los permisos del proyecto con regularidad**: audite los proyectos periódicamente para asegurarse de que las restricciones sigan alineándose con las necesidades del equipo y los requisitos de seguridad.

## Recursos adicionales
<a name="_additional_resources"></a>
+  [Configuración de los permisos de Argo CD](argocd-permissions.md): configuración de la integración de Identity Center y RBAC
+  [Creación de aplicaciones](argocd-create-application.md): creación de aplicaciones dentro de los proyectos
+  [Uso de ApplicationSets](argocd-applicationsets.md): uso de ApplicationSets con proyectos para implementaciones de varios clústeres
+  [Documentación de proyectos de Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/): referencia ascendente completa