Verschlüsseln von Betriebssystemdatenträgern mit einem kundenseitig verwalteten Schlüssel in Azure Red Hat OpenShift

Artikel
10/26/2023

Standardmäßig wurden die Betriebssystemdatenträger der virtuellen Computer in einem Azure Red Hat OpenShift-Cluster mit automatisch generierten Schlüsseln verschlüsselt, die von Microsoft Azure verwaltet wurden. Aus Sicherheitsgründen können Kunden die Betriebssystemdatenträger bei der Bereitstellung eines Azure Red Hat OpenShift-Clusters mit selbstverwalteten Schlüsseln verschlüsseln. Diese Features ermöglichen mehr Kontrolle, indem vertrauliche Daten mit kundenseitig verwalteten Schlüsseln (CMK) verschlüsselt werden.

Für Cluster, die mit kundenseitig verwalteten Schlüsseln erstellt werden, ist eine Standardspeicherklasse mit ihren Schlüsseln aktiviert. Daher werden sowohl Betriebssystemdatenträger als auch Datenträger mit diesen Schlüsseln verschlüsselt. Die kundenseitig verwalteten Schlüssel werden in Azure Key Vault gespeichert.

Weitere Informationen zur Verwendung von Azure Key Vault zum Erstellen und Verwalten von Schlüsseln finden Sie unter Serverseitige Verschlüsselung von Azure Disk Storage in der Microsoft Azure-Dokumentation.

Mit hostbasierter Verschlüsselung werden die auf dem VM-Host der VMs Ihres Azure Red Hat OpenShift-Agent-Knotens gespeicherten Daten ruhend verschlüsselt und verschlüsselt an den Speicherdienst übermittelt. Hostbasisverschlüsselung bedeutet, dass temporäre Datenträger im Ruhezustand mit von der Plattform verwalteten Schlüsseln verschlüsselt werden.

Der Cache von Betriebssystem- und sonstigen Datenträgern wird im Ruhezustand entweder mit von der Plattform verwalteten Schlüsseln oder vom Kunden verwalteten Schlüsseln verschlüsselt, je nachdem, welcher Verschlüsselungstyp auf diesen Datenträgern festgelegt wurde. Standardmäßig werden bei der Verwendung von Azure Red Hat OpenShift Betriebssystem- und sonstige Datenträger im Ruhezustand mit von der Plattform verwalteten Schlüsseln verschlüsselt. Dies bedeutet, dass die Caches für diese Datenträger standardmäßig auch im Ruhezustand mit von der Plattform verwalteten Schlüsseln verschlüsselt werden.

Sie können Ihre eigenen verwalteten Schlüssel angeben, indem Sie die nachstehenden Verschlüsselungsschritte befolgen. Der Cache für diese Datenträger wird auch mit dem Schlüssel verschlüsselt, den Sie in diesem Schritt angeben.

Einschränkung

Es liegt in der Verantwortung von Kunden, die Key Vault-Instanz und den Datenträgerverschlüsselungssatz in Azure zu verwalten. Wenn die Schlüssel nicht verwaltet werden, führt dies zu fehlerhaften Azure Red Hat OpenShift-Clustern. Die VMs arbeiten nicht mehr, und infolgedessen funktioniert auch der gesamte Azure Red Hat OpenShift-Cluster nicht mehr.

Das Azure Red Hat OpenShift-Technikerteam besitzt keinen Zugriff auf die Schlüssel. Daher kann es die Schlüssel nicht sichern, replizieren oder abrufen.

Weitere Informationen zur Verwendung von Datenträgerverschlüsselungssätzen zum Verwalten Ihrer Verschlüsselungsschlüssel finden Sie unter Serverseitige Verschlüsselung von Azure Disk Storage in der Microsoft Azure-Dokumentation.

Voraussetzungen

Überprüfen von Berechtigungen. Sie benötigen die Berechtigungen „Mitwirkender“ und „Benutzerzugriffsadministrator“ oder „Besitzer“ für das Abonnement.
Registrieren Sie die Ressourcenanbieter, wenn Sie über mehrere Azure-Abonnements verfügen. Registrierungsdetails finden Sie unter Registrieren der Ressourcenanbieter.
Sie müssen das EncryptionAtHost-Feature in Ihrem Abonnement aktiviert haben. Sie können sie aktivieren, indem Sie Folgendes ausführen:
```
az feature register --namespace Microsoft.Compute --name EncryptionAtHost
```
Sie können den aktuellen Status des Features überprüfen, indem Sie Folgendes ausführen:
```
az feature show --namespace Microsoft.Compute --name EncryptionAtHost
```

Erstellen eines virtuellen Netzwerks mit zwei leeren Subnetzen

