Включение шифрования данных KMS в кластерах службы Azure Kubernetes (AKS) (предварительная версия)

В этой статье показано, как включить шифрование данных службы управления ключами (KMS) для секретов Kubernetes в службе Azure Kubernetes (AKS). Шифрование KMS шифрует секреты Kubernetes, хранящиеся в etcd, с помощью ключей Azure Key Vault.

AKS поддерживает два варианта управления ключами:

• Управляемые платформой ключи (PMK): AKS автоматически создает ключи шифрования и управляет ими. Этот параметр обеспечивает простую настройку с автоматическим поворотом ключей.
• Управляемые клиентом ключи (CMK): вы создаете и управляете собственными ключами Azure Key Vault и ключами шифрования. Этот параметр обеспечивает полный контроль над жизненным циклом ключей и соответствует требованиям соответствия, которые предписывают использование ключей, управляемых клиентом.

Дополнительные сведения о понятиях шифрования и параметрах ключей см. раздел о шифровании неактивных данных для AKS.

Это важно

Предварительные версии функций AKS доступны на условиях самообслуживания и добровольного выбора. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии AKS сопровождаются частичной поддержкой клиентов на основе принципа лучших усилий. Как таковые, эти функции не предназначены для использования в производстве. Для получения дополнительной информации ознакомьтесь со следующими статьями поддержки:

• Политики поддержки AKS
• Часто задаваемые вопросы о поддержке Azure

Предпосылки

• Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см. в статье "Начало работы с Azure Cloud Shell".

  

• Если вы предпочитаете запускать справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, подумайте о запуске Azure CLI в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.

  • Если вы используете локальную установку, войдите в Azure CLI с помощью команды az login . Чтобы завершить процесс аутентификации, следуйте шагам, отображаемым в вашем терминале. Сведения о других параметрах входа см. в статье "Проверка подлинности в Azure с помощью Azure CLI".

  • Когда вас попросят, установите расширение Azure CLI при первом использовании. Дополнительные сведения о расширениях см. в статье Использование расширений и управление ими с помощью Azure CLI.

  • Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

• Для этой статьи требуется версия 2.73.0 или более поздняя версия Azure CLI. Если вы используете Azure Cloud Shell, последняя версия уже установлена там.
• Вам потребуется aks-preview расширение Azure CLI версии 19.0.0b13 или более поздней.
  • Если у вас еще нет aks-preview расширения, установите его с помощью az extension add команды.

    az extension add --name aks-preview
    

  • Если у вас уже есть aks-preview расширение, обновите его, чтобы убедиться, что у вас установлена последняя версия с помощью az extension update команды.

    az extension update --name aks-preview
    

• kubectl Установлен инструмент CLI.

Регистрация флага компонента

Чтобы использовать шифрование данных KMS с ключами, управляемыми платформой, зарегистрируйте флаг функции KMSPMKPreview в подписке.

1. Зарегистрируйте флаг компонента с помощью az feature register команды.

   az feature register --namespace Microsoft.ContainerService --name KMSPMKPreview
   

2. Проверьте состояние регистрации с помощью az feature show команды. Через несколько минут отобразится состояние Registered (Зарегистрировано).

   az feature show --namespace Microsoft.ContainerService --name KMSPMKPreview
   

3. Когда отображается состояние "Зарегистрировано", обновите регистрацию поставщика ресурсов Microsoft.ContainerService с помощью az provider register команды.

   az provider register --namespace Microsoft.ContainerService
   

Настройка переменных среды

Настройте переменные среды для развертывания. Замените значения заполнителей собственными.

# Set environment variables
export SUBSCRIPTION_ID="<your-subscription-id>"
export RESOURCE_GROUP="<your-resource-group>"
export LOCATION="<your-location>"
export CLUSTER_NAME="<your-cluster-name>"

# Set subscription
az account set --subscription $SUBSCRIPTION_ID

# Create resource group if it doesn't exist
az group create --name $RESOURCE_GROUP --location $LOCATION

Включение шифрования ключей, управляемых платформой

С помощью ключей, управляемых платформой, AKS автоматически создает и управляет azure Key Vault и ключами шифрования. Поворот ключа автоматически обрабатывается платформой.

Создание кластера AKS с ключами, управляемыми платформой

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

