From 77235820acadbc49f1f48830534556f2e10637b4 Mon Sep 17 00:00:00 2001 From: Luca Sacchi Ricciardi Date: Tue, 24 Mar 2026 22:27:03 +0100 Subject: [PATCH] feat(02-02): create explanation document for IAM parallels - docker-iam-parallels.md: Conceptual mapping between Docker and AWS IAM - Side-by-side comparisons with practical examples - Covers PARA-01, PARA-03, PARA-04 requirements - Explains least privilege principle and best practices - Links to AWS documentation for deeper learning --- .../explanation/docker-iam-parallels.md | 361 ++++++++++++++++++ 1 file changed, 361 insertions(+) create mode 100644 labs/lab-01-iam/explanation/docker-iam-parallels.md diff --git a/labs/lab-01-iam/explanation/docker-iam-parallels.md b/labs/lab-01-iam/explanation/docker-iam-parallels.md new file mode 100644 index 0000000..16bbad4 --- /dev/null +++ b/labs/lab-01-iam/explanation/docker-iam-parallels.md @@ -0,0 +1,361 @@ +# 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)