Uso de la extensión Secret Store para capturar secretos para el acceso sin conexión en clústeres de Kubernetes habilitados para Azure Arc

Artículo
12/11/2024

La extensión Almacén secreto de Azure Key Vault para Kubernetes ("SSE") sincroniza automáticamente los secretos de una instancia de Azure Key Vault con un clúster de Kubernetes habilitado para Azure Arc para el acceso sin conexión. Esto significa que puede usar Azure Key Vault para almacenar, mantener y rotar los secretos, incluso cuando se ejecuta el clúster de Kubernetes en un estado semiconectado. Los secretos sincronizados se almacenan en el almacén de secretos de clúster, lo que hace que estén disponibles como secretos de Kubernetes que se usarán de todas las maneras habituales: montados como volúmenes de datos o expuestos como variables de entorno a un contenedor de un pod.

Los secretos sincronizados son recursos empresariales críticos, por lo que SSE los protege a través de espacios de nombres y nodos aislados, directivas de control de acceso basado en rol (RBAC) y permisos limitados para el sincronizador de secretos. Para obtener protección adicional, cifre el almacén de secretos de Kubernetes en el clúster.

Sugerencia

SSE se recomienda para escenarios en los que sea necesario el acceso sin conexión o si necesita secretos sincronizados en el almacén de secretos de Kubernetes. Si no necesita estas características, puede usar la extensión del proveedor de secretos de Azure Key Vault para la administración de secretos en los clústeres de Kubernetes habilitados para Arc. No se recomienda ejecutar tanto la extensión de proveedor de secretos de Azure Key Vault en línea como SSE sin conexión en paralelo en un clúster.

En este artículo se muestra cómo instalar y configurar SSE como una extensión de Kubernetes habilitada para Azure Arc.

Importante

SSE está actualmente en versión preliminar. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Requisitos previos

Un clúster habilitado para Arc. Puede ser uno que haya conectado a usted mismo (los ejemplos a lo largo de esta guía usan un clúster K3s) o un clúster de AKS habilitado por Azure Arc administrado por Microsoft. El clúster debe ejecutar la versión 1.27 o superior de Kubernetes y encontrarse en una de las regiones compatibles (Este de EE. UU., Este de EE.UU. 2, Oeste de EE.UU., Oeste de EE.UU. 2, Oeste de EE.UU. 3, Oeste de Europa, Norte de Europa). La región se define mediante la región del grupo de recursos que se usa para crear el clúster de Arc.
Asegúrese de cumplir los requisitos previos generales para las extensiones de clúster, incluida la versión más reciente de la extensión de la k8s-extension CLI de Azure.
cert-manager es necesario para soportar TLS para la comunicación de registro intracluster. Los ejemplos que aparecen más adelante en esta guía le ayudarán durante la instalación. Para obtener más información sobre cert-manager, consulte cert-manager.io

Instale la CLI de Azure e inicie sesión, si aún no lo ha hecho:

az login

Antes de empezar, establezca las variables de entorno que se usarán para configurar los recursos de Azure y del clúster. Si ya tiene una identidad administrada, Azure Key Vault u otro recurso enumerado aquí, actualice los nombres de las variables de entorno para reflejar esos recursos.

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"

Activación de la federación de identidades de carga de trabajo en el clúster

El SSE usa una característica llamada federación de identidades de carga de trabajo para acceder a los secretos de Azure Key Vault y sincronizarlos. En esta sección se describe cómo configurarlo. En las secciones siguientes se explica cómo se usa con detalle.

Sugerencia

Los siguientes pasos se basan en la Guía paso a paso para configurar Kubernetes habilitado para Arc con federación de identidades de carga de trabajo. Consulte esa documentación para obtener ayuda adicional.

Si el clúster aún no está conectado a Azure Arc, siga estos pasos. Durante estos pasos, habilite la federación de identidades de carga de trabajo como parte del comando connect:

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

Si el clúster ya está conectado a Azure Arc, habilite la identidad de carga de trabajo mediante el comando update:

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

Ahora configure su clúster para emitir tokens de cuenta de servicio con una nueva dirección URL del emisor (service-account-issuer) que permita a Microsoft Entra ID encontrar las claves públicas necesarias para que pueda validar estos tokens. Estas claves públicas son para el emisor de tokens de cuenta de servicio propio del clúster y se obtuvieron y se hospedaron en la nube en esta dirección URL como resultado de la opción de --enable-oidc-issuer que estableció anteriormente.