az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --kubernetes-version 1.33.0 \
    --kms-infrastructure-encryption Enabled \
    --generate-ssh-keys

Включение управляемых платформой ключей в существующем кластере

Включите шифрование KMS с помощью ключей, управляемых платформой, в существующем кластере AKS.

Замечание

Кластер должен работать под управлением Kubernetes версии 1.33 или более поздней.

az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --kms-infrastructure-encryption Enabled

Проверка конфигурации KMS

После включения шифрования KMS проверьте конфигурацию.

az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query 'securityProfile'

Выходные данные включают конфигурацию KMS:

{
    "kubernetesResourceObjectEncryptionProfile": {
        "infrastructureEncryption": "Enabled"
    }
}

Включение шифрования ключей, управляемого клиентом, с помощью хранилища закрытых ключей

Для повышения безопасности можно использовать закрытое хранилище ключей с отключенным доступом к общедоступной сети. AKS обращается к хранилищу закрытых ключей через исключение брандмауэра доверенных служб. В этом разделе показано, как настроить управляемые клиентом ключи с помощью хранилища закрытых ключей.

Создание хранилища ключей и ключа с доступом к доверенным службам

Замечание

В этом разделе показано создание хранилища ключей с доступом к общедоступной сети, а затем включение брандмауэра с обходом доверенных служб. Этот подход предназначен только для иллюстрирующих целей. В рабочих средах необходимо создать хранилище ключей и управлять им как закрытым с самого начала. Рекомендации по управлению хранилищами закрытых ключей см. в разделе "Безопасность сети Azure Key Vault".

1. Создайте хранилище ключей с включенной функцией Azure RBAC.

   export KEY_VAULT_NAME="<your-key-vault-name>"
   
   az keyvault create \
       --name $KEY_VAULT_NAME \
       --resource-group $RESOURCE_GROUP \
       --enable-rbac-authorization true \
       --public-network-access Enabled
   
   # Get the key vault resource ID
   export KEY_VAULT_RESOURCE_ID=$(az keyvault show --name $KEY_VAULT_NAME --resource-group $RESOURCE_GROUP --query id -o tsv)
   

2. Назначьте себе роль сотрудника по шифрованию Key Vault, чтобы создать ключ.

   az role assignment create \
       --role "Key Vault Crypto Officer" \
       --assignee-object-id $(az ad signed-in-user show --query id -o tsv) \
       --assignee-principal-type "User" \
       --scope $KEY_VAULT_RESOURCE_ID
   

3. Создайте ключ в хранилище ключей.

   export KEY_NAME="<your-key-name>"
   
   az keyvault key create --name $KEY_NAME --vault-name $KEY_VAULT_NAME
   
   # Get the key ID (without version for automatic rotation)
   export KEY_ID=$(az keyvault key show --name $KEY_NAME --vault-name $KEY_VAULT_NAME --query 'key.kid' -o tsv)
   export KEY_ID_NO_VERSION=$(echo $KEY_ID | sed 's|/[^/]*$||')
   

4. Включите брандмауэр хранилища ключей с возможностью обхода для доверенных служб.

   az keyvault update \
       --name $KEY_VAULT_NAME \
       --resource-group $RESOURCE_GROUP \
       --default-action Deny \
       --bypass AzureServices
   

   Параметр --default-action Deny блокирует доступ к общедоступной сети, а --bypass AzureServices параметр позволяет доверенным службам Azure (включая AKS) получить доступ к хранилищу ключей.

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

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

   export IDENTITY_NAME="<your-identity-name>"
   
   az identity create --name $IDENTITY_NAME --resource-group $RESOURCE_GROUP
   
   # Get the identity details
   export IDENTITY_OBJECT_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RESOURCE_GROUP --query 'principalId' -o tsv)
   export IDENTITY_RESOURCE_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RESOURCE_GROUP --query 'id' -o tsv)
   

2. Назначьте необходимые роли управляемому удостоверению.

   # Assign Key Vault Crypto User role for encrypt/decrypt operations
   az role assignment create \
       --role "Key Vault Crypto User" \
       --assignee-object-id $IDENTITY_OBJECT_ID \
       --assignee-principal-type "ServicePrincipal" \
       --scope $KEY_VAULT_RESOURCE_ID
   
   # Assign Key Vault Contributor role for key management
   az role assignment create \
       --role "Key Vault Contributor" \
       --assignee-object-id $IDENTITY_OBJECT_ID \
       --assignee-principal-type "ServicePrincipal" \
       --scope $KEY_VAULT_RESOURCE_ID
   

