Il computing riservato sfrutta un ambiente di esecuzione attendibile (TEE) per proteggere la memoria in uso, che aiuta a garantire la crittografia dei dati inattivi, in transito e in uso. I container riservati combinano l'ambiente TEE con i deployment Kubernetes. Il deployment di un TEE a livello di pod consente un solido isolamento dei carichi di lavoro, non solo dagli altri carichi di lavoro nel cluster, ma anche dagli amministratori del cluster.

La difficoltà con i container riservati è capire da dove iniziare. La decisione di eseguire il deployment di un pod in un container riservato richiede la modifica di una sola riga nel manifest del pod. Tuttavia, per iniziare è necessario distribuire correttamente una serie di componenti, idealmente su più cluster. Red Hat ha recentemente rilasciato il supporto per i container riservati su Microsoft Azure in Red Hat OpenShift Sandboxed Container Operator v1.9 e versioni successive, e il supporto per l'attestazione remota con la versione Red Hat di Trustee.

Questo blog descrive come utilizzare i modelli convalidati per raggiungere tre obiettivi:

1. Muovere i primi passi con i container riservati (Confidential Containers, CoCo) con OpenShift Sandboxed Containers Operator e la versione Red Hat di Trustee su Azure.
2. Fornire una base coerente e dichiarativa per i CoCo, per consentire i deployment delle procedure consigliate.
3. Dimostrare come eseguire il deployment delle applicazioni con i CoCo.

Panoramica dei modelli convalidati 

I modelli convalidati sono architetture di codice realizzate per diversi scenari di utilizzo in ambienti multicloud e hybrid cloud. Ogni modello viene testato e, una volta perfezionato, aggiunto al flusso di integrazione continua (CI) di Red Hat. In questo modo siamo certi che i test avvengano con la versione più recente degli operatori, le versioni di OpenShift e in più ambienti di cloud pubblico.

Ogni repository di modelli convalidati da Red Hat presenta uno scenario di utilizzo aziendale costituito da risorse Kubernetes (grafici helm, kustomize e oggetti primitivi) che descrivono uno stack hybrid cloud in modo dichiarativo e completo, dai servizi all'infrastruttura di supporto. I modelli convalidati semplificano i deployment complessi e altamente riproducibili e sono ideali per gestire deployment scalabili utilizzando le procedure operative di GitOps.

Perché utilizzare i modelli convalidati? 

Il deployment di soluzioni aziendali complesse prevede più passaggi. Ogni passaggio, se eseguito in modo impreciso, può introdurre potenziali errori o inefficienze. I modelli convalidati risolvono questo problema fornendo un processo di deployment già convalidato e automatizzato che:

• Utilizza un modello GitOps per distribuire lo scenario di utilizzo come codice.
• Funge come Proof of Concept (PoC) modificato per soddisfare esigenze specifiche e può essere trasformato in un vero e proprio deployment.
• È altamente riproducibile, quindi è l'ideale per operare in modo scalabile.
• I modelli convalidati sono predisposti per la collaborazione. Chiunque può suggerire miglioramenti, offrire il proprio contributo o utilizzarli perché tutti i repository Git sono upstream.
• Ogni modello convalidato può essere modificato in base alle tue esigenze specifiche. Se intendi sostituire un componente (ad esempio utilizzare lo Ceph storage invece di S3), è sufficiente commentare le sezioni pertinenti della configurazione e includere un altro repository.
• È testato. Una volta convalidato il modello, lo scenario di utilizzo viene incluso nel flusso CI di Red Hat e continua a essere testato su tutte le versioni del prodotto finché il modello rimane attivo.

I modelli convalidati sono una soluzione "tutto compreso". Indipendentemente dal punto in cui ti trovi nell’utilizzo del framework dei modelli, vengono forniti sia il core che un set di componenti configurabili pronti all'uso. Per questo articolo, ho utilizzato un modello convalidato, per iniziare a utilizzare i container riservati in modo semplice.

Come eseguire il deployment di un modello

Il sito web dei modelli convalidati contiene un'ampia documentazione su come utilizzarli. Le procedure consigliate richiedono:

1. Un repository Git per il modello, ad esempio un fork del modello. I modelli convalidati utilizzano GitOps, quindi è necessario controllare il repository in uso.
2. Un laptop per sviluppatori in cui siano installati oc, Git e Podman.
3. Un cluster OpenShift vuoto nel quale l'operatore dei modelli "gestisce" il cluster.

Ecco come interagiscono questi requisiti:

Con questa configurazione, il modello convalidato è proprietario di quanto si trova nel cluster, in modo da avere un unico punto di partenza.

Utilizzo di modelli convalidati per i container riservati

I container sandbox di Red Hat OpenShift si basano sui container Kata e offrono funzionalità aggiuntive per l'esecuzione dei container riservati. I container riservati sono container distribuiti all'interno di un'enclave hardware isolata che aiuta a proteggere i dati e il codice dagli utenti con privilegi, come gli amministratori del cloud o del cluster. Il progetto CNCF Confidential Containers è alla base della soluzione OpenShift CoCo.

