Поделиться через

Использование расширения Secret Store для получения секретов для автономного доступа в кластерах Kubernetes с поддержкой Azure Arc

Расширение хранилища секретов Azure Key Vault для Kubernetes (SSE) автоматически синхронизирует секреты из Azure Key Vault с кластером Kubernetes с поддержкой Azure Arc для автономного доступа. Это означает, что Azure Key Vault можно использовать для хранения, обслуживания и смены секретов даже когда вы запускаете кластер Kubernetes в условиях частичного отключения. Синхронизированные секреты хранятся в хранилище секретов кластера, что делает их доступными в качестве секретов Kubernetes, которые могут использоваться всеми обычными способами: монтироваться как тома данных или предоставляться в виде переменных среды для контейнера в pod.

Синхронизированные секреты являются критически важными бизнес-ресурсами, поэтому SSE защищает их с помощью изолированных пространств имен, политик управления доступом на основе ролей (RBAC) и ограниченных разрешений для контроллера синхронизации. Для дополнительной защиты зашифруйте хранилище секретов Kubernetes в кластере.

В этой статье показано, как установить и настроить SSE в качестве расширения Kubernetes с поддержкой Azure Arc.

Подсказка

SSE рекомендуется для кластеров за пределами облака Azure, где подключение к Azure Key Vault может не быть идеальным. SSE по своей природе создает копии ваших секретов в хранилище Kubernetes. Если вы предпочитаете не создавать локальные копии секретов и кластер имеет идеальное подключение к Azure Key Vault, вы можете использовать расширение поставщика секретов Azure Key Vault только в Интернете для доступа к секретам в кластерах Kubernetes с поддержкой Arc. Не рекомендуется запускать онлайн-расширение поставщика секретов Azure Key Vault и автономный SSE вместе параллельно в одном кластере.

Предпосылки

  • Кластер с поддержкой Arc. Это может быть кластер, который вы подключили сами (в этом руководстве предполагается кластер K3s, и в нём даются указания по включению Arc) или кластер AKS, управляемый Microsoft, с включенной поддержкой Azure Arc. Кластер должен работать под управлением Kubernetes версии 1.27 или выше.
  • Убедитесь, что выполнены общие предварительные требования для расширенийk8s-extension кластера, включая последнюю версию расширения Azure CLI.
  • cert-manager необходим для поддержки TLS в целях внутрикластерного обмена журналами. Примеры в этом руководстве помогут вам пройти через процесс установки. Дополнительные сведения о диспетчере сертификатов см. в cert-manager.io

Установите Azure CLI и выполните вход, если вы еще не выполнили следующие действия.

az login

Прежде чем начать, задайте переменные среды для настройки ресурсов Azure и кластера. Если у вас уже есть управляемое удостоверение, например, Azure Key Vault или другой ресурс, указанный здесь, обновите имена в переменных среды, чтобы отразить эти ресурсы. Обратите внимание, что KEYVAULT_NAME должно быть глобально уникальным; создание keyvault завершится сбоем позже, если это имя уже используется в Azure.

export RESOURCE_GROUP="AzureArcTest"
export CLUSTER_NAME="AzureArcTest1"
export LOCATION="EastUS"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export AZURE_TENANT_ID="$(az account show -s $SUBSCRIPTION --query tenantId --output tsv)"
export CURRENT_USER="$(az account show --query user.name --output tsv)"
export KEYVAULT_NAME="my-UNIQUE-kv-name"
export KEYVAULT_SECRET_NAME="my-secret"
export USER_ASSIGNED_IDENTITY_NAME="my-identity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="my-credential"
export KUBERNETES_NAMESPACE="my-namespace"
export SERVICE_ACCOUNT_NAME="my-service-account"

При необходимости создайте группу ресурсов:

az group create --name ${RESOURCE_GROUP}  --location ${LOCATION}

Активируйте федерацию удостоверений рабочих нагрузок в вашем кластере

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

Подсказка

Следующие шаги основаны на практическом руководстве по настройке Kubernetes с поддержкой Arc и федерацией удостоверений рабочей нагрузки. Дополнительные сведения см. в этой документации.

Если кластер еще не подключен к Azure Arc, выполните следующие действия. В ходе этих действий включите федерацию удостоверений рабочей нагрузки connect в рамках команды:

az connectedk8s connect --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer

Для включения удостоверения рабочей нагрузки, если ваш кластер уже подключен к Azure Arc, используйте команду update.

az connectedk8s update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer

Теперь настройте кластер для выдачи токенов учетной записи службы с новым URL-адресом издателя service-account-issuer, который позволяет Microsoft Entra ID найти открытые ключи, необходимые для проверки этих токенов. Эти открытые ключи предназначены для издателя токенов учетной записи службы самого кластера и были получены и размещены в облаке по этому URL-адресу в результате ранее установленного параметра --enable-oidc-issuer.

При необходимости можно также настроить ограничения на собственные разрешения SSE в качестве привилегированного ресурса, работающего в плоскости управления, настроив OwnerReferencesPermissionEnforcementконтроллер допуска. Этот контроллер допуска ограничивает, сколько SSE может изменить другие объекты в кластере.

  1. Настройте kube-apiserver с полем URL-адреса издателя и принудительным соблюдением разрешений. В следующем примере используется кластер k3s. Кластер может иметь различные средства для изменения аргументов сервера API: --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}"--kube-apiserver-arg=service-account-max-token-expiration=24h и --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement".

    • Получите URL-адрес издателя учетной записи службы.

      export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER

    • Обновите аргументы сервера API в файле конфигурации кластера K3s.

      cat <<EOF > /tmp/k3s-config.yaml
kube-apiserver-arg:
    - 'service-account-issuer=${SERVICE_ACCOUNT_ISSUER}'
    - 'service-account-max-token-expiration=24h'
    - 'enable-admission-plugins=OwnerReferencesPermissionEnforcement'
EOF
sudo mv /tmp/k3s-config.yaml /etc/rancher/k3s/config.yaml

  2. Перезапустите kube-apiserver.

    sudo systemctl restart k3s

  3. (необязательно) Убедитесь, что издатель учетной записи службы настроен правильно:

    kubectl cluster-info dump | grep service-account-issuer

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

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

Создание Azure Key Vault

Создайте Azure Key Vault и добавьте секрет. Если у вас уже есть Azure Key Vault и секрет, этот раздел можно пропустить.

  1. Создайте Azure Key Vault:

    az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --name "${KEYVAULT_NAME}" --enable-rbac-authorization

  2. Назначьте себе права "администратор секретов" в хранилище, чтобы создать секрет:

    az role assignment create --role "Key Vault Secrets Officer" --assignee ${CURRENT_USER} --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}

    Подсказка

    Если эта команда завершается ошибкой из-за политик условного доступа, вы можете назначить своей учетной записи роль "Офицер секретов" с помощью портала Azure.

  3. Создайте секрет и обновите его, чтобы иметь две версии:

    az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello!'
az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello2'

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

Затем создайте управляемое удостоверение, назначаемое пользователем, и предоставьте ему разрешения на доступ к Azure Key Vault. Если у вас уже есть управляемое удостоверение с разрешениями "Key Vault Reader" и "Key Vault Secrets User" в Azure Key Vault, можно пропустить этот раздел. Дополнительные сведения см. в статье о создании управляемого удостоверения, назначаемого пользователем , и использовании секрета, ключа и сертификата Azure RBAC с помощью Key Vault.

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

    az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

  2. Предоставьте удостоверению разрешение пользователя Key Vault Reader и Key Vault Secret User. Возможно, потребуется подождать некоторое время, пока не завершится репликация создания удостоверения, прежде чем эти команды будут выполнены успешно.

    export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -otsv)"
az role assignment create --role "Key Vault Reader" --assignee "${USER_ASSIGNED_CLIENT_ID}" --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}
az role assignment create --role "Key Vault Secrets User" --assignee "${USER_ASSIGNED_CLIENT_ID}" --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}

Создать учетные данные для федеративной идентичности

Создайте учетную запись службы Kubernetes для рабочей нагрузки, требующей доступа к секретам. Затем создайте федеративные учетные данные удостоверения для установления связи между управляемым удостоверением, издателем учетной записи службы OIDC и учетной записью службы Kubernetes.

  1. Создайте учетную запись службы Kubernetes, которая будет федеративно связана с управляемым удостоверением. Заметите его с подробными сведениями о связанном управляемом удостоверении, назначаемом пользователем.

    kubectl create ns ${KUBERNETES_NAMESPACE}

    cat <<EOF | kubectl apply -f -
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: ${SERVICE_ACCOUNT_NAME}
    namespace: ${KUBERNETES_NAMESPACE}
