Defender for Containers copre postura, vulnerabilità, runtime e supply chain. Le leve che contano sono due: come raccoglie i dati e cosa fa quando trova qualcosa.

Defender for Containers: agentless o sensore

Nelle impostazioni del piano ogni componente ha un ruolo preciso:

Environment settings > sottoscrizione > Containers > Settings
- Agentless scanning for machines   vulnerabilità e segreti sui nodi
- Defender sensor                   DaemonSet, telemetria runtime
    - Defender Security Gating      admission control
    - Defender Runtime Anti Malware
- Azure Policy                      valutazioni di postura
- Kubernetes API access             inventario e configurazione
- Registry access                   scansione delle immagini
    - Security findings

Security findings non si abilita via Azure Policy, solo da questo interruttore. L’agentless discovery è API-based e a impatto zero; il sensore serve per tutto ciò che è runtime, cioè antimalware, rilevamento DNS, binary drift e gating.

Le immagini nuove nel registry vengono analizzate in poche ore, poi c’è un rescan giornaliero limitato a quelle pushate o pullate negli ultimi 30 giorni o in esecuzione. Un’immagine ferma da oltre 30 giorni smette di ricevere aggiornamenti: basta pullarla. La scansione a runtime non copre i nodi Windows né quelli con dischi OS effimeri AKS.

Misconfigurazioni e rischi a runtime

Il data plane hardening passa da Azure Policy for Kubernetes. La trappola: le policy valutano in audit per default, e per bloccare devi portare l’effetto a Deny dalla scheda Take action della raccomandazione, scegliendo lo scope. Secondo dettaglio: alcune raccomandazioni non funzionano finché non le parametrizzi. Container images should be deployed from trusted registries only richiede l’elenco dei registry fidati, e senza parametri le risorse risultano unhealthy.

Il binary drift è l’altro controllo di runtime: un container che esegue un binario assente dall’immagine originale è sospetto per definizione. Richiede il sensore. Le regole si scrivono in Environment settings > Containers drift policy: azione Drift detection alert, Drift detection blocking o Ignore drift detection, ambito per cluster, immagine, namespace, pod o label, più una allow list di processi. Si valuta per priorità fermandosi al primo match, e la regola di default è Ignore drift detection: finché non la cambi non succede nulla. I sensori recepiscono la policy entro 30 minuti.

AKS: API server, identità, nodi

Per default l’API server ha un IP pubblico e un FQDN. Due modi di chiuderlo: authorized IP ranges, solo con load balancer Standard, non sui cluster privati, fino a 200 range, oppure API Server VNet Integration, che ne regge 2000. Il valore 0.0.0.0/32 è un caso speciale: consente solo l’IP di uscita del load balancer del cluster.

Sull’autenticazione la scelta è fra identità Entra e local accounts, cioè un certificato di cluster admin che bypassa Entra: in produzione va disabilitato. Sull’autorizzazione, Kubernetes RBAC vive nel cluster mentre Azure RBAC per Kubernetes centralizza i permessi in Entra, con una sola assegnazione a livello di sottoscrizione o management group.

Per i pod si usa Microsoft Entra Workload ID: OIDC issuer sul cluster, federated identity credential sull’identità gestita, annotazione azure.workload.identity/client-id sul service account e label azure.workload.identity/use a true sul pod. La label è obbligatoria: senza, i pod falliscono dopo un riavvio. Limite: 20 federated identity credential per identità gestita. La pod-managed identity è deprecata.

I nodi stanno in subnet privata senza IP pubblici, con SSH abilitato per default ma raggiungibile solo dall’IP interno. Non modificare l’NSG a livello di NIC gestito da AKS: si aggiungono NSG di subnet. I Secret Kubernetes sono base64 in etcd, quindi per cifrarli con chiave del cliente serve il KMS etcd encryption.

Container Registry: chi si autentica e da dove

L’admin account è disabilitato per default e va lasciato così: è un unico account con permessi pieni, condiviso e non attribuibile. Il token di az acr login vale 3 ore; il segreto di un service principal scade per default dopo un anno.

Sui ruoli conta la modalità del registry, in Properties. RBAC Registry + ABAC Repository Permissions abilita i ruoli granulari Container Registry Repository Reader, Writer e Contributor, con condizioni ABAC per limitarli a repository specifici; RBAC Registry Permissions usa i vecchi AcrPull, AcrPush e AcrDelete. Attenzione: i ruoli Repository non danno il permesso di elencare il catalogo, che sta in Container Registry Repository Catalog Lister.

Anonymous pull è disattivo per default, esiste solo su Standard e Premium e vale per tutti i repository: se lo accendi, i permessi per repository non proteggono più nulla. Il private endpoint richiede Premium e la zona privatelink.azurecr.io, con record per l’endpoint del registry e per i data endpoint di ogni replica. Disabilitato l’accesso pubblico, az acr build smette di funzionare e i trusted services, Defender for Cloud incluso, entrano solo col bypass.

Container Instances e Container Apps

Su ACI: immagini da registry privato, identità gestita o service principal al posto dell’admin account, segreti in Key Vault, nessun container privilegiato. Nota pratica: distribuire dal portale un’immagine da ACR ad ACI richiede ancora l’admin account, percorso da evitare in produzione.

Container Apps ha identità gestita di sistema o assegnata dall’utente, usabile anche per il pull da ACR senza credenziali admin; i segreti stanno a livello di applicazione, isolati dalle revisioni, e possono essere reference a Key Vault. Le restrizioni IP di ingress hanno una regola non ovvia: non si mescolano regole Allow e Deny, e senza regole tutto il traffico in ingresso è ammesso.