Il computing riservato aiuta a proteggere i dati in uso sfruttando soluzioni hardware dedicate. Utilizzando l'hardware, puoi creare ambienti isolati proprietari e proteggerli dall'accesso non autorizzato o dalle modifiche ai dati del carico di lavoro durante l'esecuzione (dati in uso).

CoCo abilita il computing cloud native riservato, utilizzando varie piattaforme hardware e tecnologie di supporto. Punta inoltre a standardizzare il computing riservato a livello di pod e a semplificarne l'utilizzo negli ambienti Kubernetes. In questo modo, gli utenti di Kubernetes possono distribuire i carichi di lavoro CoCo utilizzando flussi di lavoro e strumenti familiari, senza dover conoscere a fondo le tecnologie di computing riservato alla base.

Per ulteriori informazioni, leggi l’Introduzione alla soluzione OpenShift per i container riservati. 

Architettura dei container riservati 

La soluzione Red Hat per i container riservati si basa su due operatori chiave:

• Container riservati di Red Hat OpenShift: una funzionalità aggiuntaall'operatore dei container sandbox di Red Hat OpenShift che si occupa del deployment degli elementi costitutivi per la connessione dei carichi di lavoro (pod) e delle macchine virtuali riservate (CVM) eseguite all'interno dell'ambiente TEE fornito dall'hardware.
• Attestazione remota: la versione Red Hat di Trustee si occupa del deployment e della gestione di Key Broker Service (KBS) in un cluster Red Hat OpenShift.

Per ulteriori informazioni, leggi l’Introduzione ai Confidential Container di Trustee: panoramica e scenari di utilizzo dei servizi di attestazione.

In genere, CoCo presenta due ambienti: una zona attendibile e una zona non attendibile, nelle quali sono distribuiti rispettivamente Trustee e l'operatore sandbox container: 

Qual è la sfida? Per capire come utilizzare questi modelli è necessario comprendere i dettagli specifici dell'infrastruttura cloud o on premise. È importante acquisire alcune informazioni, ad esempio l'area geografica in cui si opera, il chipset (Intel, AMD, IBM Power, s390) e l'hypervisor che si intendono utilizzare. 

Per ulteriori informazioni sul deployment di CoCo, leggi le Considerazioni sul deployment per la soluzione Red Hat OpenShift per container riservati.

Presentazione del modello convalidato per i container riservati

L'obiettivo del modello convalidato per i container riservati è semplificare l'avvio e la comprensione delle modalità di deployment dei container riservati. Il modello si avvale dell'architettura dei modelli convalidati per:

1. distribuire gli operatori necessari per l'esecuzione dei CoCo;
2. configurare i componenti periferici in background, inclusi i certificati (utilizzando Let's Encrypt, se necessario);
3. astrarre l'utente che esegue il deployment dei CoCo nel cluster dal cloud utilizzando strumenti come Red Hat Advanced Cluster Manager;
4. eseguire il deployment di un set di applicazioni di esempio per illustrare le varie funzionalità dei container riservati, inclusa la loro gestione.

Attualmente il modello viene distribuito su Microsoft Azure in un singolo cluster con tutti i componenti derivanti da un unico modello convalidato (altri deployment verranno aggiunti in futuro).

Come funziona?

Usiamo l'operatore dei modelli convalidati per distribuire Argo CD, che a sua volta distribuisce gli operatori aggiuntivi necessari. 

È necessario che la mappa di configurazione dei peer-pod, inclusi init-data e kata-policy, sia configurata in modo che indirizzi al Key Broker Service (KBS) di Trustee. Queste informazioni sono dinamiche e richiedono all'utente di utilizzare l'interfaccia a riga di comando di Azure o di accedere al portale di Azure. Dal punto di vista della sicurezza e della visibilità, anche init-data e kata-policy sono problematici, perché vengono serializzati in base64 prima di essere inviati a una mappa di configurazione, il che rende difficile per l'utente verificarne il comportamento.

 

Questi problemi vengono risolti utilizzando i metadati inseriti dall'operatore dei modelli convalidati, che ci consente di accedere facilmente alle informazioni sul cluster nella nostra applicazione. I criteri di gestione del cluster avanzati vengono utilizzati per raccogliere le informazioni definite dal gestore del controller cloud e per inserirle nelle mappe di configurazione e nei segreti appropriati per l'operatore del container sandbox.

Hashicorp Vault viene utilizzato come KMS all'interno del cluster con la configurazione dei segreti dei modelli convalidati, consentendo agli utenti di eseguire il bootstrap di Vault in modo coerente dall'ambiente di una workstation per lo sviluppo. Lo utilizziamo per fornire i segreti per Trustee, che vengono sincronizzati tramite l'operatore esterno dei segreti.

La combinazione di queste funzionalità consente l'installazione con un singolo comando ed è illustrata di seguito: 

Requisiti 

Al momento, la piattaforma è limitata ad Azure, con la topologia di modello simple che consiste in un singolo cluster OpenShift.

Gli utenti possono portare un cluster Azure Red Hat OpenShift o un cluster OpenShift autogestito su Azure. Il modello include la documentazione su come utilizzareopenshift-install per creare un cluster. Il cluster e l'account Azure devono avere l'accesso alle CVM di Azure disponibili nella regione. Oggi il modello presuppone macchine virtuali di classe DCasv5 per i container riservati, che tuttavia possono essere personalizzate.

L'unica configurazione aggiuntiva necessaria per Azure è il deployment di un gateway NAT per la subnet del nodo di lavoro. Tale deployment avviene in modo automatico.

Per la workstation dello sviluppatore è necessaria una workstation POSIX (Mac OS o Linux) nella quale siano installati oc e podman.

Istruzioni dettagliate

I passaggi da completare sono solo tre.

1. Crea un fork

Innanzitutto, crea un fork del repository GitHub dei modelli convalidati all'interno della tua organizzazione. Tieni presente che, a causa della coerenza futura di Argo CD, non è consigliabile utilizzare direttamente il repository dei modelli convalidati.

git clone https://github.com/(YOUR ORG}/coco-pattern.git

2. Genera le chiavi casuali

A questo punto è necessario generare i segreti di base. Il modello include gli script per generare le chiavi casuali:

sh scripts/gen-secrets.sh

3. Procedi con l'installazione

Accedi al cluster utilizzando oc login e avvia l'installazione del modello:

./pattern.sh make install

Tutto qui! Attendi che il sistema sia online, quindi esplora le applicazioni distribuite.

Esplorazione delle applicazioni distribuite

Il modello distribuisce un'istanza di Argo CD denominata Simple ArgoCD nel menu 9 box, nella web console di OpenShift. Vengono distribuite diverse applicazioni. Le due applicazioni critiche da considerare sono hello-openshift e kbs-access.

L'applicazione hello-openshift distribuisce un'applicazione web tre volte: 

• come pod standard;
• come pod kata, in cui la configurazione dell'agente è stata deliberatamente sovrascritta per consentire a un utente di eseguirla nel pod;
• come applicazione "sicura" con hardening dei CoCo attivato.

L'applicazione kbs-access è una semplice dimostrazione di come recuperare un segreto da Trustee tramite un container init. L'accesso KBS consente di accedere al segreto tramite l'API web, in modo da poter osservare come le modifiche al segreto si propagano nel sistema. Il metodo init container è pratico al fine di recuperare i segreti e per migliorare la sicurezza delle applicazioni esistenti, perché non richiede la presenza di Trustee nella posizione di sviluppo del codice.

Considerazioni sulla sicurezza durante il deployment dei modelli CoCo 

I container riservati sono incentrati sulla sicurezza, quindi è importante valutare il profilo di sicurezza del modello convalidato dei container riservati. I fattori principali da considerare per questo modello sono due:

• Oggi il modello utilizza valori di riferimento semplici. Ti invitiamo ad approfondire il flusso di attestazione RATS e a elaborare policy adatte alle tue esigenze di sicurezza e al profilo di rischio del sistema.
• Separazione del deployment di Trustee. In relazione al primo punto, il servizio di attestazione di Trustee si basa sul principio dell'operatività in un'area di sicurezza diversa e attendibile. Idealmente, si tratta di un ambiente diverso, ad esempio on premise o di un altro provider cloud.

Il diagramma seguente mostra l'architettura per il deployment di Trustee in un ambiente distinto, utilizzando il modello convalidato dei container riservati:

Il ruolo dei modelli CoCo in futuro 

Il modello convalidato CoCo è sufficiente per iniziare. Il suo obiettivo è garantire il corretto funzionamento di un singolo cluster e ambiente, in modo da poter iniziare i test. Il nostro obiettivo è offrire ulteriori esempi pratici per consentirti di continuare a utilizzare i container riservati.

Intendiamo supportare i deployment hub and spoke su più cluster, facilitando il deployment di Trustee nell'hub con Red Hat Advanced Cluster Management e permettendo ai cluster spoke di trovarsi dove vengono eseguiti i carichi di lavoro riservati.

Intendiamo anche fornire esempi pratici sull'utilizzo di Trustee per la gestione dei segreti. Gli esempi riportati fin qui sono semplici. Con gli sviluppi futuri intendiamo consentire la crittografia dello storage gestito all'interno di un TEE e l'inizializzazione dei segreti per le applicazioni non compatibili con Trustee e la configurazione di VPN.

Inoltre, puntiamo a supportare altri ambienti per il deployment di CoCo e Trustee, in modo da poter considerare attendibili le risorse on premise o più provider di servizi cloud.

Riepilogo 

Il modello convalidato dei container riservati fornisce un meccanismo semplice per iniziare a utilizzare i CoCo. È ottimo per avviare la sperimentazione e distribuire le applicazioni autonome in un unico repository, sfruttando l'approccio GitOps standardizzato di tipo app of apps con Argo CD. Come hai visto, iniziare è semplice come utilizzare i comandi clone git e make install.