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

Статья
11/19/2024

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

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

Совет

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

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

Внимание

В настоящее время SSE находится в предварительной версии. Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.

Необходимые компоненты

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

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

az login

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

export RESOURCE_GROUP="AzureArcTest"
export CLUSTER_NAME="AzureArcTest1"
export LOCATION="EastUS"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
az account set --subscription "${SUBSCRIPTION}"
export AZURE_TENANT_ID="$(az account show -s $SUBSCRIPTION --query tenantId --output tsv)"
export CURRENT_USER="$(az ad signed-in-user show --query userPrincipalName --output tsv)"
export KEYVAULT_NAME="my-kv"
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"

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

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

Совет

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

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

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

Если кластер уже подключен к Azure Arc, включите удостоверение рабочей нагрузки update с помощью команды:

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

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

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

Настройте kube-apiserver с помощью поля URL-адреса издателя и принудительного применения разрешений. В следующем примере используется кластер k3s. Ваш кластер может иметь разные средства для изменения аргументов сервера API: --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --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
```
- Откройте файл конфигурации сервера K3s.
```
sudo nano /etc/systemd/system/k3s.service
```
- Измените конфигурацию сервера, чтобы выглядеть так, как показано в следующем примере, заменив <SERVICE_ACCOUNT_ISSUER> приведенными выше выходными данными echo $SERVICE_ACCOUNT_ISSUER, не забывая включить косую черту в конце этого URL-адреса:
```
ExecStart=/usr/local/bin/k3s \
  server --write-kubeconfig-mode=644 \
     --kube-apiserver-arg="--service-account-issuer=<SERVICE_ACCOUNT_ISSUER>" \
     --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement"
```

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

sudo systemctl daemon-reload
sudo systemctl restart k3s

Используйте руководство по активации федерации удостоверений рабочей нагрузки в AKS в Azure Local с помощью --enable-oidc-issuer флагов и --enable-workload-identity флагов.

Вернитесь к этим шагам после первоначальной активации. Оставшейся части этого руководства не требуется.

Убедитесь, что активация выполнена успешно, получив URL-адрес издателя учетной записи службы кластера. Этот URL-адрес будет использоваться в следующих шагах:

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

Используйте руководство по активации федерации удостоверений рабочей нагрузки в AKS Edge Essentials.

Вернитесь к этим шагам после первоначальной активации. Оставшейся части этого руководства не требуется.

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

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

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

создать Azure Key Vault;

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

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

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

Предоставьте себе разрешения "Офицер секретов" в хранилище, чтобы создать секрет:

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

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

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 и пользователей секретов Key Vault в Azure Key Vault, можно пропустить этот раздел. Дополнительные сведения см. в статье "Создание управляемых удостоверений, назначенных пользователем" и использование секрета, ключа и сертификата Azure RBAC с помощью Key Vault.

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

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

Предоставьте удостоверению разрешение пользователя 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.

Создайте учетную запись службы Kubernetes, которая будет федеративна с управляемым удостоверением. Заметите его с подробными сведениями о связанном управляемом удостоверении, назначаемом пользователем.
```
kubectl create ns ${KUBERNETES_NAMESPACE}
```
```
cat <<EOF | kubectl apply -f -
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: ${SERVICE_ACCOUNT_NAME}
    namespace: ${KUBERNETES_NAMESPACE}
