Condividi tramite

Distribuire un cluster del servizio Azure Kubernetes con contenitori riservati e criteri predefiniti

  • Articolo

In questo articolo si usa l'interfaccia della riga di comando di Azure per distribuire un cluster del servizio Azure Kubernetes e configurare contenitori riservati (anteprima) con criteri di sicurezza predefiniti. Si distribuisce quindi un'applicazione come contenitore Riservato. Per altre informazioni, vedere la panoramica dei contenitori riservati del servizio Azure Kubernetes.

In generale, per iniziare a usare i contenitori riservati del servizio Azure Kubernetes sono necessari i passaggi seguenti.

  • Distribuire o aggiornare un cluster del servizio Azure Kubernetes usando l'interfaccia della riga di comando di Azure
  • Aggiungere un'annotazione al manifesto del pod YAML per contrassegnare il pod come eseguito come contenitore riservato
  • Aggiungere un criterio di sicurezza almanifesto del pod YAML
  • Abilitare l'applicazione dei criteri di sicurezza
  • Distribuire l'applicazione in confidential computing

Prerequisiti

  • Interfaccia della riga di comando di Azure versione 2.44.1 o successiva. Eseguire az --version per trovare la versione ed eseguire az upgrade per aggiornare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

  • Estensione dell'aks-previewinterfaccia della riga di comando di Azure versione 0.5.169 o successiva.

  • Estensione dell'confcom interfaccia della riga di comando di Azure Confidential Container 0.3.3 o versione successiva. confcom è necessario per generare criteri di sicurezza.

  • Registrare la funzionalità Preview nella sottoscrizione di Azure.

  • Il servizio Azure Kubernetes supporta i contenitori riservati (anteprima) nella versione 1.25.0 e successive.

  • Identità del carico di lavoro e credenziali di identità federate. Le credenziali dell'identità del carico di lavoro consentono alle applicazioni Kubernetes di accedere in modo sicuro alle risorse di Azure con un ID Microsoft Entra basato su account del servizio con annotazioni. Se non si ha familiarità con l'ID del carico di lavoro Microsoft Entra, vedere Panoramica dell'ID del carico di lavoro di Microsoft Entra e vedere il Funzionamento dell'identità del carico di lavoro con il servizio Azure Kubernetes.

  • L'identità usata per creare il cluster dispone delle autorizzazioni minime adeguate. Per altre informazioni sull'accesso e l'identità per il servizio Azure Kubernetes, vedere Opzioni di accesso e identità per il servizio Azure Kubernetes (AKS).

  • Per gestire un cluster Kubernetes, usare il client da riga di comando Kubernetes kubectl. Azure Cloud Shell include kubectl. È possibile installarlo in locale usando il comando az aks install-cli.

  • I contenitori riservati nel servizio Azure Kubernetes forniscono un contenitore open source sidecar per l'attestazione e la versione sicura della chiave. Il sidecar si integra con un servizio di gestione delle chiavi, ad esempio Azure Key Vault, per rilasciare una chiave al gruppo di contenitori dopo il completamento della convalida. La distribuzione di un modulo di protezione hardware (HSM) gestito di Azure Key Vault è facoltativa, ma consigliata per supportare l'integrità e l'attestazione a livello di contenitore. Vedere Effettuare il provisioning e attivare un modulo di protezione hardware gestito per distribuire un modulo di protezione hardware gestito.

Installare l'estensione aks-preview per l'interfaccia della riga di comando di Azure

Importante

Le funzionalità di anteprima del servizio Azure Kubernetes sono disponibili in modalità self-service e opzionale. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

Per installare l'estensione aks-preview, eseguire il comando seguente:

az extension add --name aks-preview

Per eseguire l'aggiornamento alla versione più recente dell'estensione rilasciata eseguire il comando seguente:

az extension update --name aks-preview

Installare l'estensione dell'interfaccia della riga di comando di Azure confcom

Per installare l'estensione confcom, eseguire il comando seguente:

az extension add --name confcom

Per eseguire l'aggiornamento alla versione più recente dell'estensione rilasciata eseguire il comando seguente:

az extension update --name confcom

Registrare il flag di funzionalità KataCcIsolationPreview

Registrare il flag di funzionalità KataCcIsolationPreview usando il comando az feature register, come illustrato nell'esempio seguente:

az feature register --namespace "Microsoft.ContainerService" --name "KataCcIsolationPreview"

Sono necessari alcuni minuti per visualizzare lo stato Registered. Verificare lo stato della registrazione usando il comando az feature show:

