Используйте идентификацию рабочих нагрузок в Microsoft Entra с Azure Kubernetes Service (AKS)

Рабочие нагрузки, развернутые в кластере Служба Azure Kubernetes (AKS), требуют учетных данных приложения Microsoft Entra или управляемых удостоверений для доступа к защищенным ресурсам Microsoft Entra, таким как Azure Key Vault и Microsoft Graph. Идентификация рабочей нагрузки Microsoft Entra интегрируется с возможностями, собственными для Kubernetes, для федерации с внешними поставщиками удостоверений.

Идентификатор рабочей нагрузки Microsoft Entra использует проекцию тома токена учетной записи службы (т. е. учетную запись службы), чтобы поды могли использовать удостоверение Kubernetes. Токен Kubernetes выдан, и федерация OIDC позволяет приложениям Kubernetes безопасно получать доступ к ресурсам Azure с помощью идентификатора Microsoft Entra ID, при этом доступ основан на аннотированных учетных записях службы.

Идентификатор рабочей нагрузки Microsoft Entra работает особенно хорошо с клиентскими библиотеками Identify Azure или с коллекцией библиотек проверки подлинности Microsoft (MSAL), вместе с регистрацией приложений. Рабочая нагрузка может использовать любую из этих библиотек, чтобы легко пройти проверку подлинности и получить доступ к облачным ресурсам Azure.

Эта статья поможет вам понять идентификатор рабочей нагрузки Microsoft Entra, а также рассмотрение вариантов, доступных для планирования стратегии проекта и потенциальной миграции с удостоверения, управляемого pod в Microsoft Entra.

Зависимости

• AKS поддерживает Workload ID Microsoft Entra на версии 1.22 и выше.
• Azure CLI версии 2.47.0 или более поздней. Запустите az --version, чтобы определить версию и запустите az upgrade для обновления версии. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.

Клиентские библиотеки идентификации Azure

В клиентских библиотеках удостоверений Azure выберите один из следующих подходов:

• Используйте DefaultAzureCredential, который пытается использовать WorkloadIdentityCredential.
• Создайте экземпляр ChainedTokenCredential, который включает в себя WorkloadIdentityCredential.
• Используйте WorkloadIdentityCredential напрямую.

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

В следующих примерах DefaultAzureCredential кода используется. Этот тип учетных данных использует переменные среды, вводимые изменяющим webhook Azure Workload Identity, для аутентификации в Azure Key Vault. Чтобы просмотреть примеры с помощью одного из других подходов, обратитесь к ссылкам клиентской библиотеки для конкретной экосистемы выше.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

string keyVaultUrl = Environment.GetEnvironmentVariable("KEYVAULT_URL");
string secretName = Environment.GetEnvironmentVariable("SECRET_NAME");