EOF
```

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

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}

Установка SSE

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

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

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

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

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

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

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

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

При необходимости можно изменить интервал опроса поворота по умолчанию, добавив --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds>:

Наименование параметра	Description	Default value
`rotationPollIntervalInSeconds`	Указывает, как быстро SSE проверяет или обновляет секрет, который он управляет.	`3600` (1 час)

Настройка SSE

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

SecretProviderClass Объект, определяющий подключение к Key Vault.
SecretSync Объект для синхронизации каждого секрета.

`SecretProviderClass` Создание ресурса

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

Для каждого azure Key Vault необходимо синхронизировать отдельное SecretProviderClass удостоверение, используемое для доступа к Azure Key Vault, и для каждого целевого пространства имен Kubernetes.

Создайте один или несколько SecretProviderClass файлов YAML с соответствующими значениями для Key Vault и секретов, следуя этому примеру.

cat <<EOF > spc.yaml
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: secret-provider-class-name                      # Name of the class; must be unique per Kubernetes namespace
  namespace: ${KUBERNETES_NAMESPACE}                    # Kubernetes namespace to make the secrets accessible in
spec:
  provider: azure
  parameters:
    clientID: "${USER_ASSIGNED_CLIENT_ID}"               # Managed Identity Client ID for accessing the Azure Key Vault with.
    keyvaultName: ${KEYVAULT_NAME}                       # The name of the Azure Key Vault to synchronize secrets from.
    objects: |
      array:
        - |
          objectName: ${KEYVAULT_SECRET_NAME}            # The name of the secret to sychronize.
          objectType: secret
          objectVersionHistory: 2                       # [optional] The number of versions to synchronize, starting from latest.
    tenantID: "${AZURE_TENANT_ID}"                       # The tenant ID of the Key Vault 
EOF

`SecretSync` Создание объекта

Каждый синхронизированный SecretSync секрет также требует объекта для определения сведений, относящихся к кластеру. Здесь вы указываете такие сведения, как имя секрета в кластере и имена для каждой версии секрета, хранящегося в кластере.

Создайте один SecretSync файл YAML объекта для каждого секрета, следуя этому шаблону. Пространство имен Kubernetes должно соответствовать пространству имен сопоставления SecretProviderClass.

cat <<EOF > ss.yaml
apiVersion: secret-sync.x-k8s.io/v1alpha1
kind: SecretSync
metadata:
  name: secret-sync-name                                  # Name of the object; must be unique per Kubernetes namespace
  namespace: ${KUBERNETES_NAMESPACE}                      # Kubernetes namespace
spec:
  serviceAccountName: ${SERVICE_ACCOUNT_NAME}             # The Kubernetes service account to be given permissions to access the secret.
  secretProviderClassName: secret-provider-class-name     # The name of the matching SecretProviderClass with the configuration to access the AKV storing this secret
  secretObject:
    type: Opaque
    data:
    - sourcePath: ${KEYVAULT_SECRET_NAME}/0                # Name of the secret in Azure Key Vault with an optional version number (defaults to latest)
      targetKey: ${KEYVAULT_SECRET_NAME}-data-key0         # Target name of the secret in the Kubernetes secret store (must be unique)
    - sourcePath: ${KEYVAULT_SECRET_NAME}/1                # [optional] Next version of the AKV secret. Note that versions of the secret must match the configured objectVersionHistory in the secrets provider class 
      targetKey: ${KEYVAULT_SECRET_NAME}-data-key1         # [optional] Next target name of the secret in the K8s secret store
EOF

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

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

kubectl apply -f ./spc.yaml
kubectl apply -f ./ss.yaml

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

Просмотр параметров конфигурации

Чтобы просмотреть дополнительные параметры конфигурации для этих двух пользовательских типов ресурсов, используйте kubectl describe команду для проверки crD в кластере:

# Get the name of any applied CRD(s)
kubectl get crds -o custom-columns=NAME:.metadata.name

# View the full configuration options and field parameters for a given CRD
kubectl describe crd secretproviderclass
kubectl describe crd secretsync

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

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

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

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

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

# View details of all secrets in the namespace
kubectl get secrets -n ${KUBERNETES_NAMESPACE} -o yaml

Просмотр состояния последней синхронизации

Чтобы просмотреть состояние последней синхронизации для заданного секрета, используйте kubectl describe команду для SecretSync объекта. Выходные данные включают метку времени создания секрета, версии секрета и подробные сообщения о состоянии для каждого события синхронизации. Эти выходные данные можно использовать для диагностики ошибок подключения или конфигурации, а также для наблюдения за изменением значения секрета.

kubectl describe secretsync secret-sync-name -n ${KUBERNETES_NAMESPACE}

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

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

kubectl get secret secret-sync-name -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.${KEYVAULT_SECRET_NAME}-data-key0}" | base64 -d
kubectl get secret secret-sync-name -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.${KEYVAULT_SECRET_NAME}-data-key1}" | base64 -d

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

SSE — это развертывание Kubernetes, содержащее модуль pod с двумя контейнерами: контроллер, который управляет хранением секретов в кластере и поставщиком, который управляет доступом к и извлекает секреты из Azure Key Vault. Каждый синхронизированный SecretSync секрет содержит объект, содержащий состояние синхронизации этого секрета из Azure Key Vault в хранилище секретов кластера.

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

Тип состояния SecretSync	Сведения	Действия по исправлению и изучению дальнейших действий
`CreateSucceeded`	Секрет был успешно создан.	Н/Д
`CreateFailedProviderError`	Сбой создания секрета из-за некоторых проблем с поставщиком (подключение к Azure Key Vault). Эта ошибка может быть вызвана подключением к Интернету, недостаточными разрешениями для секретов синхронизации удостоверений, неправильной настройки `SecretProviderClass`или других проблем.	Дополнительные сведения см. в журналах поставщика с помощью следующих команд: `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'`
`CreateFailedInvalidLabel`	Не удалось создать секрет, так как секрет уже существует без правильной метки Kubernetes, которую SSE использует для управления секретами.	Удалите существующую метку и секрет и разрешите SSE повторно создать секрет: `kubectl delete secret <secret-name>` Чтобы принудительно создать секрет быстрее, чем настроенный интервал опроса поворота, удалите `SecretSync` объект (`kubectl delete secretsync <secret-name>`) и повторно примените класс синхронизации секретов (`kubectl apply -f <path_to_secret_sync>`).
`CreateFailedInvalidAnnotation`	Не удалось создать секрет, так как секрет уже существует без правильной заметки Kubernetes, которую SSE использует для управления секретами.	Удалите существующую заметку и секрет и разрешите SSE повторно создать секрет: `kubectl delete secret <secret-name>` Чтобы принудительно создать секрет быстрее, чем настроенный интервал опроса поворота, удалите `SecretSync` объект (`kubectl delete secretsync <secret-name>`) и повторно примените класс синхронизации секретов (`kubectl apply -f <path_to_secret_sync>`).
`UpdateNoValueChangeSucceeded`	Служба SSE проверила Azure Key Vault на наличие обновлений в конце настроенного интервала опроса, но не было изменений для синхронизации.	Н/Д
`UpdateValueChangeOrForceUpdateSucceeded`	Служба SSE проверила Azure Key Vault на наличие обновлений и успешно обновила значение.	Н/Д
`UpdateFailedInvalidLabel`	Сбой обновления секрета, так как метка секрета, которую SSE использует для управления секретами, была изменена.	Удалите существующую метку и секрет и разрешите SSE повторно создать секрет: `kubectl delete secret <secret-name>` Чтобы принудительно создать секрет быстрее, чем настроенный интервал опроса поворота, удалите `SecretSync` объект (`kubectl delete secretsync <secret-name>`) и повторно примените класс синхронизации секретов (`kubectl apply -f <path_to_secret_sync>`).
`UpdateFailedInvalidAnnotation`	Сбой обновления секрета, так как заметка о секрете, который SSE использует для управления секретами, была изменена.	Удалите существующую заметку и секрет и разрешите SSE повторно создать секрет: `kubectl delete secret <secret-name>` Чтобы принудительно создать секрет быстрее, чем настроенный интервал опроса поворота, удалите `SecretSync` объект (`kubectl delete secretsync <secret-name>`) и повторно примените класс синхронизации секретов (`kubectl apply -f <path_to_secret_sync>`).
`UpdateFailedProviderError`	Сбой обновления секрета из-за некоторых проблем с поставщиком (подключение к Azure Key Vault). Эта ошибка может быть вызвана подключением к Интернету, недостаточными разрешениями для секретов синхронизации удостоверений, конфигурации `SecretProviderClass`или других проблем.	Дополнительные сведения см. в журналах поставщика с помощью следующих команд: `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'`
`UserInputValidationFailed`	Сбой обновления секрета, так как класс синхронизации секретов настроен неправильно (например, недопустимый тип секрета).	Просмотрите определение класса синхронизации секретов и исправьте все ошибки. Затем удалите объект (), удалите `SecretSync` класс синхронизации секретов (`kubectl delete -f <path_to_secret_sync>`) и повторно примените класс синхронизации секретов (`kubectl apply -f <path_to_secret_sync>`).`kubectl delete secretsync <secret-name>`
`ControllerSpcError`	Сбой обновления секрета, так как SSE не удалось получить класс поставщика или класс поставщика неправильно настроен.	Проверьте класс поставщика и исправьте все ошибки. Затем удалите объект (), удалите `SecretSync` класс поставщика (`kubectl delete -f <path_to_provider>`) и повторно примените класс поставщика (`kubectl apply -f <path_to_provider>`).`kubectl delete secretsync <secret-name>`
`ControllerInternalError`	Сбой обновления секрета из-за внутренней ошибки в SSE.	Дополнительные сведения см. в журналах SSE или событиях. `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager'`
`SecretPatchFailedUnknownError`	Сбой обновления секрета во время исправления значения секрета Kubernetes. Эта ошибка может произойти, если секрет был изменен кем-либо, кроме SSE, или если во время обновления SSE возникли проблемы.	Попробуйте удалить секрет и `SecretSync` объект, а затем позволить SSE повторно создать секрет, повторно применив синхронизацию секретов CR: `kubectl delete secret <secret-name>` `kubectl delete secretsync <secret-name>` `kubectl apply -f <path_to_secret_sync>`

Удаление SSE

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

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

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

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

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

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

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

Дополнительные сведения о расширениях Azure Arc.
Дополнительные сведения об Azure Key Vault.

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

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

Необходимые компоненты

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

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

создать Azure Key Vault;

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

Создание учетных данных федеративного удостоверения

Установка SSE

Настройка SSE

`SecretProviderClass` Создание ресурса

`SecretSync` Создание объекта

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

Просмотр параметров конфигурации

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

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

Просмотр состояния последней синхронизации

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

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

Удаление SSE

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

Обратная связь

Дополнительные ресурсы

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

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

Необходимые компоненты

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

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

создать Azure Key Vault;

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

Создание учетных данных федеративного удостоверения

Установка SSE

Настройка SSE

SecretProviderClass Создание ресурса

SecretSync Создание объекта

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

Просмотр параметров конфигурации

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

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

Просмотр состояния последней синхронизации

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

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

Удаление SSE

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

Обратная связь

Дополнительные ресурсы

`SecretProviderClass` Создание ресурса

`SecretSync` Создание объекта