Cosa sono i contenitori riservati?

Un container riservato fornisce un ambiente di runtime sicuro per i carichi di lavoro sensibili, ma consente di continuare a lavorare all'interno dei flussi di lavoro esistenti.

L'implementazione di IBM Cloud dei container confidenziali sfrutta i pod peer per estendere le funzionalità dei pod Red Hat OpenShift in un VSI separato dal nodo worker. Questa estensione crea un ambiente di esecuzione affidabile che va oltre i tradizionali Kubernetes e OpenShift.

Scopri di più qui:

• Esaminate i motivi per cui potreste utilizzare contenitori riservati.
• Consultate il sito Domande frequenti per i contenitori riservati.

Prerequisiti

• Quando si crea o si sceglie il cluster Red Hat OpenShift on IBM Cloud da utilizzare, il cluster deve soddisfare i seguenti requisiti:

  • Il cluster deve trovarsi in una regione che supporta le istanze server virtuali(VSI)TDX.
  • Il cluster deve avere un'interfaccia pubblica oppure ci si può collegare al suo ambiente tramite una VPN.
  • Per consentire al cluster di comunicare con qualsiasi VSI creato con contenitori riservati, è necessario creare un gruppo di sicurezza denominato kube-CLUSTER_ID per il cluster.

• Se necessario, abilitare OperatorHub. A volte OperatorHub viene disabilitato in un cluster per motivi di sicurezza.

Fase 1: Installazione dell'operatore

Installare OpenShift Sandboxed Containers Operator per gestire il ciclo di vita dei container riservati nei cluster.

1. Aprire la dashboard del cluster.

2. Fare clic su OpenShift console web > Operatori > OperatorHub.

3. Cercare OpenShift sandboxed containers Operator e fare clic sulla piastrella.

4. Fare clic su Installa per ottenere la versione supportata e stabile di OpenShift Sandboxed Containers Operator, versione 1.10.3. Per conoscere le versioni supportate di OpenShift, consultare il sito Red Hat 's Operator Update Information Checker.

5. Nella finestra Installator, è possibile mantenere le selezioni predefinite e fare clic su Install.

6. Attendere il completamento dell'installazione. Fare clic sul collegamento View installed Operators in Namespace openshift-sandboxed-containers-operator e attendere che lo stato sia Succeeded. Nell'attesa, è possibile completare il passo successivo per configurare la CLI.

Passo 2: Impostazione della CLI

Prima di iniziare, è possibile completare questi passaggi per configurare la CLI oppure utilizzare la shell IBM Cloud per eseguire i comandi.

1. Installare la linea di comando IBM Cloud.

2. Installare gli strumenti ks e oc CLI.

3. Accedi alla CLI di IBM Cloud.

   ibmcloud login --apikey API_KEY -g RESOURCE_GROUP
   

4. Elencare i cluster dell'account e copiare l'ID del cluster che si desidera utilizzare per il passaggio successivo.

   ibmcloud ks cluster ls
   

5. Esegui il comando config .

   ibmcloud ks cluster config --cluster CLUSTER_ID --admin --endpoint link
   

   Nella propria home directory, viene creata una cartella .kube e vengono memorizzate le informazioni per comunicare con il cluster.

6. Verificare che i comandi di oc vengano eseguiti correttamente visualizzando i dettagli dei nodi worker nel cluster.

   oc get nodes
   

7. Impostare lo spazio dei nomi del progetto in modo da non doverlo includere nei comandi successivi.

   oc project openshift-sandboxed-containers-operator
   

8. Facoltativo: Esplorare lo spazio dei nomi.

   oc get all
   

   Ad esempio, nell'elenco dei pod, il controller manager denominato pod/controller-manager-<id> gestisce i microservizi all'interno del gestore.

9. Installare lo strumento is CLI.

Passo 3: Importazione dell'immagine del peer pod

L'operatore OpenShift Sandboxed Containers lancia un sistema operativo speciale all'interno del pod peer, che deve essere importato nel proprio account IBM Cloud. Questo sistema operativo è necessario per distribuire un carico di lavoro in un contenitore riservato.

L'immagine peer pod contiene un sistema operativo completo Red Hat Enterprise Linux (RHEL) 9.6 con il software necessario per istanziare un container in una macchina virtuale confidenziale (CVM).

Tutte le configurazioni e i pacchetti installati nel sistema operativo mantengono i valori predefiniti Red Hat. Tuttavia, i VSI dell' IBM Cloud richiedono cloud init per funzionare. Negli script, cloud init non può essere disinstallato quando ha finito di costruire podvm, il che rappresenta una differenza fondamentale rispetto all'immagine di partenza.