Erstellen Sie ein virtuelles Netzwerk mit zwei leeren Subnetzen. Wenn Sie über ein vorhandenes virtuelles Netzwerk verfügen, das Ihre Anforderungen erfüllt, können Sie diesen Schritt überspringen. Informationen zum Erstellen eines virtuellen Netzwerks finden Sie unter Erstellen eines virtuellen Netzwerks mit zwei leeren Subnetzen.

Erstellen einer Azure Key Vault-Instanz

Sie müssen eine Azure Key Vault-Instanz zum Speichern Ihrer Schlüssel verwenden. Erstellen Sie eine neue Key Vault-Instanz mit aktiviertem Löschschutz. Erstellen Sie dann einen neuen Schlüssel innerhalb der Key Vault-Instanz zum Speichern Ihres eigenen benutzerdefinierten Schlüssels.

Festlegen weiterer Umgebungsberechtigungen:

export KEYVAULT_NAME=$USER-enckv
export KEYVAULT_KEY_NAME=$USER-key
export DISK_ENCRYPTION_SET_NAME=$USER-des

Erstellen Sie einen Schlüsseltresor und einen Schlüssel im Key Vault:

az keyvault create -n $KEYVAULT_NAME \
               -g $RESOURCEGROUP \
               -l $LOCATION \
               --enable-purge-protection true

az keyvault key create --vault-name $KEYVAULT_NAME \
                       -n $KEYVAULT_KEY_NAME \
                       --protection software

KEYVAULT_ID=$(az keyvault show --name $KEYVAULT_NAME --query "[id]" -o tsv)

KEYVAULT_KEY_URL=$(az keyvault key show --vault-name $KEYVAULT_NAME \
                                        --name $KEYVAULT_KEY_NAME \
                                        --query "[key.kid]" -o tsv)

Erstellen eines Azure-Datenträgerverschlüsselungssatzes

Der Azure-Datenträgerverschlüsselungssatz wird als Bezugspunkt für Datenträger in Azure Red Hat OpenShift-Clustern verwendet. Er ist mit der im vorherigen Schritt erstellten Azure Key Vault-Instanz verbunden und pullt kundenseitig verwaltete Schlüssel von diesem Speicherort.

az disk-encryption-set create -n $DISK_ENCRYPTION_SET_NAME \
                              -l $LOCATION \
                              -g $RESOURCEGROUP \
                              --source-vault $KEYVAULT_ID \
                              --key-url $KEYVAULT_KEY_URL

DES_ID=$(az disk-encryption-set show -n $DISK_ENCRYPTION_SET_NAME -g $RESOURCEGROUP --query 'id' -o tsv)

DES_IDENTITY=$(az disk-encryption-set show -n $DISK_ENCRYPTION_SET_NAME \
                                           -g $RESOURCEGROUP \
                                           --query "[identity.principalId]" \
                                           -o tsv)

Erteilen von Berechtigungen für den Datenträgerverschlüsselungssatz für den Zugriff auf die Key Vault-Instanz

Verwenden Sie den Datenträgerverschlüsselungssatz, den Sie im vorherigen Schritt erstellt haben, und erteilen Sie dem Datenträgerverschlüsselungssatz die Berechtigung für den Zugriff auf und die Verwendung von Azure Key Vault.

az keyvault set-policy -n $KEYVAULT_NAME \
                       -g $RESOURCEGROUP \
                       --object-id $DES_IDENTITY \
                       --key-permissions wrapkey unwrapkey get

Erstellen eines Azure Red Hat OpenShift-Clusters

Erstellen Sie einen Azure Red Hat OpenShift-Cluster, um die kundenseitig verwalteten Schlüssel zu verwenden.

az aro create --resource-group $RESOURCEGROUP \
              --name $CLUSTER  \
              --vnet aro-vnet  \
              --master-subnet master-subnet \
              --worker-subnet worker-subnet \
              --disk-encryption-set $DES_ID

Nachdem Sie den Azure Red Hat OpenShift-Cluster erstellt haben, werden alle VMs mit den kundenseitig verwalteten Verschlüsselungsschlüsseln verschlüsselt.

Führen Sie die folgenden Befehle aus, um zu überprüfen, ob Sie die Schlüssel ordnungsgemäß konfiguriert haben:

Rufen Sie den Namen der Clusterressourcengruppe ab, in der sich die Cluster-VMs, Datenträger usw. befinden:

CLUSTERRESOURCEGROUP=$(az aro show --resource-group $RESOURCEGROUP --name $CLUSTER --query 'clusterProfile.resourceGroupId' -o tsv | cut -d '/' -f 5)

Überprüfen Sie, ob die Datenträger über den richtigen Datenträgerverschlüsselungssatz verfügen:
```
az disk list -g $CLUSTERRESOURCEGROUP --query '[].encryption'
```
Das Feld diskEncryptionSetId in der Ausgabe muss auf den Datenträgerverschlüsselungssatz verweisen, den Sie beim Erstellen des Azure Red Hat OpenShift-Clusters angegeben haben.

Share via