Opcionalmente, puede configurar límites en los permisos propios de SSE como un recurso con privilegios que se ejecuta en el plano de control mediante la configuración del controlador de admisión de OwnerReferencesPermissionEnforcement. Este controlador de admisión restringe la cantidad que SSE puede cambiar otros objetos del clúster.

Configure kube-apiserver con el campo url del emisor y la aplicación de permisos. El ejemplo siguiente es para un clúster k3s. El clúster puede tener diferentes medios para cambiar los argumentos del servidor de API: --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement".
- Obtenga la dirección URL del emisor de la cuenta de servicio.
```
export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER
```
- Abra el archivo de configuración del servidor K3s.
```
sudo nano /etc/systemd/system/k3s.service
```
- Edite la configuración del servidor para que tenga un aspecto similar al ejemplo siguiente, reemplazando <SERVICE_ACCOUNT_ISSUER> por la salida anterior de echo $SERVICE_ACCOUNT_ISSUER, recordando incluir la barra diagonal final de esta dirección 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"
```

Reinicie kube-apiserver.

sudo systemctl daemon-reload
sudo systemctl restart k3s

Use la Guía paso a paso para activar la federación de identidades de carga de trabajo en AKS en Azure Local usando las marcas --enable-oidc-issuer y --enable-workload-identity.

Vuelva a estos pasos después de la activación inicial. No es necesario completar el resto de esa guía.

Valide que la activación se haya realizado correctamente obteniendo la dirección URL del emisor de la cuenta de servicio del clúster. Usará esta dirección URL en los pasos siguientes:

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

Use la Guía paso a paso para activar la federación de identidades de carga de trabajo en AKS Edge Essentials.

Vuelva a estos pasos después de la activación inicial. No es necesario completar el resto de esa guía.

Valide que la activación se haya realizado correctamente obteniendo la dirección URL del emisor de la cuenta de servicio del clúster. Usará esta dirección URL en los pasos siguientes:

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

Creación de un secreto y configuración de una identidad para su acceso

Para acceder y sincronizar un secreto de Azure Key Vault determinado, SSE requiere acceso a una identidad administrada de Azure con los permisos adecuados de Azure para acceder a ese secreto. La identidad administrada debe estar vinculada a una cuenta de servicio de Kubernetes mediante la característica de identidad de carga de trabajo que ha activado anteriormente. SSE usa la identidad administrada de Azure federada asociada para extraer secretos de Azure Key Vault en el almacén de secretos de Kubernetes. Las siguientes secciones describen cómo configurarlo.

Crear una instancia de Azure Key Vault

Crear una instancia de Azure Key Vault y agregar un secreto. Si ya tiene una instancia de Azure Key Vault y un secreto, puede omitir esta sección.

Cree un almacén de claves de Azure Key Vault:

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

Conceda permisos de "Agente de secretos" en el almacén, por lo que puede crear un secreto:

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

Cree un secreto y actualícelo para que tenga dos versiones:

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'

Creación de una identidad administrada asignada por el usuario

A continuación, cree una identidad administrada asignada por el usuario y conceda permisos para acceder a Azure Key Vault. Si ya tiene una identidad administrada con el Lector de Key Vault y los permisos de usuario de secretos de Key Vault en Azure Key Vault, puede omitir esta sección. Para más información, consulte Creación de identidades administradas asignadas por el usuario y Uso de permisos de secreto, clave y certificado de Azure RBAC con Key Vault.

Creación de la identidad administrada asignada por el usuario:

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

Conceda permisos de usuario al lector de Key Vault y a los secretos de Key Vault. Es posible que tenga que esperar un momento para la replicación de la creación de la identidad antes de que estos comandos se realicen correctamente:

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}

Creación de una credencial de identidad federada

Cree una cuenta de servicio de Kubernetes para la carga de trabajo que necesite acceso a secretos. A continuación, cree una credencial de identidad federada para vincular entre la identidad administrada, el emisor de la cuenta de servicio OIDC y la cuenta de servicio de Kubernetes.

Cree una cuenta de Servicio de Kubernetes que se federará a la identidad administrada. Anote con los detalles de la identidad administrada asignada por el usuario asociada.

kubectl create ns ${KUBERNETES_NAMESPACE}

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

Creación de una credencial de identidad federada:

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}

Instalación de SSE

SSE está disponible como una extensión de Azure Arc. Un clúster de Kubernetes habilitado para Azure Arc se puede ampliar con extensiones de Kubernetes habilitadas para Azure Arc. Las extensiones habilitan las funcionalidades de Azure en el clúster conectado y proporcionan una experiencia controlada por Azure Resource Manager para la administración del ciclo de vida y la instalación de la extensión.

cert-manager y trust-manager también son necesarios para la comunicación segura de registros entre los servicios de clúster y deben instalarse antes que la extensión de Arc.

Instale 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

Instale trust-manager.

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

Instale SSE en el clúster habilitado para Arc mediante el siguiente comando:
```
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 
```
Si lo desea, puede modificar opcionalmente el intervalo de sondeo de rotación predeterminado agregando --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds>:

Nombre de parámetro Descripción Default value

rotationPollIntervalInSeconds Especifica la rapidez con la que SSE comprueba o actualiza el secreto que administra. 3600 (1 hora)

Nombre de parámetro	Descripción	Default value
`rotationPollIntervalInSeconds`	Especifica la rapidez con la que SSE comprueba o actualiza el secreto que administra.	`3600` (1 hora)

Configuración de SSE

Configure la extensión instalada con información sobre Azure Key Vault y qué secretos se sincronizarán con el clúster mediante la definición de instancias de recursos personalizados de Kubernetes. Puede crear dos tipos de recursos personalizados:

Objeto SecretProviderClass para definir la conexión a Key Vault.
Objeto SecretSync para cada secreto que se va a sincronizar.

Crear un recurso `SecretProviderClass`

El SecretProviderClass recurso se usa para definir la conexión a Azure Key Vault, la identidad que se usará para acceder al almacén, qué secretos sincronizar y el número de versiones de cada secreto que se conservarán localmente.

Necesita un elemento independiente SecretProviderClass para cada instancia de Azure Key Vault que quiera sincronizar, para cada identidad usada para el acceso a una instancia de Azure Key Vault y para cada espacio de nombres de Kubernetes de destino.

Cree uno o varios SecretProviderClass archivos YAML con los valores adecuados para key Vault y secretos siguiendo este ejemplo.

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

Cree un objeto `SecretSync`

Cada secreto sincronizado también requiere un objeto SecretSync para definir información específica del clúster. Aquí se especifica información como el nombre del secreto en el clúster y los nombres de cada versión del secreto almacenado en el clúster.

Cree un archivo YAML de objeto SecretSync para cada secreto, siguiendo esta plantilla. El espacio de nombres de Kubernetes debe coincidir con el espacio de nombres del objeto coincidente 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

Aplique los CRs de configuración

Aplique los recursos personalizados de configuración (CSP) mediante el kubectl apply comando:

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

SSE busca automáticamente los secretos y comienza a sincronizarlos con el clúster.

Opciones de configuración de tareas

Para ver opciones de configuración adicionales para estos dos tipos de recursos personalizados, use el kubectl describe comando para inspeccionar los CRD del clúster:

# 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

Observación de secretos que se sincronizan con el clúster

Una vez aplicada la configuración, los secretos comienzan a sincronizarse con el clúster automáticamente en la cadencia especificada al instalar SSE.

Visualización de secretos sincronizados

Para ver los secretos sincronizados con el clúster, ejecute el siguiente comando:

# 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

Ver el estado de la última sincronización

Para ver el estado de la sincronización más reciente de un secreto determinado, use el kubectl describe comando para el SecretSync objeto. La salida incluye la marca de tiempo de creación de secretos, las versiones del secreto y los mensajes de estado detallados para cada evento de sincronización. Esta salida se puede usar para diagnosticar errores de conexión o configuración y observar cuándo cambia el valor del secreto.

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

Visualización de valores de secretos

Para ver los valores de secreto sincronizados, ahora almacenados en el almacén de secretos de Kubernetes, use el siguiente comando:

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

Solución de problemas

SSE es una implementación de Kubernetes que contiene un pod con dos contenedores: el controlador, que administra el almacenamiento de secretos en el clúster y el proveedor, que administra el acceso y extrae secretos de Azure Key Vault. Cada secreto sincronizado tiene un objeto SecretSync que contiene el estado de la sincronización de ese secreto de Azure Key Vault al almacén de secretos del clúster.

Para solucionar un problema, empiece por examinar el estado del objeto SecretSync, tal como se describe en Ver el estado de la última sincronización. En la tabla siguiente se enumeran los tipos de estado comunes, sus significados y los posibles pasos de solución de problemas para resolver errores.

Tipo de estado SecretSync	Detalles	Pasos para corregir o investigar más a fondo
`CreateSucceeded`	El secreto se creó correctamente.	N/D
`CreateFailedProviderError`	Error en la creación de secretos debido a algún problema con el proveedor (conexión a Azure Key Vault). Este error podría deberse a la conectividad a Internet, permisos insuficientes para los secretos de sincronización de identidades, configuración incorrecta de `SecretProviderClass`, u otros problemas.	Investigue aún más examinando los registros del proveedor mediante los siguientes comandos: `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'`
`CreateFailedInvalidLabel`	Error en la creación del secreto porque el secreto ya existe sin la etiqueta correcta de Kubernetes que SSE usa para administrar sus secretos.	Quite la etiqueta y el secreto existentes y permita que SSE vuelva a crear el secreto: `kubectl delete secret <secret-name>` Para forzar que SSE vuelva a crear el secreto más rápido que el intervalo de sondeo de rotación configurado, elimine el `SecretSync` objeto (`kubectl delete secretsync <secret-name>`) y vuelva a aplicar la clase de sincronización de secretos (`kubectl apply -f <path_to_secret_sync>`).
`CreateFailedInvalidAnnotation`	Error en la creación de secretos porque el secreto ya existe sin la anotación correcta de Kubernetes que SSE usa para administrar sus secretos.	Quite la anotación y el secreto existentes y permita que SSE vuelva a crear el secreto: `kubectl delete secret <secret-name>` Para forzar que SSE vuelva a crear el secreto más rápido que el intervalo de sondeo de rotación configurado, elimine el `SecretSync` objeto (`kubectl delete secretsync <secret-name>`) y vuelva a aplicar la clase de sincronización de secretos (`kubectl apply -f <path_to_secret_sync>`).
`UpdateNoValueChangeSucceeded`	El SSE ha comprobado Azure Key Vault para ver las actualizaciones al final del intervalo de sondeo configurado, pero no se han producido cambios en la sincronización.	N/D
`UpdateValueChangeOrForceUpdateSucceeded`	SSE ha comprobado Azure Key Vault para ver las actualizaciones y ha actualizado correctamente el valor.	N/D
`UpdateFailedInvalidLabel`	Error en la actualización del secreto porque se modificó la etiqueta del secreto que usa SSE para administrar sus secretos.	Quite la etiqueta y el secreto existentes y permita que SSE vuelva a crear el secreto: `kubectl delete secret <secret-name>` Para forzar que SSE vuelva a crear el secreto más rápido que el intervalo de sondeo de rotación configurado, elimine el `SecretSync` objeto (`kubectl delete secretsync <secret-name>`) y vuelva a aplicar la clase de sincronización de secretos (`kubectl apply -f <path_to_secret_sync>`).
`UpdateFailedInvalidAnnotation`	Error en la actualización del secreto porque se modificó la anotación en el secreto que usa SSE para administrar sus secretos.	Quite la anotación y el secreto existentes y permita que SSE vuelva a crear el secreto: `kubectl delete secret <secret-name>` Para forzar que SSE vuelva a crear el secreto más rápido que el intervalo de sondeo de rotación configurado, elimine el `SecretSync` objeto (`kubectl delete secretsync <secret-name>`) y vuelva a aplicar la clase de sincronización de secretos (`kubectl apply -f <path_to_secret_sync>`).
`UpdateFailedProviderError`	Error en la actualización del secreto debido a algún problema con el proveedor (conexión a Azure Key Vault). Este error podría deberse a la conectividad a Internet, permisos insuficientes para los secretos de sincronización de identidades, la configuración de `SecretProviderClass` u otros problemas.	Investigue aún más examinando los registros del proveedor mediante los siguientes comandos: `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'`
`UserInputValidationFailed`	Error en la actualización del secreto porque la clase de sincronización de secretos se configuró incorrectamente (por ejemplo, un tipo de secreto no válido).	Revise la definición de la clase de sincronización secreta y corrija los errores. A continuación, elimine el `SecretSync` objeto (`kubectl delete secretsync <secret-name>`), elimine la clase de sincronización secreta (`kubectl delete -f <path_to_secret_sync>`) y vuelva a aplicar la clase de sincronización de secretos (`kubectl apply -f <path_to_secret_sync>`).
`ControllerSpcError`	Error en la actualización del secreto porque SSE no pudo obtener la clase de proveedor o la clase de proveedor está mal configurada.	Revise la clase de proveedor y corrija los errores. A continuación, elimine el `SecretSync` objeto (`kubectl delete secretsync <secret-name>`), elimine la clase de proveedor (`kubectl delete -f <path_to_provider>`) y vuelva a aplicar la clase de proveedor (`kubectl apply -f <path_to_provider>`).
`ControllerInternalError`	Error en la actualización del secreto debido a un error interno en SSE.	Compruebe los registros de SSE o los eventos para obtener más información: `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager'`
`SecretPatchFailedUnknownError`	Error en la actualización del secreto durante la revisión del valor del secreto de Kubernetes. Este error puede producirse si alguien que no sea SSE modificó el secreto o si se produjeron problemas durante una actualización de SSE.	Intente eliminar el secreto y el objeto `SecretSync` y, a continuación, deje que SSE vuelva a crear el secreto mediante la nueva aplicación de la CR de sincronización de secretos: `kubectl delete secret <secret-name>` `kubectl delete secretsync <secret-name>` `kubectl apply -f <path_to_secret_sync>`