Prima di cominciare:

Convalidare la compatibilità della versione. L'immagine è supportata dalle seguenti versioni.

• OpenShift Contenitori in sandbox Versione dell'operatore 1.10.3
• OpenShift versioni 4.19, 4.18, 4.17, e 4.16 cluster

Per importare l'immagine del peer pod:

1. Esegui il image-create comando.

   # Note IMAGE_NAME is a placeholder variable. Image names do not support capitalization.
   ibmcloud is image-create "IMAGE_NAME" --file cos://us-south/podvm-image/rhel9-podvm-latest.qcow2  --os-name red-9-amd64
   

2. Apri le immagini di calcolo.

3. Fare clic sull'icona Crea +, scegliere una regione con VSI compatibili con TDX e compilare i campi obbligatori.

   a. Per Sorgente immagine, selezionare Cloud Object Storage.

   b. Selezionate la scheda Individuazione per file immagine URL e per l'immagine URL, inserite cos://us-south/podvm-image/rhel9-podvm-latest.qcow2.

   c. Per il sistema operativo, selezionare Red Hat Enterprise Linux > red-9-amd64.

   d. Facoltativo: Per creare in seguito un altro contenitore riservato dall'API con gli stessi dettagli, fare clic sul pulsante Ottieni una chiamata API di esempio e copiare il comando Curl.

   e. Fai clic su " Crea immagine personalizzata ".

4. Quando l'immagine viene aggiunta all'elenco Immagini, fare clic sul nome dell'immagine e selezionare la scheda ID. Quindi, prendi nota dell 'ID immagine da utilizzare in seguito.

5. Attendere che lo stato dell'immagine sia Disponibile.

   ibmcloud is image IMAGE_NAME
   

6. Ripetere questi passaggi quando è disponibile una nuova versione dell'immagine.

Passo 4: creazione di una chiave API o di un profilo di fiducia

I container riservati richiedono una credenziale per istanziare il pod peer tramite kata-remote quando viene lanciato un carico di lavoro sicuro. Questa credenziale deve essere una chiave API valida o un profilo affidabile con le autorizzazioni per creare un VSI nel proprio account.

Se si stanno testando contenitori riservati, è possibile utilizzare una chiave API. Se si utilizza Secrets Manager, è necessario impostare un profilo di fiducia.

• Chiave API dall'interfaccia utente

  1. Dalla dashboard IBM Cloud, fare clic su Gestione > Accesso (IAM) > Chiavi API.

  2. Fai clic su Crea.

  3. Salvate questa chiave in modo sicuro, perché non potrà essere recuperata in seguito da questa pagina.

• Chiave API dalla CLI.

  Esegui il seguente comando e salva l'output.

  ibmcloud iam api-key-create KEY_NAME
  

• Profilo attendibile

  1. Apri la dashboard dei profili attendibili.

  2. Creare un profilo di fiducia e concedere al profilo le autorizzazioni necessarie per creare server virtuali da OpenShift.

     a. Creare un profilo di fiducia.

     ibmcloud iam trusted-profile-create <NAME> [--description <DESCRIPTION>]
     

     b. Consentire alle risorse di openshift-sandboxed-containers-operator di utilizzare il profilo di fiducia.

     ibmcloud iam trusted-profile-rule-create PROFILE_NAME_OR_ID --name RULE_NAME --type Profile-CR --conditions claim:namespace,operator:EQUALS,value:openshift-sandboxed-containers-operator --cr-type ROKS_SA
     

     c. Consentire l'accesso ai servizi di infrastruttura VPC (is).

     Per consentire l'accesso a tutte le risorse dell'account:

     ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile>  --roles Editor,Writer --service-name is
     

     Per consentire l'accesso a un gruppo di risorse specifico:

     ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile> --roles Viewer [--resource-group-id <resource group>]
     

Passo 5: creazione di una chiave SSH (facoltativo)

Nei cluster di prova, potrebbe essere utile avere a disposizione una chiave SSH per risolvere i problemi che non si avviano e per visualizzare i log. Nei cluster di produzione, potrebbe non essere necessario abilitare la funzionalità SSH.

1. Fare clic su Infrastruttura > Calcolo > Chiavi SSH.

2. Crea una chiave SSH e prendi nota dell'ID della chiave SSH.

Passo 6: Configurazione dei contenitori riservati

Dopo l'installazione dell'Operatore, creare ConfigMaps per permettere a Kata di gestire i carichi di lavoro nell'account IBM Cloud.