az feature show --namespace "Microsoft.ContainerService" --name "KataCcIsolationPreview"

Quando lo stato diventa Registrato, aggiornare la registrazione del provider di risorse Microsoft.ContainerService usando il comando az provider register:

az provider register --namespace "Microsoft.ContainerService"

Distribuire un nuovo cluster

  1. Creare un cluster del servizio Azure Kubernetes usando il comando az aks create e specificando i parametri seguenti:

    • --os-sku: AzureLinux. Solo lo SKU del sistema operativo Linux di Azure supporta questa funzionalità in questa versione di anteprima.
    • --node-vm-size: tutte le dimensioni delle macchine virtuali di Azure di seconda generazione e supportano la virtualizzazione annidata. Ad esempio, macchine virtuali Standard_DC8as_cc_v5.
    • --enable-workload-identity: consente di creare un ID carico di lavoro Di Microsoft Entra che consente ai pod di usare un'identità Kubernetes.
    • --enable-oidc-issuer: abilita l'autorità di certificazioneOpenID Connect (OIDC). Consente a un ID Microsoft Entra o a un'altra piattaforma di gestione dell'accesso e dell'identità del provider di servizi cloud la possibilità di individuare le chiavi di firma pubblica del server API.

    L'esempio seguente aggiorna il cluster denominato myAKSCluster e crea un singolo pool di nodi di sistema in myResourceGroup:

    az aks create --resource-group myResourceGroup --name myAKSCluster --kubernetes-version <1.25.0 and above> --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --node-count 1 --enable-oidc-issuer --enable-workload-identity --generate-ssh-keys

    Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster. Il cluster creato nel passaggio precedente ha un singolo pool di nodi. Nel passaggio successivo si aggiunge un secondo pool di nodi al cluster.

  2. Quando il cluster è pronto, ottenere le credenziali del cluster usando il comando az aks get-credentials.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

  3. Aggiungere un pool di nodi utente a myAKSClustercon due nodi in nodepool2 in myResourceGroup usando il comando az aks nodepool add. Specificare i seguenti parametri:

    • --workload-runtime: specificare KataCcIsolation per abilitare la funzionalità Contenitori riservati nel pool di nodi. Con questo parametro, questi altri parametri soddisfano i requisiti seguenti. In caso contrario, il comando non riesce e segnala un problema con i parametri corrispondenti.
    • --os-sku: AzureLinux. Solo lo SKU del sistema operativo Linux di Azure supporta questa funzionalità in questa versione di anteprima.
    • --node-vm-size: tutte le dimensioni delle macchine virtuali di Azure di seconda generazione e supportano la virtualizzazione annidata. Ad esempio, macchine virtuali Standard_DC8as_cc_v5.
    az aks nodepool add --resource-group myResourceGroup --name nodepool2 --cluster-name myAKSCluster --node-count 2 --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --workload-runtime KataCcIsolation

Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.

Eseguire la distribuzione in un cluster esistente

Per usare questa funzionalità con un cluster del servizio Azure Kubernetes esistente, è necessario soddisfare i requisiti seguenti:

Usare il comando seguente per abilitare i contenitori riservati (anteprima) creando un pool di nodi per ospitarlo.

  1. Aggiungere un pool di nodi al cluster del servizio Azure Kubernetes usando il comando az aks nodepool add. Specificare i seguenti parametri:

    • --resource-group: immettere il nome di un gruppo di risorse esistente in cui creare il cluster del servizio Azure Kubernetes.
    • --cluster-name: immettere un nome univoco per il cluster del servizio Azure Kubernetes, ad esempio myAKSCluster.
    • --name: immettere un nome univoco per il pool di nodi dei cluster, ad esempio nodepool2.
    • --workload-runtime: specificare KataCcIsolation per abilitare la funzionalità nel pool di nodi. Insieme al parametro --workload-runtime, questi altri parametri soddisfano i requisiti seguenti. In caso contrario, il comando non riesce e segnala un problema con i parametri corrispondenti.
    • --os-sku: AzureLinux. Solo lo SKU del sistema operativo Linux di Azure supporta questa funzionalità in questa versione di anteprima.
    • --node-vm-size: tutte le dimensioni delle macchine virtuali di Azure di seconda generazione e supportano la virtualizzazione annidata. Ad esempio, macchine virtuali Standard_DC8as_cc_v5.

    L'esempio seguente aggiunge un pool di nodi utente a myAKSCluster con due nodi in nodepool2 in myResourceGroup:

    az aks nodepool add --resource-group myResourceGroup --name nodepool2 –-cluster-name myAKSCluster --node-count 2 --os-sku AzureLinux --node-vm-size Standard_DC4as_cc_v5 --workload-runtime KataCcIsolation

    Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.

  2. Eseguire il comando az aks update per abilitare i contenitori riservati (anteprima) nel cluster.

    az aks update --name myAKSCluster --resource-group myResourceGroup

    Il comando viene completato dopo pochi minuti e vengono restituite informazioni in formato JSON sul cluster.

  3. Quando il cluster è pronto, ottenere le credenziali del cluster usando il comando az aks get-credentials.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Configurare il contenitore