Quitar SSE

Para quitar SSE y detener la sincronización de secretos, desinstálelo con el comando az k8s-extension delete:

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

La desinstalación de la extensión no quita secretos, SecretSync objetos ni CRD del clúster. Estos objetos se deben quitar directamente con kubectl.

Al eliminar la CRD de SecretSync, se quitan todos los SecretSync objetos y, de forma predeterminada, se quitan todos los secretos de propiedad, pero los secretos pueden persistir si:

Ha modificado la propiedad de cualquiera de los secretos.
Ha cambiado la configuración de recolección de elementos no utilizados en el clúster, incluido el establecimiento de distintos finalizadores.

En los casos anteriores, los secretos se deben eliminar directamente mediante kubectl.

Pasos siguientes

Más información sobre las extensiones de Azure Arc.
Obtenga más información sobre Azure Key Vault.

Compartir a través de

Uso de la extensión Secret Store para capturar secretos para el acceso sin conexión en clústeres de Kubernetes habilitados para Azure Arc

Requisitos previos

Activación de la federación de identidades de carga de trabajo en el clúster

Creación de un secreto y configuración de una identidad para su acceso

Crear una instancia de Azure Key Vault

Creación de una identidad administrada asignada por el usuario

Creación de una credencial de identidad federada

Instalación de SSE

