**Contribuisci a migliorare questa pagina** 

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Lavorare con Argo CD Projects
<a name="argocd-projects"></a>

Argo CD Projects (AppProject) forniscono il raggruppamento logico e il controllo degli accessi per le applicazioni. I progetti definiscono i repository Git, i cluster di destinazione e i namespace che le applicazioni possono utilizzare, abilitando limiti di multi-tenancy e sicurezza nelle istanze Argo CD condivise.

## Quando usare i progetti
<a name="_when_to_use_projects"></a>

Usa Projects per:
+ Separa le applicazioni per team, ambiente o unità aziendale
+ Limita i repository da cui i team possono eseguire l'implementazione
+ Limita i cluster e i namespace in cui i team possono effettuare l'implementazione
+ Applica le quote di risorse e i tipi di risorse consentiti
+ Fornisci l'implementazione self-service delle applicazioni con guardrail

## Progetto predefinito
<a name="_default_project"></a>

Ogni funzionalità di Argo CD include un `default` progetto che consente l'accesso a tutti i repository, i cluster e i namespace. Sebbene sia utile per i test iniziali, crea progetti dedicati con restrizioni esplicite per l'uso in produzione.

Per i dettagli sulla configurazione predefinita del progetto e su come limitarla, consultate [The Default Project](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#the-default-project) nella documentazione di Argo CD.

## Crea un progetto
<a name="_create_a_project"></a>

Crea un progetto applicando una `AppProject` risorsa al tuo cluster.

 **Esempio: Team-specific progetto** 

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


  # Source namespaces (required for EKS capability)
  sourceNamespaces:
    - argocd
    - team-a-dev
    - team-a-prod

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

Applica il progetto:

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

## Configurazione del progetto
<a name="_project_configuration"></a>

### Repository di origine
<a name="_source_repositories"></a>

Controlla quali repository Git le applicazioni di questo progetto possono utilizzare:

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

È possibile utilizzare caratteri jolly e schemi di negazione (`!`prefisso) per consentire o negare repository specifici. Per i dettagli, consultate [Gestione dei progetti](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#managing-projects) nella documentazione di Argo CD.

### Namespace di origine
<a name="_source_namespaces"></a>

Quando si utilizza la funzionalità EKS Argo CD, il `spec.sourceNamespaces` campo è **obbligatorio nella definizione personalizzata**. AppProject Questo campo specifica quali namespace possono contenere applicazioni o ApplicationSets che fanno riferimento a questo progetto:

**Importante**  
Questo è un campo obbligatorio per la funzionalità EKS Argo CD, che differisce da OSS Argo CD dove questo campo è facoltativo.

#### Comportamento predefinito AppProject
<a name="_default_appproject_behavior"></a>

Include `default` AppProject automaticamente lo spazio dei `argocd` nomi in. `sourceNamespaces` Se devi creare applicazioni o ApplicationSets in namespace aggiuntivi, modifica il `sourceNamespaces` campo per aggiungere quei namespace:

```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: default
  namespace: argocd
spec:
  sourceNamespaces:
    - argocd           # Already included by default
    - team-a-apps      # Add additional namespaces as needed
    - team-b-apps
```

#### Configurazione personalizzata AppProject
<a name="_custom_appproject_configuration"></a>

Quando si crea una personalizzazione AppProject, è necessario includere manualmente lo spazio dei nomi di `argocd` sistema e qualsiasi altro spazio dei nomi in cui si intende creare applicazioni oppure: ApplicationSets

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

  # Required: Manually specify all namespaces
  sourceNamespaces:
    - argocd           # ArgoCD system namespace (required)
    - team-a-dev       # Custom namespace for dev Applications
    - team-a-prod      # Custom namespace for prod Applications

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

  # Destination restrictions
  destinations:
    - namespace: 'team-a-*'
      server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster  # Use cluster ARN from: aws eks describe-cluster
```

**Nota**  
Se omettete uno spazio dei nomi da`sourceNamespaces`, Applications o ApplicationSets create in quel namespace non saranno in grado di fare riferimento a questo progetto, con conseguenti errori di distribuzione.

### Restrizioni sulla destinazione
<a name="_destination_restrictions"></a>

Limite in cui le applicazioni possono essere distribuite:

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

**Importante**  
Utilizza nomi di cluster e modelli di namespace specifici anziché caratteri jolly per i progetti di produzione. In questo modo si evitano implementazioni accidentali in cluster o namespace non autorizzati.

È possibile utilizzare caratteri jolly e schemi di negazione per controllare le destinazioni. Per i dettagli, consultate [Gestione dei progetti](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#managing-projects) nella documentazione del CD Argo.

### Restrizioni sulle risorse
<a name="_resource_restrictions"></a>

Controlla quali tipi di risorse Kubernetes possono essere implementati:

 **Cluster-scoped risorse:**

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

 **Namespace-scoped risorse**:

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

Usa le liste nere per negare risorse specifiche:

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

## Assegna applicazioni ai progetti
<a name="_assign_applications_to_projects"></a>

Quando crei un'applicazione, specifica il progetto nel `spec.project` campo:

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

Le applicazioni senza un progetto specificato utilizzano il `default` progetto.

## Ruoli del progetto e RBAC
<a name="_project_roles_and_rbac"></a>

I progetti possono definire ruoli personalizzati per un controllo granulare degli accessi. Associa i ruoli del progetto agli utenti e ai gruppi di AWS Identity Center nella configurazione delle funzionalità per controllare chi può sincronizzare, aggiornare o eliminare le applicazioni.

 **Esempio: progetto con ruoli di sviluppatore e amministratore** 

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

Per i dettagli sui ruoli del progetto, sui token JWT per le CI/CD pipeline e sulla configurazione RBAC, consulta [Project Roles](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-roles) nella documentazione di Argo CD.

## Schemi comuni
<a name="_common_patterns"></a>

### Environment-based Progetti
<a name="_environment_based_projects"></a>

Crea progetti separati per ogni 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
```

### Team-based Progetti
<a name="_team_based_projects"></a>

Isolare i team con progetti dedicati:

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

### Multi-cluster Progetti
<a name="_multi_cluster_projects"></a>

Implementa su più cluster con politiche coerenti:

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

## Best practice
<a name="_best_practices"></a>

 **Inizia con progetti restrittivi**: inizia con autorizzazioni limitate ed espandi secondo necessità anziché iniziare con un accesso ampio.

 **Usa modelli di namespace**: sfrutta i caratteri jolly nelle restrizioni dello spazio dei nomi (ad esempio`team-a-*`) per consentire flessibilità pur mantenendo i limiti.

 **Progetti di produzione separati: utilizza progetti** dedicati per la produzione con controlli più rigorosi e politiche di sincronizzazione manuale.

 **Scopi del progetto di documentazione**: utilizza il `description` campo per spiegare a cosa serve ogni progetto e chi dovrebbe utilizzarlo.

 **Rivedi regolarmente le autorizzazioni del progetto**: controlla periodicamente i progetti per assicurarti che le restrizioni siano ancora in linea con le esigenze del team e i requisiti di sicurezza.

## Risorse aggiuntive
<a name="_additional_resources"></a>
+  [Configurare le autorizzazioni di Argo CD](argocd-permissions.md)- Configurazione dell'integrazione tra RBAC e Identity Center
+  [Creazione di applicazioni](argocd-create-application.md)- Crea applicazioni all'interno dei progetti
+  [Usa ApplicationSets](argocd-applicationsets.md)- Utilizzabile ApplicationSets con Projects per implementazioni multi-cluster
+  [Documentazione sui progetti Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/) - Riferimento completo a upstream