1. Creare una directory per memorizzare i file.

   mkdir <directory-name>
   

2. Passare alla directory.

   cd <directory-name>
   

3. Copiare le seguenti variabili d'ambiente per la chiave API, l'ID del profilo attendibile, il nome del cluster, l'ID dell'immagine PodVM, l'ID della chiave SSH e l'ID del VPC (opzionale).

   Facoltativo: è possibile memorizzarli in uno script di Shell nella nuova directory per impostarli nuovamente in seguito. Esempio: <directory-name>/env-vars.sh

   a. Raccogliere i valori delle seguenti variabili e aggiornarli nello script.

   • Per CLUSTER_NAME, aprire i dettagli del cluster nell'elenco dei cluster e copiare il nome.
   • Facoltativo: Per VPC_ID, nella sezione Dettagli cluster della stessa pagina, è possibile fare clic sul nome del vpc per aprire i dettagli del VPC e copiare il campo ID VPC.
   • Per PODVM_IMAGE_ID, utilizzare l'ID immagine salvato per l'immagine del peer pod.
   • Se si utilizza una chiave API, è possibile rimuovere la riga IBMCLOUD_TRUSTED_PROFILE_ID.
   • Se si utilizza un profilo di fiducia, è possibile rimuovere la riga IBMCLOUD_API_KEY.
   • Se non è stata impostata una chiave SSH, è possibile rimuovere la riga SSH_KEY_ID.

   export IBMCLOUD_API_KEY=<your API key>
   export IBMCLOUD_TRUSTED_PROFILE_ID="<your Trusted Profile ID>"
   export CLUSTER_NAME=<cluster-name-region-flavor>
   export PODVM_IMAGE_ID=<PodVM image ID provided by IBM or a custom-built image>
   export SSH_KEY_ID=<SSH key ID to be used by the peer pod VSI>
   export VPC_ID=<Optional: the VPC that your Openshift cluster is in>
   

   b. Se le variabili sono state memorizzate in uno script di Shell, eseguirlo. Esempio:

   sh env-vars.sh
   

4. Eseguire il comando per creare il sito feature-gates.yaml ConfigMap.

   cat > feature-gates.yaml <<EOF
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: osc-feature-gates
     namespace: openshift-sandboxed-containers-operator
   data:
     deploymentMode: "DaemonSetFallback" # or DaemonSet to force it
     confidential: "true"
     layeredImageDeployment: "false"
   EOF
   

5. Applicare il sito ConfigMap.

   oc apply -f feature-gates.yaml
   

6. Esegui il comando per creare il file peer-pods-secret.yaml``. Rimuovere dalla sezione stringData tutte le variabili d'ambiente opzionali di cui si ha bisogno.

   cat > peer-pods-secret.yaml <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: peer-pods-secret
     namespace: openshift-sandboxed-containers-operator
   type: Opaque
   stringData:
     # either IBMCLOUD_API_KEY or IBMCLOUD_IAM_PROFILE_ID must be set
     # if you specify both the IBMCLOUD_API_KEY will be used
     # IBMCLOUD_IAM_ENDPOINT is optional
     IBMCLOUD_API_KEY: "$IBMCLOUD_API_KEY"
     IBMCLOUD_IAM_ENDPOINT: "https://iam.cloud.ibm.com/identity/token"
     IBMCLOUD_IAM_PROFILE_ID: "$IBMCLOUD_TRUSTED_PROFILE_ID"
   EOF
   

7. Applica il segreto al cluster.

   oc apply -f peer-pods-secret.yaml
   