Prima di configurare l'accesso all'insieme di credenziali delle chiavi di Azure e al segreto e distribuire un'applicazione come contenitore riservato, è necessario completare la configurazione dell'identità del carico di lavoro.

Per configurare l'identità del carico di lavoro, seguire questa procedura descritta nell'articolo Distribuire e configurare l'identità del carico di lavoro :

  • Recuperare l'URL dell'autorità di certificazione OIDC
  • Creare un'identità gestita
  • Creare un account del servizio Kubernetes
  • Stabilire credenziali di identità federate

Importante

È necessario impostare le variabili di ambiente dalla sezione Esportare le variabili di ambiente nell'articolo Distribuire e configurare l'identità del carico di lavoro per continuare a completare questa esercitazione. Ricordarsi di impostare la variabile SERVICE_ACCOUNT_NAMESPACE su kafka ed eseguire il comando kubectl create namespace kafka prima di configurare l'identità del carico di lavoro.

Distribuire un'applicazione attendibile con kata-cc e un contenitore di attestazione

La procedura seguente consente di configurare la crittografia end-to-end per i messaggi Kafka usando le chiavi di crittografia gestite dai moduli di sicurezza hardware gestiti di Azure (mHSM). La chiave viene rilasciata solo quando il consumer Kafka viene eseguito all'interno di un contenitore riservato con un contenitore di provisioning del segreto di attestazione di Azure inserito nel pod.

Questa configurazione si basa sui quattro componenti seguenti:

  • Cluster Kafka: un cluster Kafka semplice distribuito nello spazio dei nomi Kafka nel cluster.
  • Kafka Producer: producer Kafka in esecuzione come pod Kubernetes vanilla che invia messaggi crittografati configurati dall'utente usando una chiave pubblica a un argomento Kafka.
  • Kafka Consumer: un pod consumer Kafka in esecuzione con il runtime kata-cc, dotato di un contenitore di versione della chiave sicura per recuperare la chiave privata per decrittografare i messaggi Kafka ed eseguire il rendering dei messaggi nell'interfaccia utente Web.

Per questa versione di anteprima, a scopo di test e valutazione, si consiglia di creare o utilizzare una risorsa Azure Key Vault di livello Premium esistente per supportare l'archiviazione delle chiavi in un modulo di sicurezza hardware (HSM). Non è consigliabile usare l'insieme di credenziali delle chiavi di produzione. Se non si ha un'istanza di Azure Key Vault, vedere Creare un insieme di credenziali delle chiavi usando l'interfaccia della riga di comando di Azure.

  1. Concedere all'identità gestita creata in precedenza e all'account l'accesso all'insieme di credenziali delle chiavi. Assegnare ad entrambe le identità i ruoli di Key Vault Crypto Officer e Key Vault Crypto User di Azure RBAC.

    Nota

    • L'identità gestita è il valore assegnato alla variabile USER_ASSIGNED_IDENTITY_NAME.

    • Per aggiungere assegnazioni di ruoli, è necessario avere le autorizzazioni Microsoft.Authorization/roleAssignments/write e Microsoft.Authorization/roleAssignments/delete, ad esempio Amministratore dell'accesso ai dati di Key Vault, Amministratore dell'accesso utenti o Proprietario.

    • È necessario usare lo SKU Premium di Key Vault per supportare le chiavi protette dal modulo di protezione hardware.

    Eseguire il comando seguente per impostare l'ambito:

    AKV_SCOPE=$(az keyvault show --name <AZURE_AKV_RESOURCE_NAME> --query id --output tsv)

    Eseguire il comando seguente per assegnare il ruolo Crypto Officer di Key Vault.

    az role assignment create --role "Key Vault Crypto Officer" --assignee "${USER_ASSIGNED_IDENTITY_NAME}" --scope $AKV_SCOPE

    Eseguire il comando seguente per assegnare il ruolo Crypto User di Key Vault.

    az role assignment create --role "Key Vault Crypto User" --assignee "${USER_ASSIGNED_IDENTITY_NAME}" --scope $AKV_SCOPE

  2. Installare il cluster Kafka nello spazio dei nomi kafka eseguendo il comando seguente:

    kubectl create -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka

  3. Eseguire il comando seguente per applicare il file CR del cluster kafka.

    kubectl apply -f https://strimzi.io/examples/latest/kafka/kafka-persistent-single.yaml -n kafka

  4. Preparare la chiave di crittografia/decrittografia RSA usando lo script bash per il carico di lavoro da GitHub. Salvare il file come setup-key.sh.

  5. Impostare la variabile MAA_ENDPOINT di ambiente con il nome di dominio completo dell'URI di attestazione eseguendo il comando seguente.

    export MAA_ENDPOINT="$(az attestation show --name "myattestationprovider" --resource-group "MyResourceGroup" --query 'attestUri' -o tsv | cut -c 9-)"

    Controllare se il formato FQDN dell'URI di attestazione è corretto (il MAA_ENDPOINT non deve includere il prefisso "https://"):

    echo $MAA_ENDPOINT

    Nota

    Per configurare l'attestazione di Microsoft Azure, vedere Avvio rapido: Configurare Attestazione di Azure con l'interfaccia della riga di comando di Azure.

  6. Copiare il manifesto YAML seguente e salvarlo come consumer.yaml.

    apiVersion: v1
