Quando si avvia una trasformazione, avere un piano fa la differenza. Una delle sfide più grandi per qualsiasi azienda alle prese con iniziative di ampio respiro è capire da dove partire, chi coinvolgere e con chi collaborare per arrivare al successo. Indipendentemente dalla struttura organizzativa — divisionale, a matrice, piatta o di altro tipo — fissando obiettivi ambiziosi e avviando proof of concept (PoC) frequenti e tempestivi, ci si muove nella direzione giusta.
Questo articolo propone un punto di vista preciso su come strutturare la propria infrastruttura cloud. Si basa sull'esperienza maturata di recente nella guida di trasformazioni cloud enterprise per organizzazioni FinTech (regolamentate) con prodotti SaaS e nella ri-architettura di applicazioni legacy per farle girare sul servizio Kubernetes gestito di Google, GKE. L'obiettivo è mettere in luce gli aspetti da pianificare e progettare in termini di rete, budget, DevOps, sicurezza e compliance. In articoli successivi approfondirò molti di questi temi con esempi specifici e demo.
Strutturare la propria azienda su Google Cloud Platform
In sintesi
- Verifichi di avere un allineamento organizzativo
- Scelga il Suo percorso
- Configuri le identità con gruppi utente e ruoli
- Centralizzi le reti con le Shared VPC
- Pianifichi tutte le risorse
- Etichetti le risorse per una reportistica più efficace
- Imposti gli alert di budget
- Organizzi i repository del codice sorgente per l'IaC
- Imposti gli alert di sicurezza e monitoraggio
- Utilizzi un bastion host (jump host)
- Protegga i dati
- Utilizzi il Cloud Security Command Center
- Documenti e testi i piani di Disaster Recovery e Business Continuity
- Si affidi a esperti che ci sono già passati
Verifichi di avere un allineamento organizzativo
Anche se questo articolo si concentra sulle funzionalità di Google Cloud Platform (GCP), sarebbe scorretto non citare il CEO di AWS, Andy Jassy, che ha sintetizzato con grande efficacia i quattro pilastri del successo nella trasformazione cloud — e oserei dire nel successo di qualsiasi iniziativa:
- Convinzione e allineamento del senior leadership team
- Obiettivi ambiziosi calati dall'alto
- Formare i propri builder
- Non lasciare che la paralisi [da analisi] blocchi tutto sul nascere
Il mio mantra personale quando provo qualcosa di nuovo è: "prima fallo funzionare, poi fallo bene, infine fallo veloce".
Scelga il Suo percorso
Google mette a disposizione online ottime risorse sulle best practice enterprise, e qui sotto trova un'illustrazione con i passaggi consigliati per i Secure Google Cloud Services. Le esigenze variano da organizzazione a organizzazione, perciò questa roadmap rappresenta un ottimo punto di partenza per pianificare la propria infrastruttura o per farsi un'idea di ciò che è disponibile.
Fonte: Google
Configuri le identità con gruppi utente e ruoli
Conviene partire da una policy basata sul principio del minimo privilegio e disabilitare subito la possibilità di creare progetti a livello di organizzazione. Solo DevOps, Billing e OrgAdmin dovrebbero avere questa facoltà, idealmente attraverso un solo service account in DevOps dedicato all'automazione dell'infrastruttura (per esempio Terraform). Ovunque sia possibile, non aggiunga singoli utenti all'IAM.
- Organization Administrators ([email protected])
- Network Administrators ([email protected])
- Security Administrators ([email protected])
- Billing Administrators ([email protected])
- DevOps ([email protected])
- Development ([email protected])
- DataScience ([email protected]) [opzionale]
Una volta creati questi gruppi, eventualmente con Cloud Identity (collegandosi al proprio AD o IdP esistente) o nella propria organizzazione GSuite, aggiunga almeno una persona per gruppo. A quel punto assegni i ruoli necessari a ciascun gruppo solo quando servono davvero, a livello di organizzazione o di cartella.
Fonte: Google
Se segue l'approccio GitOps, i team di sviluppo possono distribuire qualsiasi workloads* nei rispettivi namespace dei cluster Kubernetes tramite pipeline CI/CD a partire dal source control. Questo approccio agevola la gestione di accessi e quote, semplificando il controllo dei costi cloud e il budgeting.
*solo binari approvati provenienti da un image repository privato e affidabile
Centralizzi le reti con le Shared VPC
Nei settori altamente regolamentati o quando si deve mantenere la compliance — per esempio SOC 2 — i controlli possono richiedere una rigorosa separazione delle responsabilità. Una pratica enterprise diffusa consiste nel separare la gestione della rete dal DevOps e dallo sviluppo applicativo. GCP semplifica tutto questo grazie alla sua shared VPC e a un'elegante gerarchia di progetti, ovvero host project e service project.
Progetti e pianifichi la rete in modo da evitare collisioni ed elimini tutte le reti predefinite all'interno dei progetti — mi ringrazierà più avanti!
Come anticipato, è un approccio con un punto di vista preciso, ma il Suo potrebbe essere diverso. La best practice che consiglio è incapsulare i service project in un host project e centralizzare la configurazione di rete in un unico punto, concedendo l'accesso a questi progetti solo al gruppo dei network administrator.
Quando assegna gli IP alle subnet, in base alla scala e ai piani di crescita, un range CIDR /16 per una VPC dovrebbe essere ampiamente sufficiente (65.000 indirizzi). Kubernetes, però, richiede un gran numero di IP per servizi e pod, perché vengono assegnati dinamicamente a container effimeri. Suggerisco di riservare un range aggiuntivo non utilizzato per gli IP secondari, come segue:
- subnet all'interno del range VPC /16: k8s-nodes-prod (10.10.0.0/22)
secondaria: k8s-services-prod (10.80.64.0/22)
secondaria: k8s-pods-prod (10.80.0.0/18)
subnet: bastion-prod (10.10.64.0/29)
- subnet all'interno del range VPC /16: k8s-nodes-stage (10.11.0.0/22)
secondaria: k8s-services-stage (10.81.64.0/22)
secondaria: k8s-pods-stage (10.81.0.0/18)
subnet: bastion-stage (10.11.64.0/29)
- subnet all'interno del range VPC /16: k8s-nodes-demo (10.12.0.0/22)
secondaria: k8s-services-demo (10.82.64.0/22)
secondaria: k8s-pods-demo (10.82.0.0/18)
subnet: bastion-demo (10.12.64.0/29)
- subnet all'interno del range VPC /16: k8s-nodes-qa (10.13.0.0/22)
secondaria: k8s-services-qa (10.83.64.0/22)
secondaria: k8s-pods-qa (10.83.0.0/18)
subnet: bastion-qa (10.13.64.0/29)
- subnet all'interno del range VPC /16: k8s-nodes-dev (10.14.0.0/22)
secondaria: k8s-services-dev (10.84.64.0/22)
secondaria: k8s-pods-dev (10.84.0.0/18)
subnet: bastion-dev (10.14.64.0/29)
In questo modo resta ampio spazio nella VPC per ulteriori subnet dedicate a database server o ad altre risorse.
Pianifichi tutte le risorse
Google Cloud Platform organizza le risorse per organizzazione, cartella e progetto. In questo modo è più semplice gestire utenti e gruppi senza la multi-account madness tipica di altre piattaforme. Molte aziende che hanno adottato il cloud agli albori si trovano oggi a costruire soluzioni custom per gestire questo "caos" di account e permessi: un incubo per InfoSec e compliance — su questo aspetto GCP ci ha visto giusto.
├── DevOps
│ └── project-devops
│ ├── bucket-terraform-state
│ ├── cluster-devops
│ │ ├── namespace-cicd
│ │ └── namespace-vault
│ ├── sink-application-logs
│ └── sink-audit-logs
├── RnD
│ ├── Non-Production
│ │ └── project-shared-network-nonprod
│ │ ├── sink-application-logs
│ │ ├── sink-audit-logs
│ │ ├── vpc-demo-10-12-0-0
│ │ │ └── project-demo
│ │ │ ├── cluster-demo
│ │ │ │ ├── namespace-team1
│ │ │ │ ├── namespace-team2
│ │ │ │ └── namespace-vault
│ │ │ ├── sink-application-logs
│ │ │ └── sink-audit-logs
│ │ ├── vpc-dev-10-14-0-0
│ │ │ └── project-development
│ │ │ ├── cluster-development
│ │ │ │ ├── namespace-team1
│ │ │ │ ├── namespace-team2
│ │ │ │ └── namespace-vault
│ │ │ ├── sink-application-logs
│ │ │ └── sink-audit-logs
│ │ └── vpc-qa-10-13-0-0
│ │ └── project-development
│ │ └── cluster-qa
│ │ ├── namespace-team1
│ │ ├── namespace-team2
│ │ └── namespace-vault
│ ├── Production
│ │ └── project-shared-network-prod
│ │ ├── sink-application-logs
│ │ ├── sink-audit-logs
│ │ ├── vpc-prod-10-10-0-0
│ │ │ └── project-production
│ │ │ ├── cluster-production
│ │ │ │ ├── namespace-team1
│ │ │ │ ├── namespace-team2
│ │ │ │ └── namespace-vault
│ │ │ ├── sink-application-logs
│ │ │ └── sink-audit-logs
│ │ └── vpc-stage-10-11-0-0
│ │ └── project-stage
│ │ ├── cluster-stage
│ │ │ ├── namespace-team1
│ │ │ ├── namespace-team2
│ │ │ └── namespace-vault
│ │ ├── sink-application-logs
│ │ └── sink-audit-logs
│ └── project-monitoring
│ ├── bucket-development-logs
│ ├── bucket-production-logs
│ ├── workspace-development
│ └── workspace-production
└── Security
└── project-security
└── bucket-audit-logs
Etichetti le risorse per una reportistica più efficace
Una delle sfide più comuni e fonte di confusione con i public cloud è la fatturazione, insieme a reportistica e controllo dei costi. Un modo per tenere a bada la spesa è progettare l'infrastruttura con namespace basati sui team, come illustrato sopra. Questo accelera l'onboarding e la produttività degli sviluppatori, evitando curve di apprendimento ripide o pool di talenti più ristretti. Un'altra best practice è applicare tag/label alle risorse, così da poter impostare in seguito alert, budget e report.
Un mio collega ha scritto un articolo dal titolo "Auto Tagging Google Cloud Resources" che illustra come usare il nostro tool open source IRIS. Sull'argomento esistono molti altri articoli interessanti, perciò pianifichi i tag in anticipo per ridurre i grattacapi futuri.
Tag suggeriti per ciascuna risorsa:
- Owner — chi è attualmente responsabile (potrebbe aver cambiato team)
- Creator — chi l'ha creata in origine (potrebbero servire chiarimenti in seguito)
- Project — per esempio my-company-production, per un raggruppamento più efficace
- Working Hours — risparmi fino al 60% programmando in automatico le risorse di sviluppo con Zorya
Imposti gli alert di budget
Molti CFO sono diffidenti verso il cloud per la scarsa visibilità e per il rischio di una spesa fuori controllo a causa di configurazioni errate. Con i budget alert è possibile monitorare la spesa giornaliera e intervenire rapidamente per allineare la spesa cloud ai ricavi aziendali. È una buona idea condividere le informazioni sui costi con i team e chiedere ai team leader di incontrarsi periodicamente per monitorare il budget.
Organizzi i repository del codice sorgente per l'IaC
Una volta definita la pianificazione della gerarchia delle risorse, ci si trova davanti al classico dilemma dell'uovo e della gallina. Si fa il provisioning di tutto con Terraform e, in tal caso, come ottiene Terraform i permessi per costruire ogni cosa? Il consiglio è che l'Org Admin crei la cartella e il progetto DevOps, e che il team DevOps configuri un Terraform Service Account con i permessi necessari per creare ed eliminare progetti, e così via. Parta dal minimo indispensabile e, man mano che incontra errori, aggiunga i ruoli necessari.
Uno dei miei colleghi ha scritto un ottimo articolo dal titolo "Refactoring Terraform The Right Way", in linea con i suggerimenti del team di esperti di Gruntwork.io, creatori di Terragrunt. In sintesi: separi risorse, servizi e ambienti live in tre repository distinti e gestisca di conseguenza i permessi dei gruppi nel source control.
Imposti gli alert di sicurezza e monitoraggio
Monitoraggio e alerting dovrebbero stare al centro del processo di pianificazione e, fortunatamente, Google Cloud Platform mette a disposizione molte funzionalità integrate che semplificano il lavoro. La scansione del CIS benchmark nel Cloud Security Command Center (CSCC), riportata di seguito, rileva il monitoraggio mancante e fornisce istruzioni passo-passo per configurare correttamente ogni progetto. Trova maggiori informazioni sul CSCC più avanti.
Per comodità, ecco un Gist con le configurazioni di monitoraggio consigliate.
Utilizzi un bastion (jump) host per gli accessi
Per semplicità ho omesso le VM dei bastion host nel diagramma sopra, ma la best practice per un accesso sicuro prevede di usarli. Le suggerisco di aggiungere un range di subnet per progetto dedicato a una VM bastion host, eliminare tutti gli IP esterni e configurare cluster privati. Crei un managed instance group composto da una sola istanza, così che GCP ne avvii automaticamente una nuova in caso di guasto. Può collegarsi al bastion tramite VPN, oppure adottare l'approccio moderno e più sicuro con Cloud Identity Aware Proxy (IAP). Può rendere il bastion ancora più sicuro limitando le chiavi SSH degli utenti.
Fonte: Google
Esistono numerosi articoli sulle Kubernetes Best Practices, ma quello degli ingegneri di Google dal titolo "Completely Private GKE Clusters With No Internet Connectivity" è un buon riferimento e conferma la struttura di base proposta sopra.
Protegga i dati
È necessario pianificare e progettare l'infrastruttura per soddisfare le policy definite dal team di sicurezza della Sua organizzazione, e spesso questo include diversi livelli di crittografia. Le risorse GCP sono cifrate at rest per impostazione predefinita, ma occorre individuare le proprie esigenze in termini di chiavi di crittografia (gestite da Google, self-managed, BYOK) sia at rest sia in transit.
Potrebbe inoltre voler isolare l'accesso ai dati all'interno dell'organizzazione, fino al singolo utente o alla singola applicazione. Lo può fare con i VPC Service Controls, come illustrato di seguito.
Se invia log o dati per il monitoraggio, come illustrato nell'esempio di gerarchia delle risorse, può configurare i log sink per sfruttare le API di Cloud Data Loss Prevention (Cloud DLP) e rimuovere quasi 100 tipi di dati PII prima della memorizzazione.
Utilizzi il Cloud Security Command Center
Una gemma nascosta di GCP è il Cloud Security Command Center. Questo prodotto offre un single pane of glass per asset management, rilevamento di minacce e anomalie, WAF e vulnerability scanning. A mio avviso una delle funzionalità più interessanti è proprio la scansione: si possono scegliere i progetti da analizzare, ma non è possibile decidere quando viene eseguita la scansione (1–2 volte al giorno). Evidenzia le violazioni dei benchmark CIS e NIST per ogni progetto e risorsa, fornendo indicazioni passo-passo per la remediation.
Nota: il nuovo pricing dividerà CSCC in due tier (free, premium)
Cloud Security Command Center — fonte wideops.com
- Un'ottima risorsa/checklist sono i CIS Benchmarks for Google Cloud — ne esistono di specifici anche per Kubernetes e altri sistemi, tutti gratuiti
Esistono altri ottimi tool di terze parti come Forseti Security e Prisma Cloud di Palo Alto Networks per scansionare e ottimizzare configurazioni e deployment del codice (in precedenza noti come Twistlock e Redlock).
Documenti e testi i piani di Disaster Recovery e Business Continuity
Va da sé, ma è doveroso ribadirlo: serve un piano automatizzato di backup e recovery per tutti i dati, sia in bucket sia nei database. È buona norma testare il processo di backup e ripristino almeno una volta all'anno, ma preferibilmente con frequenza maggiore.
Per la business continuity e per dormire sonni tranquilli, è altamente consigliato definire l'infrastruttura come codice (IaC) tramite Terraform. Se il Suo team mantiene con disciplina lo stato dell'infrastruttura come codice, sarà semplice produrre report di audit per la compliance e ripristinare tutto in caso di guasto catastrofico.
Si affidi a esperti che ci sono già passati
Ho solo sfiorato la superficie delle considerazioni chiave nelle trasformazioni cloud enterprise, e tutto questo può sembrare scoraggiante: la cosa migliore da fare è semplicemente iniziare. Sarò di parte, ma la seconda cosa migliore per aumentare le probabilità di successo è affiancarsi a professionisti che hanno già percorso questa strada molte volte.
DoiT International ha aiutato migliaia di aziende nel loro percorso cloud con architecture review, supporto specialistico e tool personalizzati per budgeting e reportistica cloud — il tutto senza costi aggiuntivi per i nostri clienti (siamo un cloud reseller partner). Il nostro obiettivo è formare il Suo team e metterlo nelle condizioni di gestire con successo la propria infrastruttura cloud, ma quando serve siamo sempre al Suo fianco.
Vuole leggere altri articoli di Mike? Visiti il nostro blog su Medium, oppure segua Mike su Twitter.