8. Eseguire il comando per creare il sito peer-pods-cm.yaml ConfigMap. Rimuovere le variabili d'ambiente opzionali dalla sezione data che non sono state impostate.

   cat > peer-pods-cm.yaml <<EOF
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: peer-pods-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     CLOUD_PROVIDER: "ibmcloud"
     IBMCLOUD_PODVM_IMAGE_ID: "$PODVM_IMAGE_ID"
     IBMCLOUD_PODVM_INSTANCE_PROFILE_LIST: "bx3dc-2x10"
     IBMCLOUD_PODVM_INSTANCE_PROFILE_NAME: "bx3dc-2x10"
     IBMCLOUD_RESOURCE_GROUP_ID: "$(ibmcloud is vpc "$VPC_ID" -json | jq -r .resource_group.id)"
     IBMCLOUD_SSH_KEY_ID: "$SSH_KEY_ID"
     IBMCLOUD_VPC_ID: "$VPC_ID"
     IBMCLOUD_VPC_SG_ID: "$(ibmcloud ks security-group ls --cluster $CLUSTER_NAME -json | jq -r '.[] | select(.type == "cluster") | .id')"
     CLOUD_CONFIG_VERIFY: "false"
     CRI_RUNTIME_ENDPOINT: "/run/cri-runtime/containerd.sock"
     ENABLE_CLOUD_PROVIDER_EXTERNAL_PLUGIN: "false"
     VXLAN_PORT: ""
     TUNNEL_TYPE: ""
     INITDATA: ""
     PEERPODS_LIMIT_PER_NODE: "10"
   EOF
   

   L'impostazione PEERPODS_LIMIT_PER_NODE controlla il numero massimo di pod VSI peer che possono essere pianificati per ogni nodo worker. Il valore predefinito è 10. È possibile aumentare questo valore in base alla capacità del nodo worker, ma si tenga presente che si è vincolati anche dai limiti dei pod di Kubernetes (110 pod per nodo per un worker 16x64 ) e dalle risorse CPU disponibili sul nodo worker. Ogni pod peer consuma circa 250m CPU e 120Mi memoria sul nodo worker per il costrutto del pod Kubernetes, anche se il carico di lavoro effettivo viene eseguito in un VSI separato. Per ulteriori informazioni, vedi la FAQ.

9. Applicare il sito ConfigMap.

   oc apply -f peer-pods-cm.yaml
   

10. Eseguire il comando per creare il sito kata-runtime-settings.yaml KataConfig.

    cat > kata-runtime-settings.yaml <<EOF
    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: kata-runtime-settings
      namespace: openshift-sandboxed-containers-operator
    spec:
      enablePeerPods: true
      logLevel: info
     #checkNodeEligibility: true
     #kataConfigPoolSelector:
     #  matchLabels:
     #    <label_key>: '<label_value>'
    EOF
    

11. Applicare il sito KataConfig.

    oc apply -f kata-runtime-settings.yaml
    