kind: Pod
metadata:
  name: kafka-golang-consumer
  namespace: kafka
  labels:
    azure.workload.identity/use: "true"
    app.kubernetes.io/name: kafka-golang-consumer
spec:
  serviceAccountName: workload-identity-sa
  runtimeClassName: kata-cc-isolation
  containers:
    - image: "mcr.microsoft.com/aci/skr:2.7"
      imagePullPolicy: Always
      name: skr
      env:
        - name: SkrSideCarArgs
          value: ewogICAgImNlcnRjYWNoZSI6IHsKCQkiZW5kcG9pbnRfdHlwZSI6ICJMb2NhbFRISU0iLAoJCSJlbmRwb2ludCI6ICIxNjkuMjU0LjE2OS4yNTQvbWV0YWRhdGEvVEhJTS9hbWQvY2VydGlmaWNhdGlvbiIKCX0gIAp9
      command:
        - /bin/skr
      volumeMounts:
        - mountPath: /opt/confidential-containers/share/kata-containers/reference-info-base64
          name: endor-loc
    - image: "mcr.microsoft.com/acc/samples/kafka/consumer:1.0"
      imagePullPolicy: Always
      name: kafka-golang-consumer
      env:
        - name: SkrClientKID
          value: kafka-encryption-demo
        - name: SkrClientMAAEndpoint
          value: sharedeus2.eus2.test.attest.azure.net
        - name: SkrClientAKVEndpoint
          value: "myKeyVault.vault.azure.net"
        - name: TOPIC
          value: kafka-demo-topic
      command:
        - /consume
      ports:
        - containerPort: 3333
          name: kafka-consumer
      resources:
        limits:
          memory: 1Gi
          cpu: 200m
  volumes:
    - name: endor-loc
      hostPath:
        path: /opt/confidential-containers/share/kata-containers/reference-info-base64
---
apiVersion: v1
kind: Service
metadata:
  name: consumer
  namespace: kafka
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: kafka-golang-consumer
  ports:
    - protocol: TCP
      port: 80
      targetPort: kafka-consumer

    Nota

    Aggiornare il valore per la variabile di ambiente SkrClientAKVEndpoint del pod in modo che corrisponda all'URL dell'insieme di credenziali delle chiavi di Azure, escluso il valore del protocollo https://. Il valore segnaposto del valore corrente è myKeyVault.vault.azure.net. Aggiornare il valore per la variabile SkrClientMAAEndpoint di ambiente pod con il valore di MAA_ENDPOINT. È possibile trovare il valore di MAA_ENDPOINT eseguendo il comando echo $MAA_ENDPOINT o il comando az attestation show --name "myattestationprovider" --resource-group "MyResourceGroup" --query 'attestUri' -o tsv | cut -c 9-.

  7. Generare i criteri di sicurezza per il manifesto YAML del consumer Kafka e ottenere l'hash dei criteri di sicurezza archiviati nella variabile WORKLOAD_MEASUREMENT eseguendo il comando seguente:

    export WORKLOAD_MEASUREMENT=$(az confcom katapolicygen -y consumer.yaml --print-policy | base64 -d | sha256sum | cut -d' ' -f1)

  8. Per generare una coppia di chiavi asimmetriche RSA (chiavi pubbliche e private), eseguire lo script setup-key.sh usando il comando seguente. Il valore <Azure Key Vault URL> deve essere <your-unique-keyvault-name>.vault.azure.net

    export MANAGED_IDENTITY=${USER_ASSIGNED_CLIENT_ID}
