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

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

# 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 con utente non-root
FROM alpine:3.19
RUN adduser -D -u 1000 appuser
USER appuser
CMD ["sh", "-c", "whoami"]

Verifica:

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:

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

Verifica:

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

{
  "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:

# SBAGLIATO: Log in come root
ssh root@server

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

Cloud:

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

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

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

# Verifica che l'utente abbia i permessi corretti
groups user
id user
sudo -u user docker ps

Cloud:

# 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
• IAM Best Practices
• Tutorial: Permessi Docker
• Reference: Tabella Parallelismi