laboratori-cloud/.planning/phases/02-lab-01-iam-sicurezza/02-02-PLAN.md

---
phase: 02-lab-01-iam-sicurezza
plan: 02
type: execute
wave: 1
depends_on: [02-01]
files_modified:
  - labs/lab-01-iam/tutorial/01-create-linux-users.md
  - labs/lab-01-iam/tutorial/02-docker-group-permissions.md
  - labs/lab-01-iam/tutorial/03-verify-iam-setup.md
  - labs/lab-01-iam/how-to-guides/add-user-to-docker-group.md
  - labs/lab-01-iam/how-to-guides/verify-non-root-container.md
  - labs/lab-01-iam/how-to-guides/reset-docker-permissions.md
  - labs/lab-01-iam/reference/docker-socket-permissions.md
  - labs/lab-01-iam/reference/linux-users-groups.md
  - labs/lab-01-iam/reference/iam-parallels.md
  - labs/lab-01-iam/explanation/docker-iam-parallels.md
autonomous: true
requirements: [LAB-01, DOCT-01, DOCT-02, DOCT-03, DOCT-04, DOCT-05, PARA-01, PARA-03, PARA-04]
user_setup: []
must_haves:
  truths:
    - "Student can follow step-by-step tutorial to create Linux users with Docker permissions"
    - "Tutorial follows 'little often' principle with small incremental steps"
    - "How-to guides exist for common procedures independent of tutorial flow"
    - "Reference documents provide technical specifications without explanation"
    - "Explanation document draws clear parallels between Docker permissions and AWS IAM"
  artifacts:
    - path: "labs/lab-01-iam/tutorial/01-create-linux-users.md"
      provides: "Step-by-step user creation guide"
      min_lines: 60
    - path: "labs/lab-01-iam/tutorial/02-docker-group-permissions.md"
      provides: "Docker group permissions tutorial"
      min_lines: 60
    - path: "labs/lab-01-iam/tutorial/03-verify-iam-setup.md"
      provides: "Verification and testing tutorial"
      min_lines: 40
    - path: "labs/lab-01-iam/how-to-guides/add-user-to-docker-group.md"
      provides: "Procedure for adding user to docker group"
      min_lines: 30
    - path: "labs/lab-01-iam/how-to-guides/verify-non-root-container.md"
      provides: "Non-root container verification procedure"
      min_lines: 25
    - path: "labs/lab-01-iam/how-to-guides/reset-docker-permissions.md"
      provides: "Permission reset procedure"
      min_lines: 30
    - path: "labs/lab-01-iam/reference/docker-socket-permissions.md"
      provides: "Docker socket technical specifications"
      min_lines: 40
    - path: "labs/lab-01-iam/reference/linux-users-groups.md"
      provides: "Linux user management reference"
      min_lines: 40
    - path: "labs/lab-01-iam/reference/iam-parallels.md"
      provides: "IAM parallelism quick reference"
      min_lines: 30
    - path: "labs/lab-01-iam/explanation/docker-iam-parallels.md"
      provides: "Conceptual mapping between Docker and IAM"
      min_lines: 80
  key_links:
    - from: "tutorial/*.md"
      to: "how-to-guides/*.md, reference/*.md"
      via: "Cross-references for deeper dives"
      pattern: "\\[.*\\]\\(\\../how-to-guides/.*\\)"
    - from: "explanation/docker-iam-parallels.md"
      to: "reference/iam-parallels.md"
      via: "Quick reference table for concepts"
      pattern: "See \\[.*\\]\\(\\../reference/iam-parallels.md\\)"
---

<objective>
Create complete Diátaxis documentation (Tutorial, How-to Guides, Reference, Explanation) for Lab 01 - IAM & Sicurezza. Students learn Linux user management and Docker permissions through step-by-step tutorials, with supporting documentation for procedures and technical specs.

Purpose: Teach IAM concepts through local Linux user management and Docker socket permissions, drawing direct parallels to AWS IAM.
Output: 10 documentation files covering all 4 Diátaxis quadrants.
</objective>

<execution_context>
@/home/luca/.claude/get-shit-done/workflows/execute-plan.md
@/home/luca/.claude/get-shit-done/templates/summary.md
</execution_context>

<context>
@.planning/PROJECT.md
@.planning/ROADMAP.md
@.planning/STATE.md
@.planning/phases/02-lab-01-iam-sicurezza/02-RESEARCH.md
@.planning/phases/02-lab-01-iam-sicurezza/02-VALIDATION.md
@CLAUDE.md

# Diátaxis Framework from CLAUDE.md