bash setup-key.sh "kafka-encryption-demo" <Azure Key Vault URL>

    Nota

    • La variabile MANAGED_IDENTITY di ambiente è richiesta dallo script bash setup-key.sh.

    • La chiave pubblica verrà salvata come kafka-encryption-demo-pub.pem dopo l'esecuzione dello script bash.

    Importante

    Se viene visualizzato l'errore ForbiddenByRbac, potrebbe essere necessario attendere fino a 24 ore perché i servizi back-end per le identità gestite mantengono una cache per ogni URI di risorsa per un massimo di 24 ore. Vedere anche: Risolvere i problemi relativi al controllo degli accessi in base al ruolo di Azure .

  9. Per verificare che le chiavi siano state caricate correttamente nell'insieme di credenziali delle chiavi, eseguire i comandi seguenti:

    az account set --subscription <Subscription ID>
az keyvault key list --vault-name <KeyVault Name> -o table

  10. Copiare il manifesto YAML seguente e salvarlo come producer.yaml.

    apiVersion: v1
kind: Pod
metadata:
  name: kafka-producer
  namespace: kafka
spec:
  containers:
    - image: "mcr.microsoft.com/acc/samples/kafka/producer:1.0"
      name: kafka-producer
      command:
        - /produce
      env:
        - name: TOPIC
          value: kafka-demo-topic
        - name: MSG
          value: "Azure Confidential Computing"
        - name: PUBKEY
          value: |-
            -----BEGIN PUBLIC KEY-----
            MIIBojAN***AE=
            -----END PUBLIC KEY-----
      resources:
        limits:
          memory: 1Gi
          cpu: 200m

    Nota

    Aggiornare il valore che inizia con -----BEGIN PUBLIC KEY----- e termina con -----END PUBLIC KEY----- stringhe con il contenuto da kafka-encryption-demo-pub.pem cui è stato creato nel passaggio precedente.

  11. Distribuire i manifesti YAML consumer e producer usando i file salvati in precedenza.

    kubectl apply -f consumer.yaml

    kubectl apply -f producer.yaml

  12. Ottenere l'indirizzo IP del servizio Web usando il comando seguente:

    kubectl get svc consumer -n kafka

  13. Copiare e incollare l'indirizzo IP esterno del servizio consumer nel browser e osservare il messaggio decrittografato.

    L'output del comando è simile all'esempio seguente:

    Welcome to Confidential Containers on AKS!
Encrypted Kafka Message:
Msg 1: Azure Confidential Computing

  14. È anche consigliabile provare a eseguire il consumer come un normale pod Kubernetes rimuovendo la specifica skr container e kata-cc runtime class. Poiché non si esegue il consumer con la classe di runtime kata-cc, non sono più necessari i criteri.

  15. Rimuovere l'intero criterio e osservare nuovamente i messaggi nel browser dopo la ridistribuzione del carico di lavoro. I messaggi vengono visualizzati come testo crittografato con codifica Base64 perché non è possibile recuperare la chiave di crittografia privata. La chiave non può essere recuperata perché il consumer non è più in esecuzione in un ambiente riservato e skr container non è presente, impedendo la decrittografia dei messaggi.

Pulizia

Al termine della valutazione di questa funzionalità, per evitare addebiti di Azure, pulire le risorse non necessarie. Se è stato distribuito un nuovo cluster come parte della valutazione o del test, è possibile eliminare il cluster usando il comando az aks delete.

az aks delete --resource-group myResourceGroup --name myAKSCluster

Se sono stati abilitati i contenitori riservati (anteprima) in un cluster esistente, è possibile rimuovere i pod usando il comando kubectl delete pod.

kubectl delete pod pod-name

Passaggi successivi

  • Altre informazioni sugli host dedicati di Azure per i nodi con il cluster del servizio Azure Kubernetes per usare l'isolamento hardware e il controllo sugli eventi di manutenzione della piattaforma Azure.