Создание нового кластера AKS с частными ключами, управляемыми клиентом.

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

az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --kubernetes-version 1.33.0 \
    --kms-infrastructure-encryption Enabled \
    --enable-azure-keyvault-kms \
    --azure-keyvault-kms-key-id $KEY_ID_NO_VERSION \
    --azure-keyvault-kms-key-vault-resource-id $KEY_VAULT_RESOURCE_ID \
    --azure-keyvault-kms-key-vault-network-access Private \
    --assign-identity $IDENTITY_RESOURCE_ID \
    --generate-ssh-keys

Включение ключей, управляемых клиентом, в существующем кластере (частном)

Включите шифрование KMS с помощью ключей, управляемых клиентом, с помощью хранилища закрытых ключей в существующем кластере AKS.

Замечание

Кластер должен работать под управлением Kubernetes версии 1.33 или более поздней.

az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --kms-infrastructure-encryption Enabled \
    --enable-azure-keyvault-kms \
    --azure-keyvault-kms-key-id $KEY_ID_NO_VERSION \
    --azure-keyvault-kms-key-vault-resource-id $KEY_VAULT_RESOURCE_ID \
    --azure-keyvault-kms-key-vault-network-access Private \
    --assign-identity $IDENTITY_RESOURCE_ID

Проверка конфигурации KMS

После включения шифрования KMS проверьте конфигурацию.

az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query 'securityProfile'

Выходные данные включают конфигурацию KMS:

{
    "azureKeyVaultKms": {
        "enabled": true,
        "keyId": "https://<key-vault-name>.vault.azure.net/keys/<key-name>",
        "keyVaultNetworkAccess": "Private",
        "keyVaultResourceId": "<key-vault-resource-id>"
    },
    "kubernetesResourceObjectEncryptionProfile": {
        "infrastructureEncryption": "Enabled"
    }
}

Включение шифрования ключей, управляемого клиентом, с помощью хранилища открытых ключей

С помощью управляемых клиентом ключей вы создаете и управляете собственными ключами Azure Key Vault и ключами шифрования. В этом разделе показано, как настроить управляемые клиентом ключи с помощью хранилища открытых ключей.

Создание хранилища ключей и ключа

1. Создайте хранилище ключей с включенной функцией Azure RBAC.

   export KEY_VAULT_NAME="<your-key-vault-name>"
   
   az keyvault create \
       --name $KEY_VAULT_NAME \
       --resource-group $RESOURCE_GROUP \
       --enable-rbac-authorization true \
       --public-network-access Enabled
   
   # Get the key vault resource ID
   export KEY_VAULT_RESOURCE_ID=$(az keyvault show --name $KEY_VAULT_NAME --resource-group $RESOURCE_GROUP --query id -o tsv)
   

2. Назначьте себе роль сотрудника по шифрованию Key Vault, чтобы создать ключ.

   az role assignment create \
       --role "Key Vault Crypto Officer" \
       --assignee-object-id $(az ad signed-in-user show --query id -o tsv) \
       --assignee-principal-type "User" \
       --scope $KEY_VAULT_RESOURCE_ID
   

3. Создайте ключ в хранилище ключей.

   export KEY_NAME="<your-key-name>"
   
   az keyvault key create --name $KEY_NAME --vault-name $KEY_VAULT_NAME
   
   # Get the key ID (without version for automatic rotation)
   export KEY_ID=$(az keyvault key show --name $KEY_NAME --vault-name $KEY_VAULT_NAME --query 'key.kid' -o tsv)
   export KEY_ID_NO_VERSION=$(echo $KEY_ID | sed 's|/[^/]*$||')
   

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

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

   export IDENTITY_NAME="<your-identity-name>"
   
   az identity create --name $IDENTITY_NAME --resource-group $RESOURCE_GROUP
   
   # Get the identity details
   export IDENTITY_OBJECT_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RESOURCE_GROUP --query 'principalId' -o tsv)
   export IDENTITY_RESOURCE_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RESOURCE_GROUP --query 'id' -o tsv)
   

