Настройка шифрования для Azure Elastic SAN

Все данные, записанные в томе Elastic SAN, зашифрованы на месте с помощью ключа шифрования данных (DEK). Azure использует конвертное шифрование для шифрования DEK с помощью ключа шифрования ключей (KEK). По умолчанию Azure использует управляемый платформой KEK. Вы можете использовать управляемый клиентом ключ (CMK), хранящийся в Azure Key Vault.

В этой статье показано, как настроить шифрование для группы томов Elastic SAN с помощью CMK в Azure Key Vault.

Предпосылки

• Если у вас нет подписки на Azure, создайте бесплатную учетную запись перед началом.

• Для этой статьи требуется Azure CLI версии 2.83.0 или более поздней. Дополнительные сведения см. в статье "Установка Azure CLI". Отключите такие расширения, как aks-preview если возникают проблемы. Установите или обновите расширения по мере необходимости:

  • az extension add --upgrade --name k8s-extension
  • az extension add --upgrade --name elastic-san (только Elastic SAN)

• Вам нужен клиент командной строки Kubernetes. kubectl Он уже установлен, если вы используете Azure Cloud Shell. Его можно установить локально, выполнив az aks install-cli команду.

• Проверьте, поддерживается ли целевой регион в регионах хранилища контейнеров Azure.

• В этой статье предполагается, что вы установили хранилище контейнеров Azure версии 2.1.0 или более поздней версии в кластере Службы Azure Kubernetes (AKS).

Настройка хранилища ключей

Для хранения ключей, управляемых клиентом, можно использовать новое или существующее хранилище ключей. Зашифрованный ресурс и хранилище ключей могут находиться в разных регионах или подписках в одном тенанте Microsoft Entra ID. Дополнительные сведения см. в статье "Обзор Azure Key Vault " и "Что такое Azure Key Vault?"

Шифрование с помощью ключей, управляемых клиентом, требует включения мягкого удаления и защиты от безвозвратного удаления для ключевого хранилища. Мягкое удаление включено по умолчанию при создании нового хранилища ключей и не может быть отключено. Вы можете включить защиту очистки при создании хранилища ключей или после его создания. Шифрование Azure Elastic SAN поддерживает ключи RSA размеров 2048, 3072 и 4096.

Azure Key Vault поддерживает авторизацию с помощью управления доступом на основе ролей Azure (Azure RBAC). Корпорация Майкрософт рекомендует использовать Azure RBAC вместо политик доступа к хранилищу ключей. Дополнительные сведения см. в статье "Предоставление доступа к ключам, сертификатам и секретам Key Vault с помощью управления доступом на основе ролей Azure".

Подготовьте хранилище ключей для KEKs группы дисков:

Чтобы создать новое хранилище ключей с помощью Azure CLI, вызовите команду az keyvault create. В следующем примере создается новое хранилище ключей с включенным мягким удалением и защитой от очистки. Модель разрешений хранилища ключей использует Azure RBAC. Замените значения заполнителей в квадратных скобках собственными значениями.

az keyvault create --name <key-vault-name> --resource-group <resource-group-name> --location <location> --enable-purge-protection --retention-days 7

Чтобы включить защиту очистки в существующем хранилище ключей, ознакомьтесь с обзором восстановления Azure Key Vault.

Создайте управляемую идентичность, назначаемую пользователем, и предоставьте доступ к хранилищу ключей.

Создайте управляемое удостоверение, назначаемое пользователем, в управляемой группе ресурсов кластера AKS:

az identity create --name <identity-name> --resource-group <node-resource-group>

Получите идентификаторы пользователей и сохраните их в переменных.

uai_id=$(az identity show --name <identity-name> --resource-group <node-resource-group> --query id -o tsv)
uai_principal_id=$(az identity show --ids "$uai_id" --query principalId -o tsv)

При включении ключей шифрования, управляемых клиентом для группы томов Elastic SAN, необходимо указать управляемое удостоверение, чтобы авторизовать доступ к хранилищу ключей, содержащего ключ.

Если хранилище ключей использует политики доступа, задайте разрешения ключа для управляемого удостоверения. Если в хранилище используется Azure RBAC, вместо этого назначьте эквивалентную роль.

az keyvault set-policy --name <key-vault-name> --resource-group <resource-group-name> --object-id $uai_principal_id --key-permissions get wrapKey unwrapKey

Добавление ключа

Перед добавлением ключа убедитесь, что у вас есть роль офицера шифрования Key Vault .

Получите URI хранилища и сохраните его в переменной.

vault_uri=$(az keyvault show --name <key-vault-name> --resource-group <resource-group-name> --query "properties.vaultUri" -o tsv)

Создайте ключ шифрования:

az keyvault key create --name <key-name> --vault-name <key-vault-name> --kty RSA --size 2048

Создание класса StorageClass

Создайте файл манифеста YAML, например storageclass.yaml. Используйте имена и переменные из предыдущих шагов.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azuresan-csi-encrypted
provisioner: san.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  encryption.keyvaulturi: "${vault_uri}"
  encryption.keyname: <key-name>
  encryption.identity: "${uai_id}"

Примените манифест для создания StorageClass.

kubectl apply -f storageclass.yaml

Создать запрос на постоянное хранилище

Создайте файл манифеста YAML, например acstor-pvc.yaml.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-san-encrypted
spec:
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: azuresan-csi-encrypted

Примените манифест для создания PVC.

kubectl apply -f acstor-pvc.yaml

Развертывание модуля pod

Создайте файл манифеста YAML, например acstor-pod.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: pod-san-encrypted
spec:
  nodeSelector:
    kubernetes.io/os: linux
  containers:
    - name: pod-san-encrypted
      image: mcr.microsoft.com/azurelinux/busybox:1.36
      command:
        - "/bin/sh"
        - "-c"
        - set -euo pipefail; trap exit TERM; while true; do echo "$(date)" >> /mnt/san/outfile; sleep 1; done
      volumeMounts:
        - name: persistent-storage-encrypted
          mountPath: /mnt/san
  volumes:
    - name: persistent-storage-encrypted
      persistentVolumeClaim:
        claimName: pvc-san-encrypted

Примените манифест для развертывания модуля pod.

kubectl apply -f acstor-pod.yaml

Должен отобразиться результат, как в примере ниже:

pod/pod-san-encrypted created

Проверка шифрования в группе томов

Получите дескриптор тома Elastic SAN из постоянного тома (PV):

kubectl get pv <pv-name> -o jsonpath='{.spec.csi.volumeHandle}'

Используйте группу ресурсов, имя эластичной сети SAN и имя группы томов из дескриптора тома, чтобы получить сведения о группе томов:

az elastic-san volume-group show --resource-group <resource-group-name> --elastic-san-name <elastic-san-name> --name <volume-group-name> --output json

Проверьте операции чтения и записи в зашифрованном томе:

kubectl exec pod-san-encrypted -- sh -c "echo 'testing encrypted storage' > /mnt/san/test-encryption.txt && cat /mnt/san/test-encryption.txt"

Дальнейшие шаги

• Что такое Azure Elastic SAN?
• Управление ключами клиентов для шифрования данных Azure Elastic SAN