12. Durante l'installazione di Kata e l'avvio dei demoni, è possibile monitorare i progressi.

    • Si può guardare nel progetto OperatorHub openshift-sandboxed-containers-operator per vedere che KataConfig è in corso.
    • È possibile eseguire il seguente comando per vedere le etichette aggiornate con lo stato attuale dell'installazione.

        oc get nodes --output yaml|egrep "kata-ds-rpm-install|ibm-cloud.kubernetes.io/worker-id"
        ```
        Stati possibili:
    
        - `waiting_to_install`: L'installazione di Kata è in coda al nodo.
        - `installing`: L'installazione di Kata è in corso.
        - `installed`: Kata è stato installato correttamente sul nodo.
        - `waiting_for_reboot`: Il nodo deve essere riavviato per completare l'installazione o la disinstallazione.
        - `waiting_to_uninstall`: La disinstallazione di Kata è in coda al nodo.
        - `uninstalling`: La disinstallazione di Kata è in corso.
        - `uninstalled`: Kata è stato disinstallato con successo dal nodo.
    
    

13. Quando le etichette sono aggiornate e nello stato waiting_for_reboot, riavviare ogni nodo worker uno alla volta.

Quando si esegue oc get nodes e ogni nodo worker si trova nello stato installed, l'installazione è completa.

Passo 7: Configurazione di un'autorità fiduciaria

L'attestazione è una parte fondamentale dei contenitori riservati. È necessario convalidare la sicurezza del codice della catena di fornitura e verificare che il codice in esecuzione nel contenitore non sia stato modificato. È possibile sfruttare un chip Intel TDX e il protocollo key-broker-service. L'immagine di podvm contiene già il codice del driver TDX e un kbs_client funzionanti. Tuttavia, è necessario configurare INITDATA con i dettagli del fiduciario.

1. Selezionare un fiduciario. Ci sono molte opzioni per i fiduciari in contenitori riservati.

   • A scopo di sviluppo, si potrebbe lanciare un sito VM per un amministratore fiduciario.

   • Per un servizio di livello di produzione, si potrebbe utilizzare Intel Trust Authority.

2. Se si è scelto VM per un fiduciario a scopo di sviluppo, completare questi passaggi di configurazione.

   a. Inserire l'indirizzo IP del fiduciario nel seguente script ed eseguirlo per impostare la variabile INITDATA.

   export KBS_SERVICE_ENDPOINT="https://REPLACE_WITH_TRUSTEE_IP:8080"
   export INITDATA=$(cat <<EOF | gzip | base64 -w0
   algorithm = "sha256"
   version = "0.1.0"
   [data]
   "aa.toml" = '''
   [token_configs]
   [token_configs.coco_as]
   url = "$KBS_SERVICE_ENDPOINT"
   [token_configs.kbs]
   url = "$KBS_SERVICE_ENDPOINT"
   '''
   "cdh.toml"  = '''
   socket = 'unix:///run/confidential-containers/cdh.sock'
   credentials = []
   [kbc]
   name = "cc_kbc"
   url = "$KBS_SERVICE_ENDPOINT"
   '''
   EOF
   )
   

   b. Verificare la variabile d'ambiente $INITDATA.

   echo $INITDATA
   

   c. Aggiungete il valore della variabile allo spazio dei nomi peer-pods-cm.yaml ConfigMap nello spazio dei nomi openshift-sandboxed-containers-operator.

   d. Riavviare il set di demoni osc-caa-ds nello spazio dei nomi openshift-sandboxed-containers-operator. Questo daemonset Cloud API Adapter viene utilizzato per comunicare con IBM Cloud.

   oc rollout restart daemonset.apps/osc-caa-ds
   

   e. Esegui il seguente comando per visualizzare i pod. Per ogni pod osc-caa-ds-<id>, esaminare l'età di ciascun pod per verificare che sia stato riavviato.

   oc get pods
   

   Se un pod non si è riavviato, eliminarlo per ricrearlo.

   oc delete pod/osc-caa-ds-<id>
   

   Visualizzare nuovamente i baccelli.

   oc get pods
   

   f. Ripetere questi passaggi per ogni voce di carico di lavoro di INITDATA.

   es. Il valore INITDATA può essere applicato a un singolo contenitore come annotazione e il contenitore che si avvia è configurato per utilizzare il fiduciario. Questa annotazione può essere utile per testare nuovi fiduciari o per assicurarsi che le modifiche apportate a INITDATA non interrompano i contenitori riservati.

   Esempio di annotazione:

   apiVersion: v1
   kind: Pod
     metadata:
       name: mypod
       annotations:
         io.katacontainers.config.runtime.cc_init_data: $INITDATA
   spec:
     runtimeClassName: kata-remote
   

Passo 8: Esecuzione di un carico di lavoro confidenziale del contenitore

Dopo che tutte le etichette sono state aggiornate a installed, distribuire un carico di lavoro utilizzando il nome della classe di runtime kata-remote in un file pod.yaml. È possibile utilizzare l'esempio Hello World come carico di lavoro di prova in un contenitore riservato.

1. Crea un file denominato “ pod.yaml ”.

   oc apply -f - <<EOF
   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       app: helloworld
       version: v1
     name: helloworld
   spec:
     containers:
     - name: helloworld
       image: docker.io/istio/examples-helloworld-v1:1.0
       ports:
       - containerPort: 5000
     runtimeClassName: kata-remote
   EOF
   

2. Monitorare l'installazione nell'elenco Virtual Servers. Quando viene creato il VSI, viene visualizzato lo stato Running. Se il VSI sembra bloccato nello stato di Avvio, controllare i registri per individuare eventuali problemi.

   a. Ottenere i nomi dei baccelli.

   oc get pods
   

   b. Ottenere i log di uno dei pod Cloud API Adapter e cercare gli errori.

   oc logs osc-caa-ds-<id>
   

3. Verificate il pod eseguendo il seguente comando.

   oc describe pod/helloworld
   

4. Per verificare l'attestazione, eseguire il comando seguente nel contenitore.

   oc exec -it helloworld -- bash
   

   Quindi, eseguire il seguente comando curl per ottenere informazioni dal fiduciario.

   curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1
   

   Una volta terminato, si può uscire dal contenitore.

   exit
   

5. In caso di problemi, esaminare i registri nello spazio dei nomi openshift-sandboxed-containers-operator.

   • Registri dei pod gestiti dal controller:

       oc logs pod/controller-manager-<UNIQUE_ID>
       ```
   - Registri del pod Cloud API Adapter:
   
   ```sh {: pre}
       oc logs pod/osc-caa-ds-<UNIQUE_ID>
       ```
   - Registri delle applicazioni: Dipende dalla posizione specificata.
   
   

La configurazione dei contenitori riservati è ora completa! Si necessita ancora di aiuto? Controllare la risoluzione dei problemi.

Rimozione di carichi di lavoro e strumenti

Se si completano questi passaggi nell'ordine sbagliato, si rischia di lasciare indietro delle risorse che vengono addebitate, come ad esempio una VSI.