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

# Aggiungere utenti e configurare account di servizio
<a name="add-user"></a>

## Controllo granulare degli accessi: la nostra raccomandazione
<a name="add-user-access-control"></a>

Gli utenti vengono differenziati in base al nome utente Kubernetes. Il nome utente Kubernetes dell'utente è definito nella relativa voce di accesso. Per garantire che due utenti umani abbiano nomi utente distinti, sono disponibili due opzioni:

1. Consigliato: più utenti umani possono utilizzare lo stesso ruolo purché ognuno abbia il proprio nome di sessione distinto che persisterà tra le sessioni. Per impostazione predefinita, i nomi utente Kubernetes per i ruoli IAM sono nel formato. `arn:aws:sts::{ACCOUNT_ID}:assumed-role/{ROLE_NAME}/{SESSION_NAME}` Con questa impostazione predefinita, gli utenti saranno già differenziati in base al nome della sessione. Un amministratore dispone di alcuni modi per imporre nomi di sessione univoci per utente.
   + Accesso SSO: per impostazione predefinita, gli utenti che utilizzano l'accesso SSO avranno un nome di sessione associato al proprio nome utente AWS 
   + Servizio centralizzato di vendita di credenziali: i clienti aziendali possono disporre di un servizio interno di vendita di credenziali che gli utenti possono chiamare per ottenere credenziali con la propria identità. 
   + Applicazione basata sui ruoli: richiedi agli utenti IAM di impostare il proprio `aws:username` nome di sessione di ruolo quando assumono un ruolo IAM nel tuo. Account AWS La documentazione su come eseguire questa operazione è disponibile qui: [https://aws.amazon.com/blogs/security/ -/easily-control-naming-individualiam-role-sessions](https://aws.amazon.com/blogs/security/easily-control-naming-individual-iam-role-sessions/)

1. Se 2 Data Scientist utilizzano voci di accesso diverse (ruolo o utente IAM diverso), verranno sempre conteggiati come utenti diversi.

**Creazione di una voce di accesso**

Policy IAM richiesta per il ruolo di data scientist:
+ `eks:DescribeCluster`

Politiche di accesso richieste
+ `AmazonSagemakerHyperpodSpacePolicy`- con ambito limitato allo spazio dei nomi, DS dovrebbe creare spazi in
+ `AmazonSagemakerHyperpodSpaceTemplatePolicy`- limitato allo spazio dei nomi «jupyter-k8s-shared»

## Spazi privati e pubblici
<a name="add-user-spaces"></a>

Supportiamo 2 tipi di modelli di condivisione: «Pubblico» e «OwnerOnly». Entrambi i campi «AccessType» e «OwnershipType» utilizzano questi 2 valori.
+ AccessType: Gli spazi pubblici sono accessibili da chiunque disponga delle autorizzazioni nel namespace, mentre sono OwnerOnly accessibili solo dal creatore dello spazio e dagli utenti amministratori. Gli utenti amministratori sono definiti con i seguenti criteri:
+ OwnershipType: Gli spazi pubblici possono modified/deleted appartenere a chiunque disponga delle autorizzazioni nel namespace, OwnerOnly dal creatore o modified/deleted dall'amministratore.

Gli utenti amministratori sono definiti da:

1. Parte del gruppo `system:masters` Kubernetes

1. Parte del gruppo Kubernetes definito nella variabile di ambiente CLUSTER\_ADMIN\_GROUP nel grafico helm.

I gruppi di un utente possono essere configurati utilizzando le voci di accesso EKS. Uno spazio può essere definito come «Pubblico» o «OwnerOnly» configurando le specifiche nell'oggetto:

```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  labels:
    app.kubernetes.io/name: jupyter-k8s
  name: example-workspace
spec:
  displayName: "Example Workspace"
  image: "public.ecr.aws/sagemaker/sagemaker-distribution:3.4.2-cpu"
  desiredStatus: "Running"
  ownershipType: "Public"/"OwnerOnly"
  accessType: "Public"/"OwnerOnly"
  # more fields here
```