var client = new SecretClient(
    new Uri(keyVaultUrl),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync(secretName);

#include <cstdlib>
#include <azure/identity.hpp>
#include <azure/keyvault/secrets/secret_client.hpp>

using namespace Azure::Identity;
using namespace Azure::Security::KeyVault::Secrets;

int main()
{
  const char* keyVaultUrl = std::getenv("KEYVAULT_URL");
  const char* secretName = std::getenv("SECRET_NAME");
  auto credential = std::make_shared<DefaultAzureCredential>();

  SecretClient client(keyVaultUrl, credential);
  Secret secret = client.GetSecret(secretName).Value;

  return 0;
}

package main

import (
	"context"
	"os"

	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets"
    "k8s.io/klog/v2"
)

func main() {
	keyVaultUrl := os.Getenv("KEYVAULT_URL")
	secretName := os.Getenv("SECRET_NAME")

	credential, err := azidentity.NewDefaultAzureCredential(nil)
	if err != nil {
		klog.Fatal(err)
	}

	client, err := azsecrets.NewClient(keyVaultUrl, credential, nil)
	if err != nil {
		klog.Fatal(err)
	}

	secret, err := client.GetSecret(context.Background(), secretName, "", nil)
	if err != nil {
		klog.ErrorS(err, "failed to get secret", "keyvault", keyVaultUrl, "secretName", secretName)
		os.Exit(1)
	}
}

import java.util.Map;

import com.azure.security.keyvault.secrets.SecretClient;
import com.azure.security.keyvault.secrets.SecretClientBuilder;
import com.azure.security.keyvault.secrets.models.KeyVaultSecret;
import com.azure.identity.DefaultAzureCredentialBuilder;
import com.azure.identity.DefaultAzureCredential;

public class App {
    public static void main(String[] args) {
        Map<String, String> env = System.getenv();
        String keyVaultUrl = env.get("KEYVAULT_URL");
        String secretName = env.get("SECRET_NAME");

        SecretClient client = new SecretClientBuilder()
                .vaultUrl(keyVaultUrl)
                .credential(new DefaultAzureCredentialBuilder().build())
                .buildClient();
        KeyVaultSecret secret = client.getSecret(secretName);
    }
}

import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";

const main = async () => {
    const keyVaultUrl = process.env["KEYVAULT_URL"];
    const secretName = process.env["SECRET_NAME"];

    const credential = new DefaultAzureCredential();
    const client = new SecretClient(keyVaultUrl, credential);

    const secret = await client.getSecret(secretName);
}

main().catch((error) => {
    console.error("An error occurred:", error);
    process.exit(1);
});

import os

from azure.keyvault.secrets import SecretClient
from azure.identity import DefaultAzureCredential

def main():
    keyvault_url = os.getenv('KEYVAULT_URL', '')
    secret_name = os.getenv('SECRET_NAME', '')

    client = SecretClient(vault_url=keyvault_url, credential=DefaultAzureCredential())
    secret = client.get_secret(secret_name)

if __name__ == '__main__':
    main()

Библиотека проверки подлинности Майкрософт (MSAL)

Следующие клиентские библиотеки являются минимальной версией.

Ограничения

• Для каждого управляемого удостоверения можно иметь не более 20 федеративных учетных данных.
• Для распространения учетных данных федеративного удостоверения после первоначального добавления потребуется несколько секунд.
• Виртуальные узлы, добавленные на основе проекта открытый код Virtual Kubelet, не поддерживаются.
• Создание учетных данных федеративного удостоверения не поддерживается для управляемых удостоверений, назначаемых пользователем, в этих регионах.

Принцип работы

В этой модели безопасности кластер AKS выступает в качестве издателя маркеров. Идентификатор Microsoft Entra использует OpenID Connect для обнаружения открытых ключей подписывания и проверки подлинности токена учетной записи службы перед обменом его на токен Microsoft Entra. Рабочая нагрузка может обменять токен служебной учётной записи, проецируемый на его объём, на токен Microsoft Entra с помощью клиентской библиотеки Microsoft Identity или библиотеки аутентификации Microsoft (MSAL).

В следующей таблице описаны необходимые конечные точки издателя OIDC для идентификатора рабочей нагрузки Microsoft Entra.

На следующей схеме показана последовательность проверки подлинности с помощью OpenID Connect.

Автоматическая смена сертификата вебхука

Аналогично другим надстройкам вебхуков, сертификат обновляется операцией автоматической смены сертификата в кластере.

Метки и аннотации учетной записи службы

Microsoft Entra Workload ID поддерживает следующие сопоставления, связанные с сервисной учетной записью:

• Один к одному, где учетная запись службы ссылается на объект Microsoft Entra.
• Многие к одному, где несколько учетных записей служб ссылались на один и тот же объект Microsoft Entra.
• Один ко многим, где учетная запись службы ссылается на несколько объектов Microsoft Entra путем изменения заметки идентификатора клиента. Дополнительные сведения см. в статье "Как объединить несколько удостоверений с учетной записью Kubernetes".

Если вы использовали управляемое пользователем удостоверение Microsoft Entra pod, то думайте о учетной записи службы как субъекте безопасности Azure, за исключением того, что учетная запись службы является частью основного API Kubernetes, а не пользовательского определения ресурсов (CRD). В следующих разделах описан список доступных меток и аннотаций, которые можно использовать для настройки поведения при получении токена доступа Microsoft Entra вместо токена учетной записи службы.

Аннотации учетной записи службы

Все заметки являются необязательными. Если заметка не указана, будет использоваться значение по умолчанию.

Метки Pod

Аннотации pod

Все заметки являются необязательными. Если заметка не указана, будет использоваться значение по умолчанию.

¹ Имеет приоритет, если учетная запись службы также аннотирована.

Как перейти на Microsoft Entra Workload ID

В кластере, который уже работает с управляемым модулем pod, его можно настроить для использования удостоверения рабочей нагрузки одним из двух способов. Первый вариант позволяет использовать ту же конфигурацию, которую вы реализовали для управляемого pod удостоверения. Учетной записи службы в пространстве имен можно добавить аннотацию с идентификатором для включения Microsoft Entra Workload ID и внедрения аннотаций в поды.

Второй вариант — перезаписать приложение, чтобы использовать последнюю версию клиентской библиотеки удостоверений Azure.

Чтобы упростить процесс миграции и упростить процесс миграции, мы разработали боковик миграции, который преобразует транзакции IMDS, выполняемые приложением, в OpenID Connect (OIDC). Боковой автомобиль миграции не предназначен для долгосрочного решения, но способ быстрого выполнения и быстрого выполнения на удостоверениях рабочей нагрузки. Запуск бокового автомобиля миграции в прокси приложения выполняет транзакции IMDS приложения к OIDC. Альтернативный подход — обновление до поддерживаемой версии клиентской библиотеки удостоверений Azure, которая поддерживает проверку подлинности OIDC.

В следующей таблице приведены рекомендации по миграции или развертыванию для идентификации рабочей нагрузки.

Следующие шаги

• Чтобы узнать, как настроить pod для проверки подлинности с помощью удостоверения рабочей нагрузки в качестве варианта миграции, см. статью "Модернизация проверки подлинности приложения с помощью удостоверения рабочей нагрузки".
• См. раздел «Развертывание и настройка кластера AKS с удостоверением рабочей нагрузки», который поможет вам развернуть кластер Службы Azure Kubernetes и настроить пример приложения для использования удостоверения рабочей нагрузки.