Configuración de SSE

Crear un recurso `SecretProviderClass`

Cree un objeto `SecretSync`

Aplique los CRs de configuración

Opciones de configuración de tareas

Observación de secretos que se sincronizan con el clúster

Visualización de secretos sincronizados

Ver el estado de la última sincronización

Visualización de valores de secretos

Solución de problemas

Quitar SSE

Pasos siguientes

Comentarios

Recursos adicionales

Compartir a través de

Uso de la extensión Secret Store para capturar secretos para el acceso sin conexión en clústeres de Kubernetes habilitados para Azure Arc

Requisitos previos

Activación de la federación de identidades de carga de trabajo en el clúster

Creación de un secreto y configuración de una identidad para su acceso

Crear una instancia de Azure Key Vault

Creación de una identidad administrada asignada por el usuario

Creación de una credencial de identidad federada

Instalación de SSE

Configuración de SSE

Crear un recurso SecretProviderClass

Cree un objeto SecretSync

Aplique los CRs de configuración

Opciones de configuración de tareas

Observación de secretos que se sincronizan con el clúster

Visualización de secretos sincronizados

Ver el estado de la última sincronización

Visualización de valores de secretos

Solución de problemas

Quitar SSE

Pasos siguientes

Comentarios

Recursos adicionales

Crear un recurso `SecretProviderClass`

Cree un objeto `SecretSync`