Cloud Intelligence™
Kubernetes e gestione dei secret nel cloud
Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.
About Alexei Ledenev
Long ago, in a perfectly ordinary corner of the software universe, I started persuading computers, clouds, containers, and Kubernetes clusters to behave in ways that were useful, reliable, and occasionally intentional.
Since then, I’ve led architecture and engineering teams, built cloud platforms, designed distributed systems, and created open-source tools such as pumba, KubeIP, kube-secrets-init, and ccgram - because apparently production systems were not failing in enough interesting ways on their own.
My work lives somewhere between Software Architecture, Kubernetes, Cloud, chaos engineering, and AI infrastructure: the sort of place where dashboards glow green, alarms remain suspiciously quiet, and everyone hopes DNS has read the plan.
I enjoy building practical tools for complicated systems, automating the boring parts, understanding the dangerous parts, and reminding infrastructure - gently, but firmly - that uptime is not just a lifestyle choice. 🪐
My personal page
I secret sono fondamentali per il funzionamento di molti sistemi in produzione. La loro esposizione accidentale rientra tra i rischi principali e va gestita con attenzione. Gli sviluppatori devono fare il possibile per proteggere i secret delle applicazioni.
Il problema si fa ancora più complesso quando un'azienda adotta un'architettura a microservizi e diversi servizi devono accedere a secret differenti per funzionare correttamente. Da qui nasce una nuova sfida: come distribuire, gestire, monitorare e ruotare i secret delle applicazioni evitando esposizioni accidentali?
Kubernetes Secrets
Kubernetes mette a disposizione un oggetto chiamato Secret, che permette di memorizzare dati sensibili delle applicazioni come password, chiavi SSH, API key, token e altro ancora. Un Kubernetes Secret può essere iniettato in un container di un Pod come variabile d'ambiente oppure montato come file. Grazie ai Kubernetes Secrets è possibile separare i dati sensibili e la configurazione dal deployment dell'applicazione.
Per esempio, un secret di Kubernetes si può creare con il comando kubectl create secret:
https://gist.github.com/02c582490747681776f1f480ec2f4165
oppure tramite un file Kubernetes db-credentials.yaml che descrive lo stesso secret:
Attenzione: archiviare dati sensibili in un Kubernetes Secret non li rende automaticamente sicuri. Per impostazione predefinita, tutti i dati nei Kubernetes Secrets sono salvati in chiaro e codificati in base64.
A partire dalla versione 1.13, Kubernetes supporta la cifratura at rest dei dati dei Secret, tramite l'oggetto EncryptionConfiguration con un provider di cifratura integrato o esterno.
Elenco dei provider di cifratura attualmente supportati:
Provider integrati: aescbc, aesgsm, secretbox
Tuttavia, la cifratura at rest dei Secret non è attiva per impostazione predefinita. E anche quando viene abilitata, da sola non basta e non può essere considerata una soluzione completa di gestione dei secret.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
Una soluzione completa per la gestione dei secret deve garantire anche distribuzione, rotazione, controllo degli accessi a granularità fine, audit log, monitoraggio dell'utilizzo, versionamento, storage cifrato in modo robusto, API e SDK client comodi da usare, oltre probabilmente ad altre funzionalità utili.
Cloud Secrets Management
Diversi cloud vendor offrono servizi di gestione dei secret all'interno delle proprie piattaforme cloud, per aiutare a proteggere i secret necessari ad accedere ad applicazioni, servizi e API. Affidarsi a questi servizi evita di inserire informazioni sensibili in chiaro nel codice e di sviluppare cicli di gestione dei secret fai-da-te. I servizi di Secrets Management permettono di controllare l'accesso ai secret delle applicazioni con permessi a granularità fine e tracciamento degli accessi.
Integrare Kubernetes con i servizi di Secrets Management
In linea generale, qualsiasi applicazione può sfruttare un SDK o un'API specifica del vendor per accedere ai secret memorizzati in un servizio di Secrets Management. Di solito ciò comporta modificare il codice dell'applicazione oppure ricorrere a script di bootstrap o a Init containers, utilizzando strumenti CLI client o web API.
Tutto più semplice con lo strumento secrets-init
Oggi rilasciamo doitintl/secrets-init: uno strumento open source (Apache License 2.0) che semplifica l'integrazione dei servizi cloud-native di Secrets Management con workloads containerizzati eseguiti su cluster Kubernetes gestiti dal cloud o autogestiti.
In sostanza, secrets-init è un sistema init minimale, pensato per essere eseguito come PID 1 all'interno di un ambiente container, in modo analogo a dumb-init, e offre un'integrazione fluida con diversi servizi cloud-native di Secrets Management, tra cui:
Perché serve un sistema init in un container Docker?
Suggeriamo di leggere la spiegazione nel repo Yelp dumb-init
In sintesi:
- Inoltro corretto dei segnali
- Reaping degli zombie orfani
Cosa fa secrets-init
secrets-init viene eseguito come PID 1 e si comporta come un semplice sistema init usato come ENTRYPOINT o primo comando del container: il suo compito è avviare un processo figlio e inoltrare tutti i segnali di sistema alla sessione che ha quel processo come radice. È in questo che consiste, in sostanza, un processo init. Allo stesso tempo, secrets-init propaga quasi tutte le variabili d'ambiente senza modificarle, sostituendo le speciali variabili secret con i valori recuperati dai servizi di Secret Management.
Integrazione con Docker
secrets-init è un file binario compilato staticamente (senza dipendenze esterne) e può essere facilmente incluso in qualsiasi immagine Docker. È sufficiente scaricare il binario di secrets-init e impostarlo come ENTRYPOINT del container Docker.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
Per esempio:
https://gist.github.com/7efe25155c034ee1b978a2477b3224e4
Integrazione con Kubernetes
Per usare secrets-init con un oggetto Kubernetes (Pod/Deployment/Job/ecc.) senza modificare l'immagine Docker, conviene iniettare secrets-init nel Pod di destinazione tramite un initContainer. Si può utilizzare l'immagine Docker doitint/secrets-init oppure crearne una propria. Basta copiare il binario secrets-init dall'init container in un volume condiviso e modificare il command del Pod in modo che esegua secrets-init come primo comando.
Integrazione con AWS Secrets Manager
Per iniziare a usare secrets-init con AWS Secrets Manager, è sufficiente impostare un ARN di secret AWS come valore di una variabile d'ambiente. secrets-init risolverà il valore della variabile d'ambiente, sulla base dell'ARN specificato, restituendo il valore del secret referenziato.
Esempio di utilizzo di secrets-init con un Job Kubernetes:
https://gist.github.com/6ae6d57ed08b26c64f534f87fc1872df
Integrazione con AWS Systems Manager Parameter Store
AWS Systems Manager Parameter Store consente di memorizzare i parametri delle applicazioni in chiaro o cifrati (una sorta di secret).
Come nell'esempio precedente, è possibile impostare un ARN di AWS Parameter Store come valore di una variabile d'ambiente. secrets-init risolverà il valore della variabile d'ambiente, sulla base dell'ARN specificato, restituendo il valore del parametro referenziato.
Esempio di formato di AWS Systems Manager Parameter Store:
https://gist.github.com/9a7a83ec1659c391412557e5af340f42
Per recuperare i secret AWS da AWS Secrets Manager e da Parameter Store, secrets-init deve essere eseguito con un ruolo IAM autorizzato ad accedere ai secret desiderati.
Lo si può ottenere assegnando il ruolo IAM al Pod Kubernetes o al task ECS. Si veda il post sul blog EKS Introducing fine-grained IAM roles for service accounts.
È anche possibile assegnare il ruolo IAM all'istanza EC2 su cui gira il container, ma questa opzione è decisamente meno sicura e non è consigliata.
Integrazione con Google Secret Manager
Google Cloud ha rilasciato di recente un nuovo servizio per la gestione dei secret nel cloud: Google Secret Manager
È possibile impostare il nome di un secret Google come valore di una variabile d'ambiente, utilizzando il prefisso riconosciuto da secrets-init (gcp:secretmanager:) seguito dal nome del secret (projects/{PROJECT_ID}/secrets/{SECRET_NAME} oppure projects/{PROJECT_ID}/secrets/{SECRET_NAME}/versions/{VERSION}). secrets-init risolverà il valore della variabile d'ambiente, sulla base del nome specificato, restituendo il valore del secret referenziato.
https://gist.github.com/65d46eb2b1fe44417a9d91828c94712d
Per recuperare i secret Google da Google Secret Manager, secrets-init deve essere eseguito con un ruolo IAM autorizzato ad accedere ai secret desiderati.
Lo si può ottenere assegnando il ruolo IAM al Pod Kubernetes tramite Workload Identity. È anche possibile assegnare il ruolo IAM all'istanza GCE su cui gira il container, ma questa opzione è meno sicura.
(15–03–2020) Aggiornamento: Kubernetes Admission Webhook
Il progetto kube-secrets-init implementa un admission webhook Kubernetes che inietta un initContainer in qualsiasi Pod con riferimenti espliciti (variabili d'ambiente) o impliciti (Secrets e ConfigMaps di Kubernetes) a secret nel cloud.
Link utili
- Kubernetes GKE Workload Identity – post sul blog DoiT
- doitintl/secrets-init – repository GitHub
- kube-secrets-init – repository GitHub dell'admission webhook Kubernetes
Conclusioni
Mi auguro che questo articolo le sia utile. Resto a disposizione per commenti e domande.
Vuole leggere altri contenuti? Visiti il nostro blog o segua Alexei su Twitter.