2. Назначьте необходимые роли управляемому удостоверению.

   # Assign Key Vault Crypto User role for encrypt/decrypt operations
   az role assignment create \
       --role "Key Vault Crypto User" \
       --assignee-object-id $IDENTITY_OBJECT_ID \
       --assignee-principal-type "ServicePrincipal" \
       --scope $KEY_VAULT_RESOURCE_ID
   
   # Assign Key Vault Contributor role for key management
   az role assignment create \
       --role "Key Vault Contributor" \
       --assignee-object-id $IDENTITY_OBJECT_ID \
       --assignee-principal-type "ServicePrincipal" \
       --scope $KEY_VAULT_RESOURCE_ID
   

Создание кластера AKS с ключами, управляемыми клиентом

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

az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --kubernetes-version 1.33.0 \
    --kms-infrastructure-encryption Enabled \
    --enable-azure-keyvault-kms \
    --azure-keyvault-kms-key-id $KEY_ID_NO_VERSION \
    --azure-keyvault-kms-key-vault-resource-id $KEY_VAULT_RESOURCE_ID \
    --azure-keyvault-kms-key-vault-network-access Public \
    --assign-identity $IDENTITY_RESOURCE_ID \
    --generate-ssh-keys

Включение ключей, управляемых клиентом в существующем кластере

Включите шифрование KMS с помощью ключей, управляемых клиентом, в существующем кластере AKS.

Замечание

Кластер должен работать под управлением Kubernetes версии 1.33 или более поздней.

az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --kms-infrastructure-encryption Enabled \
    --enable-azure-keyvault-kms \
    --azure-keyvault-kms-key-id $KEY_ID_NO_VERSION \
    --azure-keyvault-kms-key-vault-resource-id $KEY_VAULT_RESOURCE_ID \
    --azure-keyvault-kms-key-vault-network-access Public \
    --assign-identity $IDENTITY_RESOURCE_ID

Проверка конфигурации KMS

После включения шифрования KMS проверьте конфигурацию.

az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query 'securityProfile'

Выходные данные включают конфигурацию KMS:

{
    "azureKeyVaultKms": {
        "enabled": true,
        "keyId": "https://<key-vault-name>.vault.azure.net/keys/<key-name>",
        "keyVaultNetworkAccess": "Public",
        "keyVaultResourceId": "<key-vault-resource-id>"
    },
    "kubernetesResourceObjectEncryptionProfile": {
        "infrastructureEncryption": "Enabled"
    }
}

Перейти между опциями управления ключами

Вы можете мигрировать между ключами, управляемыми платформой, и ключами, управляемыми клиентом.

Переход с управляемых платформой ключей на ключи, управляемые клиентом

Чтобы перейти с управляемых платформой ключей на ключи, управляемые клиентом, сначала настройте хранилище ключей, ключ и управляемое удостоверение, как описано в разделе ключей, управляемых клиентом, а затем выполните команду обновления:

az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --kms-infrastructure-encryption Enabled \
    --enable-azure-keyvault-kms \
    --azure-keyvault-kms-key-id $KEY_ID_NO_VERSION \
    --azure-keyvault-kms-key-vault-resource-id $KEY_VAULT_RESOURCE_ID \
    --azure-keyvault-kms-key-vault-network-access Public \
    --assign-identity $IDENTITY_RESOURCE_ID

Переход с управляемых клиентом ключей на ключи, управляемые платформой

Чтобы перенести ключи, управляемые клиентом, на ключи, управляемые платформой, выполните приведенные далее действия.

az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --kms-infrastructure-encryption Enabled \
    --disable-azure-keyvault-kms

Ротация ключей

При шифровании данных KMS смена ключей обрабатывается по-разному в зависимости от параметра управления ключами:

• Управляемые платформой ключи: смена ключей выполняется автоматически. Никаких действий не требуется.
• Управляемые клиентом ключи. При смене версии ключа в Azure Key Vault контроллер KMS периодически обнаруживает поворот (каждые 6 часов) и использует новую версию ключа.

Замечание

В отличие от устаревшего интерфейса KMS, с этой новой реализацией не нужно вручную повторно шифровать секреты после смены ключей. Платформа обрабатывает это автоматически.

Связанный контент

• Основные понятия шифрования неактивных данных для AKS
• Наблюдаемость шифрования KMS и т. д.
• Устаревшее шифрование KMS и etcd
• Шифрование неактивных данных в Azure