lucasacchi/laboratori-cloud
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(02-02): create explanation document for IAM parallels

Browse Source 
- 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
This commit is contained in:
Luca Sacchi Ricciardi
2026-03-24 22:27:03 +01:00
parent cc3a28f192
commit 77235820ac
1 changed files with 361 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

361
labs/lab-01-iam/explanation/docker-iam-parallels.md Normal file
View File

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