## 2.1 Output Didattico a 4 Quadranti
1. **Tutorials:** Guida passo-passo incrementale (*little often*) per guidare l'allievo.
2. **How-to Guides:** Procedure specifiche (es. "Come generare chiavi SSH", "Come ripulire i volumi Docker").
3. **Reference:** Specifiche tecniche nude e crude (mappe IP, tabelle porte esposte, spiegazione direttive `docker-compose`).
4. **Explanation:** Il raccordo concettuale (parallelismo tra l'ambiente locale simulato e i veri servizi Cloud managed).

## IAM Parallels from RESEARCH.md

| Concepto Linux | AWS IAM Equivalente | Spiegazione |
|----------------|---------------------|-------------|
| Utente Linux (`student1`) | IAM User | Identità che può autenticarsi |
| Gruppo Linux (`docker`) | IAM Group | Collezione di utenti con stessi permessi |
| Permessi file/socket | IAM Policy | Regole che definiscono cosa è permesso |
| `/var/run/docker.sock` | Service Endpoint | Risorsa protetta da controlli accesso |
| `sudo` elevation | IAM Role Assumption | Temporanea elevazione privilegi |

## Common Pitfalls from RESEARCH.md
- Group membership requires re-login (use `newgrp docker` OR `su - user`)
- Testing as wrong user (root bypasses permissions)
- Socket permissions may change after Docker daemon restart

## Tone Guidelines
- Direct, simple language (Italian)
- No emojis
- Technically accurate
- Step-by-step with verification at each step
</context>

<tasks>

<task type="auto">
  <name>Task 1: Create Tutorial - Part 1: Linux Users</name>
  <files>labs/lab-01-iam/tutorial/01-create-linux-users.md</files>
  <action>
Create tutorial following Diátaxis framework - step-by-step, incremental, with verification:

```markdown
# Tutorial: Creare Utenti Linux per il Lab IAM

In questo tutorial creerai utenti Linux con permessi limitati per simulare utenti IAM in un ambiente cloud. Imparerai a creare utenti, verificare i permessi e gestire l'appartenenza ai gruppi.

## Obiettivo
Creare un utente Linux `lab01_student` che non ha accesso iniziale a Docker, simulando un utente cloud senza permessi.

## Prerequisiti
- Accesso a un terminale Linux con privilegi sudo
- Docker Engine installato e in esecuzione
- Comandi base: `useradd`, `groups`, `id`

---

## Passo 1: Verifica l'ambiente

Prima di creare utenti, verifichiamo che l'ambiente sia pronto.

Esegui:
```bash
# Verifica che Docker sia in esecuzione
sudo systemctl status docker

# Verifica che il gruppo docker esista
getent group docker
```

Atteso:
- Docker deve essere "active (running)"
- Il gruppo docker deve essere mostrato

Se qualcosa non funziona, consulta [Troubleshooting](#troubleshooting).

---

## Passo 2: Crea un nuovo utente Linux

Creiamo un utente che simulerà un utente cloud senza permessi IAM.

Esegui:
```bash
# Crea l'utente lab01_student
sudo useradd -m -s /bin/bash lab01_student

# Verifica che l'utente sia stato creato
id lab01_student
```

Atteso:
```
uid=1001(lab01_student) gid=1001(lab01_student) gruppi=1001(lab01_student)
```

Spiegazione:
- `-m` crea la home directory
- `-s /bin/bash` imposta la shell di default
- L'utente ha solo il proprio gruppo iniziale

---

## Passo 3: Verifica i gruppi dell'utente

Controlliamo a quali gruppi appartiene l'utente.

Esegui:
```bash
groups lab01_student
```

Atteso:
```
lab01_student : lab01_student
```

Nota: L'utente NON è nel gruppo `docker`. Questo è corretto simuliamo un utente senza permessi.

---

## Passo 4: Verifica che l'utente NON può accedere a Docker

Prova a eseguire un comando Docker come l'utente `lab01_student`.

Esegui:
```bash
# Esegui docker ps come lab01_student
sudo -u lab01_student docker ps
```

Atteso:
```
permission denied while trying to connect to the Docker daemon socket
```

Questo è il comportamento corretto! L'utente non ha ancora permessi Docker.

---

## Passo 5: Imposta una password per l'utente (opzionale)

Se vuoi poter fare login come questo utente:

Esegui:
```bash
sudo passwd lab01_student
```

Inserisci una password quando richiesto.

---

## Verifica

Hai completato questo tutorial quando:
- [ ] L'utente `lab01_student` esiste
- [ ] L'utente NON è nel gruppo docker
- [ ] L'utente NON può eseguire comandi docker
- [ ] Il comando `groups lab01_student` mostra solo il proprio gruppo

## Prossimo Passo

Nel [prossimo tutorial](./02-docker-group-permissions.md) imparerai a dare permessi Docker all'utente tramite i gruppi.

---

## Troubleshooting

**Problema: `useradd: user 'lab01_student' already exists`**

Soluzione:
```bash
# Elimina l'utente esistente e ricrealo
sudo userdel -r lab01_student
sudo useradd -m -s /bin/bash lab01_student
```

**Problema: Docker non è in esecuzione**

Soluzione:
```bash
sudo systemctl start docker
sudo systemctl enable docker
```

**Problema: Il gruppo docker non esiste**

Soluzione:
```bash
sudo groupadd docker
```
```

Key points:
- Step-by-step with verification after each step
- "Little often" - small steps, frequent verification
- Clear expected output
- Troubleshooting section
- Links to next tutorial
  </action>
  <verify>
    <automated>test -f labs/lab-01-iam/tutorial/01-create-linux-users.md && grep -q "Passo 1\|Passo 2\|Passo 3" labs/lab-01-iam/tutorial/01-create-linux-users.md && wc -l labs/lab-01-iam/tutorial/01-create-linux-users.md | awk '{if($1>=60) print "PASS"; else print "FAIL: Tutorial too short ("$1" lines, expected 60+)"}'</automated>
  </verify>
  <done>Tutorial Part 1 created with step-by-step user creation guide</done>
</task>

<task type="auto">
  <name>Task 2: Create Tutorial - Part 2: Docker Group Permissions</name>
  <files>labs/lab-01-iam/tutorial/02-docker-group-permissions.md</files>
  <action>
Create second tutorial covering Docker group permissions:

```markdown
# Tutorial: Permessi Docker tramite Gruppi Linux

In questo tutorial imparerai come dare permessi Docker a un utente tramite l'appartenenza al gruppo `docker`. Questo simula l'assegnazione di policy IAM a un utente cloud.

## Obiettivo
Aggiungere l'utente `lab01_student` al gruppo `docker`, permettendo l'accesso al socket Docker.

## Prerequisiti
- Completato [Tutorial 1: Creare Utenti Linux](./01-create-linux-users.md)
- L'utente `lab01_student` esiste e NON è nel gruppo docker

---

## Passo 1: Verifica lo stato corrente

Prima di modificare i permessi, verifichiamo lo stato attuale.

Esegui:
```bash
# Verifica i gruppi dell'utente
groups lab01_student

# Verifica i permessi del socket Docker
ls -l /var/run/docker.sock
```

Atteso:
- `groups` mostra solo `lab01_student` (NON docker)
- Il socket Docker ha permessi `srw-rw----` ed è di proprietà `root:docker`

Spiegazione: Il socket Docker (`/var/run/docker.sock`) è accessibile solo a `root` e ai membri del gruppo `docker`.

---

## Passo 2: Aggiungi l'utente al gruppo docker

Ora aggiungiamo l'utente al gruppo per dargli accesso Docker.

Esegui:
```bash
# Aggiungi lab01_student al gruppo docker
sudo usermod -aG docker lab01_student

# Verifica l'appartenenza al gruppo
groups lab01_student
```

Atteso:
```
lab01_student : lab01_student docker
```

Nota: Il gruppo `docker` ora appare nell'elenco!

Spiegazione:
- `-aG` significa "append" (aggiunge senza rimuovere altri gruppi) e "group" (modifica i gruppi)
- Questo è equivalente ad assegnare una policy IAM a un utente cloud

---

## Passo 3: Importante - Login necessario

I gruppi vengono valutati al momento del login. La sessione corrente dell'utente non vedrà ancora il nuovo gruppo.

Per verificare il gruppo membership (senza dover fare login):
```bash
# Questo mostra i gruppi anche se non sono ancora attivi nella sessione
groups lab01_student
```

Per rendere attivi i nuovi gruppi, l'utente deve fare una di queste operazioni:
1. Fare logout e login
2. Eseguire `newgrp docker`
3. Eseguire `su - lab01_student`

---

## Passo 4: Verifica l'accesso Docker

Ora verifichiamo che l'utente può accedere a Docker.

Esegui:
```bash
# Metodo 1: Usa newgrp per attivare il gruppo nella sessione corrente
sudo -u lab01_student -i docker ps
```

Atteso:
```
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
```

Il comando funziona! L'utente ora ha accesso Docker.

---

## Passo 5: Verifica con un container di test

Facciamo partire un container semplice per confermare che tutto funziona.

Esegui:
```bash
# Esegui un container Alpine come lab01_student
sudo -u lab01_student -i docker run --rm alpine:3.19 whoami
```

Atteso:
```
root
```

Nota: Il container mostra "root" perché questo è l'utente di default DENTRO il container (non è l'utente che ha lanciato il comando). Nel [Tutorial 3](./03-verify-iam-setup.md) imparerai a far girare i container come utente non-root.

---

## Parallelismo con AWS IAM

| Operazione Locale | AWS IAM Equivalente |
|-------------------|---------------------|
| `usermod -aG docker user` | `AttachUserPolicy` o `AddUserToGroup` |
| Utente nel gruppo `docker` | Utente IAM con policy permessive |
| Accesso al socket Docker | Accesso alle API AWS |

---

## Verifica

Hai completato questo tutorial quando:
- [ ] L'utente `lab01_student` è nel gruppo docker
- [ ] L'utente può eseguire `docker ps`
- [ ] L'utente può fare partire container
- [ ] Capisci il parallelismo con IAM User + Policy

## Prossimo Passo

Nel [prossimo tutorial](./03-verify-iam-setup.md) imparerai a verificare l'intera configurazione e a far girare container non-root.

---

## Troubleshooting

**Problema: L'utente non può ancora eseguire docker ps**

Soluzione 1: Verifica di aver usato `sudo -u lab01_student -i`
```bash
# Il flag -i è importante per caricare l'ambiente corretto
sudo -u lab01_student -i docker ps
```

Soluzione 2: Verifica che l'utente sia nel gruppo
```bash
groups lab01_student
# Se non vedi "docker", ripeti il Passo 2
```

**Problema: Il socket Docker ha permessi errati**

Soluzione:
```bash
# Correggi i permessi del socket
sudo chmod 660 /var/run/docker.sock
sudo chown root:docker /var/run/docker.sock
```

**Problema: `usermod: user 'lab01_student' does not exist`**

Soluzione: Prima crea l'utente seguendo il [Tutorial 1](./01-create-linux-users.md).
```

Key points:
- Explain the group membership evaluation timing issue
- Show parallelism with AWS IAM
- Multiple troubleshooting scenarios
- Clear verification steps
  </action>
  <verify>
    <automated>test -f labs/lab-01-iam/tutorial/02-docker-group-permissions.md && grep -q "IAM\|AWS\|Parallelismo" labs/lab-01-iam/tutorial/02-docker-group-permissions.md && wc -l labs/lab-01-iam/tutorial/02-docker-group-permissions.md | awk '{if($1>=60) print "PASS"; else print "FAIL: Tutorial too short ("$1" lines, expected 60+)"}'</automated>
  </verify>
  <done>Tutorial Part 2 created with Docker group permissions guide</done>
</task>

<task type="auto">
  <name>Task 3: Create Tutorial - Part 3: Verification and Non-Root Containers</name>
  <files>labs/lab-01-iam/tutorial/03-verify-iam-setup.md</files>
  <action>
Create third tutorial covering verification and non-root containers:

```markdown
# Tutorial: Verifica Configurazione IAM e Container Non-Root

In questo tutorial verificherai l'intera configurazione IAM e imparerai a far girare container come utente non-root, seguendo il principio del minimo privilegio.

## Obiettivo
Verificare che la configurazione IAM funzioni e far girare container come utente non-root (INF-01).

## Prerequisiti
- Completati [Tutorial 1](./01-create-linux-users.md) e [Tutorial 2](./02-docker-group-permissions.md)
- L'utente `lab01_student` esiste ed è nel gruppo docker

---

## Passo 1: Esegui lo script di verifica

Il lab include uno script automatizzato per verificare tutto.

Esegui:
```bash
bash labs/lab-01-iam/tests/99-final-verification.sh
```

Questo comando controllerà:
1. Configurazione utenti e gruppi
2. Accesso Docker
3. Esecuzione container non-root
4. Documentazione completa
5. Parallelismi IAM

Se tutti i check sono verdi, sei pronto per procedere!

---

## Passo 2: Verifica manuale - Accesso Docker

Verifichiamo manualmente che l'utente possa accedere a Docker.

Esegui:
```bash
# Verifica che docker ps funzioni
sudo -u lab01_student -i docker ps

# Verifica informazioni sul sistema Docker
sudo -u lab01_student -i docker info
```

Entrambi i comandi dovrebbero funzionare senza errori.

---

## Passo 3: Crea un container NON-ROOT

Ora creiamo un container che gira come utente non-root, seguendo il principio del minimo privilegio.

Esegui:
```bash
cd labs/lab-01-iam

# Crea un Dockerfile di test
cat > Dockerfile.test << 'EOF'
FROM alpine:3.19

# Crea un utente non-root
RUN addgroup -g 1000 appgroup && \
    adduser -D -u 1000 -G appgroup appuser

# Passa all'utente non-root
USER appuser

# Verifica che il container gira come appuser
CMD ["sh", "-c", "whoami && sleep 3600"]
EOF
```

Spiegazione:
- Creiamo un utente `appuser` con UID 1000
- Passiamo a questo utente con `USER`
- Il container ora girerà come `appuser`, non come `root`

---

## Passo 4: Build e run del container

Ora costruiamo e facciamo partire il container.

Esegui:
```bash
# Costruisci l'immagine
sudo -u lab01_student -i docker build -f Dockerfile.test -t test-non-root .

# Fai partire il container
sudo -u lab01_student -i docker run --name lab01-test-container -d test-non-root
```

Atteso:
- Build completa senza errori
- Container ID viene mostrato

---

## Passo 5: Verifica che il container NON gira come root

Verifichiamo l'utente del container in tre modi.

Esegui:
```bash
# Metodo 1: docker exec whoami
docker exec lab01-test-container whoami
```

Atteso:
```
appuser
```

Esegui:
```bash
# Metodo 2: docker inspect
docker inspect lab01-test-container --format='{{.Config.User}}'
```

Atteso:
```
appuser
```

Esegui:
```bash
# Metodo 3: docker top (mostra il processo sull'host)
docker top lab01-test-container
```

Atteso:
- La colonna USER mostra `1000` (non `0`)

---

## Passo 6: Verifica INF-01 - Nessun container root

Il requisito INF-01 richiede che NESSUN container giri come root.

Esegui:
```bash
bash labs/lab-01-iam/tests/03-non-root-test.sh
```

Questo script verificherà tutti i container e garantirà che nessuno giri come root.

---

## Passo 7: Pulisci il container di test

Dopo aver verificato, puliamo il container di test.

Esegui:
```bash
# Ferma e rimuovi il container
docker stop lab01-test-container
docker rm lab01-test-container

# Rimuovi l'immagine
docker rmi test-non-root
```

---

## Principio del Minimo Privilegio

Perché NON usare root nei container?

| Rischio Root | Mitigazione Non-Root |
|--------------|----------------------|
| Container compromesso = host compromesso | Utente limitato = danno contenuto |
| Container può leggere/scrivere qualsiasi file sull'host | Container può solo accedere ai suoi file |
| Escalation privilegi possibile | Privilegi già limitati |

Questo è lo stesso principio di IAM in cloud: dai solo i permessi minimi necessari.

---

## Verifica

Hai completato questo tutorial quando:
- [ ] Lo script di verifica passa senza errori
- [ ] Il container di test gira come utente non-root
- [ ] Tutti e tre i metodi di verifica mostrano lo stesso utente non-root
- [ ] Capisci perché INF-01 è importante per la sicurezza

---

## Troubleshooting

**Problema: `docker exec` mostra "root"**

Soluzione: Verifica che il Dockerfile abbia la direttiva `USER`
```bash
# Verifica che USER sia nel Dockerfile
grep USER Dockerfile.test
# Dovrebbe mostrare: USER appuser
```

**Problema: `docker top` mostra UID 0**

Soluzione: Il container potrebbe essere stato configurato con docker-compose. Verifica:
```bash
# Verifica la direttiva user in docker-compose
grep -A 5 "user:" labs/lab-01-iam/docker-compose.yml
```

**Problema: Il test INF-01 fallisce**

Soluzione: Assicurati che TUTTI i container abbiano la direttiva USER o user:
```bash
# Controlla tutti i container
docker ps --format "{{.Names}}" | xargs -I {} sh -c 'echo "Container: {}" && docker inspect --format="{{.Config.User}}" {}'
```
```

Key points:
- Multiple verification methods for non-root execution
- Clear explanation of security principle
- Automated test integration
- Comprehensive troubleshooting
  </action>
  <verify>
    <automated>test -f labs/lab-01-iam/tutorial/03-verify-iam-setup.md && grep -q "INF-01\|minimo privilegio\|non-root" labs/lab-01-iam/tutorial/03-verify-iam-setup.md && wc -l labs/lab-01-iam/tutorial/03-verify-iam-setup.md | awk '{if($1>=40) print "PASS"; else print "FAIL: Tutorial too short ("$1" lines, expected 40+)"}'</automated>
  </verify>
  <done>Tutorial Part 3 created with verification and non-root container guide</done>
</task>

<task type="auto">
  <name>Task 4: Create How-to Guides</name>
  <files>labs/lab-01-iam/how-to-guides/add-user-to-docker-group.md, labs/lab-01-iam/how-to-guides/verify-non-root-container.md, labs/lab-01-iam/how-to-guides/reset-docker-permissions.md</files>
  <action>
Create three how-to guides for common procedures:

**File 1: labs/lab-01-iam/how-to-guides/add-user-to-docker-group.md**
```markdown
# How-To: Aggiungere un Utente al Gruppo Docker

Guida rapida per aggiungere un utente Linux al gruppo Docker e dargli accesso al socket.

## Comando Rapido

```bash
# Aggiungi utente esistente al gruppo docker
sudo usermod -aG docker nome_utente
```

## Verifica

```bash
# Verifica l'appartenenza al gruppo
groups nome_utente

# Verifica l'accesso docker
sudo -u nome_utente -i docker ps
```

## Nota Importante

I gruppi vengono valutati al login. Per attivare il nuovo gruppo immediatamente:

```bash
# Opzione 1: newgrp (attiva solo per questo comando)
sudo -u nome_utente -i docker ps

# Opzione 2: su - (nuova sessione login)
su - nome_utente
docker ps

# Opzione 3: logout/login (sessione interattiva)
```

## Rimuovi Utente dal Gruppo Docker

```bash
# Rimuovi utente dal gruppo docker
sudo gpasswd -d nome_utente docker

# Oppure modifica i gruppi supplementari
sudo usermod -G nome_utente nome_utente
```

## Vedi Anche

- [Tutorial: Permessi Docker tramite Gruppi](../tutorial/02-docker-group-permissions.md)
- [Reference: Permessi Socket Docker](../reference/docker-socket-permissions.md)
```

**File 2: labs/lab-01-iam/how-to-guides/verify-non-root-container.md**
```markdown
# How-To: Verificare che un Container Giri come Non-Root

Guida rapida per verificare che un container non giri come utente root (requisito INF-01).

## Metodo 1: docker exec whoami

```bash
docker exec <container_name> whoami
```

Se mostra `root`, il container NON è conforme a INF-01.

## Metodo 2: docker inspect

```bash
docker inspect <container_name> --format='{{.Config.User}}'
```

- Se vuoto, il container gira come root (default)
- Se mostra un UID/nome, il container gira come quell'utente

## Metodo 3: docker top

```bash
docker top <container_name>
```

Guarda la colonna USER:
- `0` o `root` = NON conforme
- Altri UID (es. `1000`) = CONFORME

## Verifica Tutti i Container

```bash
# Verifica tutti i container in esecuzione
docker ps --format "{{.Names}}" | while read container; do
    echo "Container: $container"
    docker exec $container whoami 2>/dev/null || echo "N/A"
done
```

## Verifica con docker-compose

```bash
# Verifica tutti i servizi nel compose file
docker-compose ps --services | while read service; do
    container=$(docker-compose ps -q $service)
    echo "Service: $service, User: $(docker exec $container whoami)"
done
```

## Vedi Anche

- [Tutorial: Container Non-Root](../tutorial/03-verify-iam-setup.md)
- [Test: Script Non-Root](../tests/03-non-root-test.sh)
```

**File 3: labs/lab-01-iam/how-to-guides/reset-docker-permissions.md**
```markdown
# How-To: Reset dei Permessi Docker

Guida per ripristinare i permessi del socket Docker e risolvere problemi di accesso.

## Reset dei Permessi del Socket

```bash
# Ferma il demone Docker
sudo systemctl stop docker

# Ripristina la proprietà del socket
sudo chown root:docker /var/run/docker.sock

# Ripristina i permessi (660 = rw-rw----)
sudo chmod 660 /var/run/docker.sock

# Riavvia Docker
sudo systemctl start docker
```

## Verifica

```bash
# Verifica i permessi del socket
ls -l /var/run/docker.sock
```

Atteso: `srw-rw---- 1 root docker ...`

## Ricrea il Gruppo Docker

Se il gruppo docker è stato eliminato:

```bash
# Crea il gruppo docker
sudo groupadd docker

# Riavvia Docker per assicurarti che il socket appartenga al gruppo
sudo systemctl restart docker
```

## Risoluzione Problemi Comuni

### Problema: "Got permission denied while trying to connect"

**Causa:** Utente non nel gruppo docker o permessi socket errati

**Soluzione:**
```bash
# Verifica gruppi utente
groups $USER

# Aggiungi al gruppo se necessario
sudo usermod -aG docker $USER

# Verifica permessi socket
ls -l /var/run/docker.sock

# Correggi se necessario
sudo chmod 660 /var/run/docker.sock
sudo chown root:docker /var/run/docker.sock
```

### Problema: Socket non esiste

**Causa:** Docker non è in esecuzione

**Soluzione:**
```bash
# Avvia Docker
sudo systemctl start docker

# Verifica che il socket sia stato creato
ls -l /var/run/docker.sock
```

### Problema: Group membership non attiva

**Causa:** I gruppi vengono valutati al login

**Soluzione:**
```bash
# Attiva il gruppo per la sessione corrente
newgrp docker

# Oppure fai login di nuovo
su - $USER
```

## Reset Completo dell'Ambiente

Per reset completo dell'ambiente Docker tra i lab:

```bash
# Usa lo script di reset
bash scripts/reset-env.sh

# Oppure reset manuale
docker stop $(docker ps -aq)
docker rm $(docker ps -aq)
docker system prune -a
```

## Vedi Anche

- [How-To: Ambiente Reset](../../how-to-guides/reset-docker-environment.md)
- [Tutorial: Permessi Docker](../tutorial/02-docker-group-permissions.md)
```

Key points:
- Procedure-focused, not step-by-step learning
- Command-first structure
- Links to tutorials and reference
- Troubleshooting common issues
  </action>
  <verify>
    <automated>test -f labs/lab-01-iam/how-to-guides/add-user-to-docker-group.md && test -f labs/lab-01-iam/how-to-guides/verify-non-root-container.md && test -f labs/lab-01-iam/how-to-guides/reset-docker-permissions.md && grep -q "##" labs/lab-01-iam/how-to-guides/*.md | wc -l | awk '{if($1>=9) print "PASS"; else print "FAIL: How-to guides need more sections"}'</automated>
  </verify>
  <done>Three how-to guides created for common procedures</done>
</task>

<task type="auto">
  <name>Task 5: Create Reference Documents</name>
  <files>labs/lab-01-iam/reference/docker-socket-permissions.md, labs/lab-01-iam/reference/linux-users-groups.md, labs/lab-01-iam/reference/iam-parallels.md</files>
  <action>
Create three reference documents with technical specifications:

**File 1: labs/lab-01-iam/reference/docker-socket-permissions.md**
```markdown
# Reference: Permessi del Socket Docker

Specifiche tecniche del socket Docker Unix domain socket e controllo accessi.

## Percorso del Socket

```
/var/run/docker.sock
```

## Permessi Standard

```
srw-rw---- 1 root docker 0 Mar 24 20:00 /var/run/docker.sock
```

| Campo | Valore | Significato |
|-------|--------|-------------|
| Tipo | `s` | Socket Unix domain |
| Permessi | `rw-rw----` (660) | Owner e gruppo possono leggere/scrivere |
| Owner | `root` | Il demone Docker gira come root |
| Gruppo | `docker` | Membri del gruppo docker possono accedere |
| Altro | `---` | Nessun altro permesso |

## Controllo Accessi

L'accesso al socket è controllato dai permessi file system standard Linux:

### Chi puo accedere?

| Utente | Accesso | Motivo |
|--------|---------|--------|
| root | Si | Proprietario del socket |
| Membri del gruppo docker | Si | Permesso gruppo (rw) |
| Altri utenti | No | Nessun permesso |

### Verifica Permessi

```bash
# Mostra permessi dettagliati
stat -c "%a %U %G %n" /var/run/docker.sock
# Output: 660 root docker /var/run/docker.sock

# Verifica gruppo del socket
stat -c "%G" /var/run/docker.sock
# Output: docker

# Verifica proprietario
stat -c "%U" /var/run/docker.sock
# Output: root
```

## Modifica Permessi

```bash
# Modifica permessi (non raccomandato: 666 permette accesso a tutti)
sudo chmod 660 /var/run/docker.sock

# Modifica gruppo
sudo chown root:docker /var/run/docker.sock

# Modifica proprietario (non raccomandato)
sudo chown $USER /var/run/docker.sock
```

⚠️ **WARNING:** Non usare mai `chmod 666` o `777` sul socket Docker. Questo elimina tutti i controlli di accesso.

## Docker Daemon e Socket

### Allocazione Socket

Il demone Docker crea il socket all'avvio:

```bash
# Avvia demone (crea/ricrea socket)
sudo systemctl start docker

# Riavvia per ripristinare permessi
sudo systemctl restart docker
```

### Rootless Docker

Con rootless Docker, il socket si trova in:

```
$XDG_RUNTIME_DIR/docker.sock
# Tipicamente: /run/user/1000/docker.sock
```

## Troubleshooting

| Problema | Diagnosi | Soluzione |
|----------|----------|-----------|
| Permission denied | Utente non in gruppo docker | `sudo usermod -aG docker $USER` |
| Socket non trovato | Docker non in esecuzione | `sudo systemctl start docker` |
| Permessi errati | chmod eseguito sul socket | `sudo systemctl restart docker` |
| Gruppo errato | Chown sul socket | `sudo chown root:docker /var/run/docker.sock` |

## Comandi Rapidi

```bash
# Verifica permessi attuali
ls -l /var/run/docker.sock

# Verifica chi puo accedere
namei -l /var/run/docker.sock

# Trova processi con handle al socket
sudo lsof /var/run/docker.sock
```

## Vedi Anche

- [Reference: Utenti e Gruppi Linux](./linux-users-groups.md)
- [Explanation: Parallelismi IAM](../explanation/docker-iam-parallels.md)
```

**File 2: labs/lab-01-iam/reference/linux-users-groups.md**
```markdown
# Reference: Utenti e Gruppi Linux

Specifiche tecniche per la gestione utenti e gruppi in Linux per il lab IAM.

## Comandi Utente

### useradd - Crea utente

```bash
sudo useradd -m -s /bin/bash nome_utente
```

| Flag | Significato |
|------|-------------|
| `-m` | Crea home directory |
| `-s /bin/bash` | Imposta shell di login |
| `-G group1,group2` | Aggiunge a gruppi supplementari |
| `-u 1000` | Specifica UID |

### usermod - Modifica utente

```bash
# Aggiungi a gruppo (append)
sudo usermod -aG docker nome_utente

# Modifica shell
sudo usermod -s /bin/zsh nome_utente

# Modifica gruppi supplementari (sovrascrive)
sudo usermod -G docker,nome_utente nome_utente
```

⚠️ **IMPORTANTE:** Usa `-aG` (append) per aggiungere a un gruppo senza rimuovere gli altri.

### userdel - Elimina utente

```bash
# Elimina utente (mantieni home)
sudo userdel nome_utente

# Elimina utente e home directory
sudo userdel -r nome_utente
```

### passwd - Imposta password

```bash
# Imposta password per utente
sudo passwd nome_utente

# Cambia la tua password
passwd
```

## Comandi Gruppo

### groupadd - Crea gruppo

```bash
sudo groupadd docker
```

### groupmod - Modifica gruppo

```bash
# Rinomina gruppo
sudo groupmod -n nuovo_nome vecchio_nome

# Modifica GID
sudo groupmod -g 1001 docker
```

### gpasswd - Gestisci membri gruppo

```bash
# Aggiungi utente al gruppo
sudo gpasswd -a utente gruppo

# Rimuovi utente dal gruppo
sudo gpasswd -d utente gruppo

# Imposta amministratori gruppo
sudo gpasswd -A utente1,utente2 gruppo
```

### groupdel - Elimina gruppo

```bash
sudo groupdelete docker
```

## Comandi Informazione

### id - Mostra info utente

```bash
# Mostra UID, GID e gruppi dell'utente corrente
id

# Mostra info di un utente specifico
id nome_utente

# Solo UID
id -u nome_utente

# Solo gruppi
id -G nome_utente
```

Output esempio:
```
uid=1001(lab01_student) gid=1001(lab01_student) groups=1001(lab01_student),999(docker)
```

### groups - Mostra gruppi utente

```bash
# Gruppi dell'utente corrente
groups

# Gruppi di un utente specifico
groups nome_utente
```

### getent - Query database di sistema

```bash
# Verifica che un gruppo esista
getent group docker

# Output: docker:x:999:utente1,utente2
#        nome:x:GID:lista_membri

# Verifica che un utente esista
getent passwd nome_utente

# Output: nome_utente:x:1001:1001:,,,:/home/nome_utente:/bin/bash
#         nome:x:UID:GID:commento:home:shell
```

## File di Configurazione

### /etc/passwd

```bash
# Visualizza tutti gli utenti
cat /etc/passwd

# Aggiungi utente manualmente (non raccomandato)
echo "utente:x:1001:1001::/home/utente:/bin/bash" | sudo tee -a /etc/passwd
```

Formato:
```
username:x:UID:GID:commento:home:shell
```

### /etc/group

```bash
# Visualizza tutti i gruppi
cat /etc/group

# Aggiungi gruppo manualmente
echo "docker:x:999:utente1,utente2" | sudo tee -a /etc/group
```

Formato:
```
gruppo:x:GID:lista_membri
```

### /etc/shadow

```bash
# Password e scadenza (richiede root)
sudo cat /etc/shadow
```

## Valutazione Gruppi al Login

I gruppi vengono valutati quando l'utente fa login:

| Momento | Gruppi Valutati |
|---------|-----------------|
| Avvio sistema | No |
| Login interattivo | Si |
| `su - utente` | Si (nuovo login) |
| `newgrp group` | Si (solo sessione corrente) |
| `sudo -u utente cmd` | No (gruppi dell'utente originale) |
| Aggiunta gruppo con usermod | No (fino al prossimo login) |

## UID/GID Standard

| UID/GID | Utente/Gruppo |
|---------|---------------|
| 0 | root |
| 1-999 | Utenti di sistema |
| 1000-60000 | Utenti normali |
| 999 | docker (tipico) |

## Comandi Rapidi

```bash
# Lista tutti gli utenti umani
cat /etc/passwd | grep ':[1-9][0-9][0-9][0-9]:'

# Lista tutti i gruppi
cat /etc/group | cut -d: -f1

# Utenti in un gruppo
members gruppo
# Oppure:
getent group gruppo | cut -d: -f4
```

## Vedi Anche

- [Reference: Permessi Socket Docker](./docker-socket-permissions.md)
- [How-To: Aggiungi Utente al Gruppo Docker](../how-to-guides/add-user-to-docker-group.md)
```

**File 3: labs/lab-01-iam/reference/iam-parallels.md**
```markdown
# Reference: Parallelismi Docker e AWS IAM

Tabella di riferimento rapido per i parallelismi tra concetti Docker/Linux e AWS IAM.

## Tabella Parallelismi

| Concetto Locale | AWS IAM Equivalente | Descrizione |
|-----------------|---------------------|-------------|
| Utente Linux (`student1`) | IAM User | Identità che può autenticarsi |
| Gruppo Linux (`docker`) | IAM Group | Collezione di utenti con stessi permessi |
| Permessi file/socket | IAM Policy | Regole che definiscono cosa è permesso |
| `/var/run/docker.sock` | Service Endpoint | Risorsa protetta da controlli accesso |
| `sudo` elevation | IAM Role Assumption | Temporanea elevazione privilegi |
| `usermod -aG docker` | `AttachUserPolicy` | Assegna permessi a utente |
| Appartenenza gruppo `docker` | Policy attachment | Permessi attivi per utente |

## Comandi a Confronto

### Creazione Utente

| Operazione Locale | Comando AWS |
|-------------------|-------------|
| `sudo useradd -m user` | `aws iam create-user --user-name user` |
| `sudo passwd user` | `aws iam create-login-profile --user-name user --password Pass123!` |

### Gestione Permessi

| Operazione Locale | Comando AWS |
|-------------------|-------------|
| `sudo usermod -aG docker user` | `aws iam attach-user-policy --user-name user --policy-arn arn:aws:iam::aws:policy/PowerUserAccess` |
| `sudo gpasswd -d user docker` | `aws iam detach-user-policy --user-name user --policy-arn arn:aws:iam::aws:policy/PowerUserAccess` |

### Verifica Permessi

| Operazione Locale | Comando AWS |
|-------------------|-------------|
| `groups user` | `aws iam list-attached-user-policies --user-name user` |
| `id user` | `aws iam get-user --user-name user` |
| `sudo -u user docker ps` | `aws sts get-caller-identity` |

### Elevazione Privilegi

| Operazione Locale | Comando AWS |
|-------------------|-------------|
| `sudo command` | Assumere IAM Role |
| `su - root` | `aws sts assume-role` |

## Differenze Chiave

| Aspetto | Locale | Cloud AWS |
|---------|--------|-----------|
| Autenticazione | Password, SSH key | Access key, Secret key, Session token |
| Autorizzazione | Gruppi Linux, permessi file | IAM Policies, JSON document |
| Scope | Singolo host | Account AWS intero |
| Audit | `last`, `/var/log/auth.log` | CloudTrail |
| MFA | Non disponibile | Disponibile |

## Modelli di Policy

### Modello Allow

**Locale:**
```bash
# Utente nel gruppo docker puo accedere al socket
sudo usermod -aG docker utente
```

**AWS:**
```json
{
  "Effect": "Allow",
  "Action": "docker:*",
  "Resource": "*"
}
```

### Modello Deny

**Locale:**
```bash
# Utente NON nel gruppo docker non puo accedere
# (default deny)
```

**AWS:**
```json
{
  "Effect": "Deny",
  "Action": "docker:*",
  "Resource": "*"
}
```

## Best Practices Comuni

| Best Practice | Locale | Cloud |
|---------------|--------|-------|
| Minimo privilegio | Utenti non-root | IAM Policies restrittive |
| Separazione doveri | Gruppi distinti | Gruppi IAM distinti |
| Audit logging | auth.log | CloudTrail |
| Rotazione credenziali | `chage` | Rotate access keys |

## Comandi Utili

```bash
# Verifica membri gruppo docker
getent group docker

# Simulazione:_lista politiche IAM
aws iam list-attached-user-policies --user-name user

# Verifica permessi socket
ls -l /var/run/docker.sock

# Simulazione:_simula accesso AWS
aws sts get-caller-identity
```

## Vedi Anche

- [Explanation: Docker IAM Parallels](../explanation/docker-iam-parallels.md)
- [Tutorial: Permessi Docker](../tutorial/02-docker-group-permissions.md)
```

Key points:
- Pure reference material (no tutorial content)
- Tables and specifications
- Command comparisons
- Quick reference format
  </action>
  <verify>
    <automated>test -f labs/lab-01-iam/reference/docker-socket-permissions.md && test -f labs/lab-01-iam/reference/linux-users-groups.md && test -f labs/lab-01-iam/reference/iam-parallels.md && grep -q "|" labs/lab-01-iam/reference/*.md | wc -l | awk '{if($1>=15) print "PASS"; else print "FAIL: Reference docs need more tables"}'</automated>
  </verify>
  <done>Three reference documents created with technical specifications</done>
</task>

<task type="auto">
  <name>Task 6: Create Explanation Document (IAM Parallels)</name>
  <files>labs/lab-01-iam/explanation/docker-iam-parallels.md</files>
  <action>
Create explanation document that connects local Docker concepts to cloud IAM:

```markdown
# Explanation: Parallelismi tra Docker Permissions e AWS IAM

In questo documento esploreremo come i permessi Docker e la gestione utenti Linux simulano i concetti di Identity and Access Management (IAM) nei cloud provider come AWS. Comprendere questi parallelismi ti aiuterà a trasferire le conoscenze acquisite localmente agli ambienti cloud reali.

## Cos'è IAM?

**IAM (Identity and Access Management)** è il framework che controlla:
- **Identity:** Chi sei (autenticazione)
- **Access:** Cosa puoi fare (autorizzazione)

AWS IAM, Azure IAM, Google Cloud IAM sono tutti basati sullo stesso concetto fondamentale: le identità hanno permessi specifici su risorse specifiche.

---

## Il Parallelismo Fondamentale

### Utente Linux = IAM User

| Locale | Cloud |
|--------|-------|
| Un utente Linux (`lab01_student`) | Un IAM User (`alice`) |
| Può fare login al sistema | Può fare login ad AWS |
| Ha UID univoco | Ha User ID univoco (AIDAI...) |
| Appartiene a gruppi | Appartiene a IAM Groups |

**Similitudine:** Entrambi rappresentano un'identità umana o di servizio che può autenticarsi.

**Differenza:** Gli utenti Linux sono locali a una singola macchina, gli IAM Users sono globali all'account AWS.

### Gruppo Linux = IAM Group

| Locale | Cloud |
|--------|-------|
| Gruppo `docker` | IAM Group `Developers` |
| Membri ereditano permessi del gruppo | Membri ereditano policies del gruppo |
| Utente può essere in multipli gruppi | Utente può essere in multipli gruppi |
| `groups user` mostra membrianze | `aws iam list-groups-for-user` |

**Similitudine:** I gruppi rendono facile gestire i permessi per molti utenti. Aggiungi un utente al gruppo e ha automaticamente tutti i permessi del gruppo.

**Differenza:** I gruppi Linux sono definiti localmente, i gruppi IAM sono definiti centralmente e possono avere utenti跨-region.

### Socket Docker = Service Endpoint

| Locale | Cloud |
|--------|-------|
| `/var/run/docker.sock` | AWS API endpoint (`https://ec2.amazonaws.com`) |
| Accessibile solo con permessi corretti | Accessibile solo con credenziali valide |
| `chmod 660` limita l'accesso | IAM policies limitano l'accesso |

**Similitudine:** Entrambe sono risorse protette che richiedono autorizzazione per essere utilizzate.

**Differenza:** Il socket Docker è un file Unix locale, gli API endpoint sono servizi web remoti.

### Permessi File = IAM Policy

| Locale | Cloud |
|--------|-------|
| `rw-rw----` su socket | JSON policy con `Effect: Allow/Deny` |
| Utente deve essere nel gruppo `docker` | Utente deve avere policy permessiva |
| `chmod` cambia permessi | `AttachUserPolicy` assegna policy |

**Similitudine:** Entrambi definiscono regole esplicite su chi puo fare cosa.

**Differenza:** I permessi Linux sono semplici (read/write/execute), le IAM policies sono espressioni complesse con condizioni, wildcard, e resource-level permissions.

---

## Esempio Pratico: Setup di un Nuovo Sviluppatore

### Scenario Locale

```bash
# 1. Crea utente per il nuovo sviluppatore
sudo useradd -m -s /bin/bash mario_rossi

# 2. Aggiungi al gruppo docker (permette di lanciare container)
sudo usermod -aG docker mario_rossi

# 3. Verifica
groups mario_rossi
# Output: mario_rossi : mario_rossi docker

# 4. Mario ora puo lanciare container
sudo -u mario_rossi docker run alpine whoami
```

### Scenario Cloud AWS (Equivalente)

```bash
# 1. Crea IAM User per il nuovo sviluppatore
aws iam create-user --user-name mario_rossi

# 2. Crea gruppo per sviluppatori (se non esiste)
aws iam create-group --group-name Developers

# 3. Allega policy al gruppo (permette di usare EC2/containers)
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/PowerUserAccess

# 4. Aggiungi utente al gruppo
aws iam add-user-to-group \
  --group-name Developers \
  --user-name mario_rossi

# 5. Verifica
aws iam list-groups-for-user --user-name mario_rossi
# Output: Groups: [Developers]

# 6. Mario ora puo lanciare istanze EC2 (equivalente a container)
aws ec2 run-instances --image-id ami-12345 ...
```

**Parallelismo:**
- Entrambi iniziano creando un'identità
- Entrambi usano gruppi per gestire i permessi
- Entrambi verificano l'appartenenza al gruppo
- Entrambi ora possono lanciare risorse (container/EC2)

---

## Il Principio del Minimo Privilegio

### Locale: Non-Root Containers

**Perché non root?**
- Root in container = root sull'host (se vulnerabilità kernel)
- Root puo leggere/scrivere qualsiasi file
- Root puo modificare configurazioni di sistema

**Soluzione locale:**
```dockerfile
# Dockerfile con utente non-root
FROM alpine:3.19
RUN adduser -D -u 1000 appuser
USER appuser
CMD ["sh", "-c", "whoami"]
```

**Verifica:**
```bash
docker exec container whoami
# Output: appuser (NON root)
```

### Cloud: IAM Policies Restrittive

**Perché policy minime?**
- Chiave compromessa = danno limitato
- Principio di least privilege
- Audit e compliance requirements

**Soluzione cloud:**
```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}
```

**Verifica:**
```bash
# Simula accesso dell'utente
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/mario_rossi \
  --action-names s3:DeleteBucket \
  # Output: Decision: Deny (policy non permette DeleteBucket)
```

**Parallelismo:**
- Entrambi limitano cosa l'identità puo fare
- Entrambi riducono la superficie di attacco
- Entrambi sono verificabili tramite test

---

## Differenze tra Locale e Cloud

### 1. Scope dei Permessi

| Locale | Cloud |
|--------|-------|
| Permessi validi solo su questa macchina | Permessi validi per tutto l'account AWS |
| Utente locale accede solo a risorse locali | IAM user accede a risorse globali |
| Gruppi definiti in `/etc/group` | Gruppi definiti in IAM (centralizzato) |

**Implicazione:** Nel cloud, un utente con permessi S3 puo accedere a tutti i bucket S3 nell'account, non solo a quelli "vicini" come nel filesystem locale.

### 2. Complessità delle Policy

| Locale | Cloud |
|--------|-------|
| Semplice: lettura/scrittura/esecuzione | Complesso: conditions, IP restrictions, MFA |
| Basato su owner/group/other | Basato su JSON con wildcards |
| Binario: o hai permesso o no | Granulare: resource-level, tag-based, time-based |

**Esempio Cloud (non possibile localmente):**
```json
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": ["203.0.113.0/24"]
    },
    "DateGreaterThan": {
      "aws:CurrentTime": "2024-01-01T00:00:00Z"
    },
    "Bool": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}
```

**Implicazione:** Le IAM policies sono piu potenti ma anche piu complesse da capire e debuggare.

### 3. Audit e Logging

| Locale | Cloud |
|--------|-------|
| `/var/log/auth.log` per login sudo | CloudTrail per tutte le chiamate API |
| `last` mostra ultimi login | IAM Access Analyzer mostra attivita |
| Manuale correlare eventi | Ricerche automatiche su CloudTrail Logs |

**Implicazione:** Nel cloud hai audit trail automatico, completo e ricercabile. Localmente devi configurare e mantenere i log.

### 4. Autenticazione

| Locale | Cloud |
|--------|-------|
| Password, SSH key | Access Key ID, Secret Access Key, Session Token |
| Password scade mai (default) | Access keys devono essere ruotate regolarmente |
| MFA non disponibile | MFA obbligatorio per root/users in molte organizzazioni |

**Implicazione:** Nel cloud, l'autenticazione e piu sicura di default (rotazione automatica, MFA, sessioni temporanee).

---

## Comandi Equivalenti: Quick Reference

| Operazione | Locale | Cloud AWS |
|------------|--------|-----------|
| **Crea utente** | `sudo useradd -m user` | `aws iam create-user --user-name user` |
| **Aggiungi a gruppo** | `sudo usermod -aG docker user` | `aws iam add-user-to-group --group-name Developers --user-name user` |
| **Verifica permessi** | `groups user` | `aws iam list-attached-user-policies --user-name user` |
| **Test accesso** | `sudo -u user docker ps` | `aws sts get-caller-identity` |
| **Eleva privilegi** | `sudo command` | `aws sts assume-role` |
| **Revoca permessi** | `sudo gpasswd -d user docker` | `aws iam detach-user-policy --user-name user --policy-arn ...` |
| **Elimina utente** | `sudo userdel user` | `aws iam delete-user --user-name user` |

---

## Best Practices Transferibili

### 1. Mai Usare Root per Lavoro Normale

**Locale:**
```bash
# SBAGLIATO: Log in come root
ssh root@server

# GIUSTO: Log in come utente normale, usa sudo quando serve
ssh user@server
sudo command
```

**Cloud:**
```bash
# SBAGLIATO: Usa root account AWS (l'email con cui ti sei registrato)
# Mai usare root account per operazioni quotidiane

# GIUSTO: Crea IAM User con permessi limitati
aws iam create-user --user-name daily-ops-user
aws iam attach-user-policy --user-name daily-ops-user --policy-arn ...
```

### 2. Usa Gruppi per Gestire Permessi

**Locale:**
```bash
# Invece di dare permessi a ogni singolo utente
sudo usermod -aG docker user1
sudo usermod -aG docker user2
sudo usermod -aG docker user3

# Tutti automaticamente ereditano i permessi del gruppo docker
```

**Cloud:**
```bash
# Invece di attachare policy a ogni singolo utente
aws iam create-group --group-name Developers
aws iam attach-group-policy --group-name Developers --policy-arn ...
aws iam add-user-to-group --group-name Developers --user-name user1
aws iam add-user-to-group --group-name Developers --user-name user2

# Tutti automaticamente ereditano le policies del gruppo Developers
```

### 3. Verifica i Permessi

**Locale:**
```bash
# Verifica che l'utente abbia i permessi corretti
groups user
id user
sudo -u user docker ps
```

**Cloud:**
```bash
# Verifica che l'utente abbia le policies corrette
aws iam list-attached-user-policies --user-name user
aws iam simulate-principal-policy --policy-source-arn ... --action-names s3:GetObject
```

---

## Conclusione

I concetti che hai imparato in questo lab - utenti, gruppi, permessi - si applicano direttamente ad AWS IAM e altri cloud provider. La differenza principale e la scala e la complessita: nel cloud, questi concetti sono potenziati con condizioni granulari, audit automatico, e credenziali ruotabili.

Quando lavorerai con AWS IAM, ricorda:
- IAM User = Utente Linux (identità)
- IAM Group = Gruppo Linux (raccolta di utenti con stessi permessi)
- IAM Policy = Permessi file/socket (regole di accesso)
- Service Endpoint = Socket Docker (risorsa protetta)

Comprendendo questi parallelismi, sarai in grado di applicare le conoscenze locali al cloud con fiducia.

---

## Approfondimenti

- [AWS IAM Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)
- [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
- [Tutorial: Permessi Docker](../tutorial/02-docker-group-permissions.md)
- [Reference: Tabella Parallelismi](../reference/iam-parallels.md)
```

Key points:
- Clear explanation of IAM concepts
- Side-by-side comparisons
- Practical examples
- Best practices transferable to cloud
- Links to AWS documentation
- Covers PARA-01 (Docker mapped to IAM), PARA-03 (differences documented), PARA-04 (commands shown)
  </action>
  <verify>
    <automated>test -f labs/lab-01-iam/explanation/docker-iam-parallels.md && grep -q "IAM\|AWS\|differenza\|difference" labs/lab-01-iam/explanation/docker-iam-parallels.md && wc -l labs/lab-01-iam/explanation/docker-iam-parallels.md | awk '{if($1>=80) print "PASS"; else print "FAIL: Explanation too short ("$1" lines, expected 80+)"}'</automated>
  </verify>
  <done>Explanation document created with IAM parallels and local-cloud differences</done>
</task>

</tasks>

<verification>
1. All 4 Diátaxis document types exist: tutorial/, how-to-guides/, reference/, explanation/
2. Tutorial follows "little often" principle (small incremental steps)
3. How-to guides are procedure-focused (not tutorial-style)
4. Reference documents are technical specifications without tutorial content
5. Explanation document draws clear parallels between Docker and IAM (PARA-01, PARA-03, PARA-04)
6. All documents use Italian language without emojis
7. All documents have cross-references to related content
</verification>

<success_criteria>
1. Tutorial has 3 parts covering user creation, Docker permissions, and verification
2. How-to guides cover common procedures independent of tutorial flow
3. Reference documents provide technical specifications in quick-reference format
4. Explanation document clearly maps Docker concepts to AWS IAM concepts
5. All requirement IDs satisfied: LAB-01, DOCT-01, DOCT-02, DOCT-03, DOCT-04, DOCT-05, PARA-01, PARA-03, PARA-04
</success_criteria>

<output>
After completion, create `.planning/phases/02-lab-01-iam-sicurezza/02-02-SUMMARY.md`
</output>