laboratori-cloud/labs/lab-01-iam/explanation/docker-iam-parallels.md

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