EOF

  2. Создайте учетные данные федеративного удостоверения:

    az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name ${USER_ASSIGNED_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --issuer ${SERVICE_ACCOUNT_ISSUER} --subject system:serviceaccount:${KUBERNETES_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange

Установка SSE

Служба SSE доступна как расширение Azure Arc. Кластер Kubernetes с поддержкой Azure Arc можно расширить с помощью расширений Kubernetes с поддержкой Azure Arc. Расширения обеспечивают возможности Azure в подключенном кластере и предоставляют управляемый Azure Resource Manager интерфейс для установки и управления жизненным циклом расширений.

Диспетчер сертификатов и диспетчер доверия также требуются для безопасного взаимодействия журналов между службами кластера и должны быть установлены перед расширением Arc.

  1. Установите cert-manager.

    helm repo add jetstack https://charts.jetstack.io/ --force-update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set crds.enabled=true

  2. Установите диспетчер доверия.

    helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait

  3. Установите SSE в кластер с поддержкой Arc, выполнив следующую команду:

    az k8s-extension create \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --extension-type microsoft.azure.secretstore \
  --resource-group ${RESOURCE_GROUP} \
  --name ssarcextension \
  --scope cluster

    При необходимости можно изменить интервал опроса поворота по умолчанию, добавив --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds> (см. ссылку на конфигурацию).

Настройка SSE

Настройте установленное расширение с информацией о Azure Key Vault и секретах для синхронизации с кластером, определив экземпляры пользовательских ресурсов Kubernetes.

SSE можно настроить с помощью одного упрощенного ресурса, предназначенного для большинства вариантов использования, или внутренние компоненты SSE можно настроить непосредственно с помощью двух ресурсов. Упрощенная конфигурация — это функция предварительного просмотра и может быть улучшена с помощью несущественных изменений в предстоящих версиях. Стиль прямой конфигурации останется доступным для всех развертываний.

Самый простой способ настроить систему SSE — создать ресурс с пользовательскими настройками AKVSync. Этот ресурс фиксирует детали о вашем экземпляре AKV, какие секреты необходимо извлечь и куда их поместить в хранилище секретов Kubernetes.

cat <<EOF > akvsync.yaml
kind: AKVSync
apiVersion: secret-sync.x-k8s.io/v1alpha1
metadata:
  name: my-akv-secrets
  namespace: ${KUBERNETES_NAMESPACE}
spec:
  keyvaultName: ${KEYVAULT_NAME}
  clientID: "${USER_ASSIGNED_CLIENT_ID}"
  tenantID: "${AZURE_TENANT_ID}"
  serviceAccountName: ${SERVICE_ACCOUNT_NAME}
  objects:
    - secretInAKV: ${KEYVAULT_SECRET_NAME}
EOF

Дополнительные рекомендации по настройке см. в справочнике по AKVSync .

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

Примените настраиваемый ресурс конфигурации (CR) с помощью kubectl apply команды:

kubectl apply -f ./akvsync.yaml

При применении конфигурации AKVSync SSE автоматически создает эквивалентные прямые ресурсы конфигурации. Не изменяйте автоматически сформированные ресурсы SecretSync и SecretProviderClass, они обновляются по мере необходимости.

Служба SSE автоматически ищет секреты и начинает синхронизацию их с кластером.

Наблюдение за синхронизацией секретов с кластером

После применения конфигурации секреты начинают синхронизироваться с кластером автоматически с частотой, указанной при установке SSE.

Просмотр синхронизированных секретов

Просмотрите секреты, синхронизированные с кластером, выполнив следующую команду:

# View a list of all secrets in the namespace
kubectl get secrets -n ${KUBERNETES_NAMESPACE}

Подсказка

Добавьте -o yaml или -o json, чтобы изменить формат выводимых команд kubectl get и kubectl describe.

Просмотр значения секрета

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

kubectl get secret <NAME> -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.v0}" | base64 -d && echo

<NAME> используется ${KEYVAULT_SECRET_NAME} при использовании упрощенного примера конфигурации или secret-sync-name при использовании прямого примера конфигурации.

Устранение неполадок

См. руководство по устранению неполадок для диагностики и устранения проблем.

Удалите SSE

Чтобы удалить SSE и прекратить синхронизацию секретов, используйте команду az k8s-extension delete для удаления.

az k8s-extension delete --name ssarcextension --cluster-name $CLUSTER_NAME  --resource-group $RESOURCE_GROUP  --cluster-type connectedClusters

Удаление расширения не удаляет секреты или CRDs (AKVSync, SecretSync или SecretProviderClass) из кластера. Эти объекты должны быть удалены напрямую с помощью kubectl.

По умолчанию удаление ресурса SecretSync или AKVSync удаляет все секреты, определенные в них, но секреты могут сохраняться, если:

В этих случаях секреты необходимо удалить напрямую с помощью kubectl.

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

  • Last updated on