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

## Creazione di un progetto
<a name="_create_a_project"></a>

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

 **Esempio: progetto specifico per il team** 

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

Applica il progetto:

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

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

### Archivi 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.

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

 **Risorse con ambito cluster:**

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

 **Risorse con ambito namespace:**

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

### Progetti basati sull'ambiente
<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
```

### Progetti basati su team
<a name="_team_based_projects"></a>

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

### Progetti multicluster
<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
+  [Crea 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