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

Artikulua
09/29/2024

La extensión Almacén secreto de Azure Key Vault para Kubernetes ("Almacén secreto") 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 secret Store 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

La extensión Secret Store 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 la extensión del almacén de secretos sin conexión en paralelo en un clúster.

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

Importante

El almacén de secretos se encuentra 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 conectado a Azure Arc, que ejecuta kubernetes versión 1.27 o posterior, y en una de las regiones admitidas (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.
En los ejemplos de esta guía se usa un clúster K3s.
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

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.

az login
export RESOURCE_GROUP="oidc-issuer"
export LOCATION="westus2"
export AZURE_STORAGE_ACCOUNT="oidcissuer$(openssl rand -hex 4)"
export AZURE_STORAGE_CONTAINER="oidc-test"
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 ad signed-in-user show --query userPrincipalName --output tsv)"
export KEYVAULT_NAME="azwi-kv-$(openssl rand -hex 4)"
export KEYVAULT_SECRET_NAME="my-secret"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
az account set --subscription "${SUBSCRIPTION}"
export SERVICE_ACCOUNT_ISSUER="https://$AZURE_STORAGE_ACCOUNT.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"
export KUBERNETES_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"

Configuración de una identidad para acceder a secretos

Para acceder y sincronizar un secreto de Azure Key Vault determinado, el almacén de secretos 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 a través de la federación. La cuenta de servicio de Kubernetes es lo que se usa en un pod de Kubernetes u otra carga de trabajo para acceder a secretos desde el almacén de secretos de Kubernetes. La extensión Secret Store 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.

Hospedar información pública de OIDC sobre el emisor de la cuenta de servicio del clúster

Actualmente, el uso de la identidad federada requiere configurar el almacenamiento en la nube para hospedar información de formato OIDC sobre las claves públicas del emisor de la cuenta de servicio del clúster. En esta sección, configurará una dirección URL del emisor de Open ID Connect (OIDC) pública protegida mediante Azure Blob Storage y, a continuación, cargará un documento de detección mínimo en la cuenta de almacenamiento. Para más información, consulte Configuración de OIDC para clústeres autoadministrados.

Creación de una cuenta de almacenamiento de Azure.
```
az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"
az storage account create --resource-group "${RESOURCE_GROUP}" --name "${AZURE_STORAGE_ACCOUNT}" --allow-blob-public-access true
az storage container create --name "${AZURE_STORAGE_CONTAINER}" --public-access blob
```
Nota:

Es posible que se produzca un error en "az storage account create" si la instancia de Azure no ha habilitado el servicio "Microsoft.Storage". Si se produce un error, registre el proveedor de recursos Microsoft.Storage en su suscripción.

Genere un documento de detección. Cárguelo en la cuenta de almacenamiento y compruebe que es accesible públicamente.

cat <<EOF > openid-configuration.json
{
  "issuer": "https://${AZURE_STORAGE_ACCOUNT}.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}/",
  "jwks_uri": "https://${AZURE_STORAGE_ACCOUNT}.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}/openid/v1/jwks",
  "response_types_supported": [
    "id_token"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ]
}
EOF

az storage blob upload --container-name "${AZURE_STORAGE_CONTAINER}" --file openid-configuration.json --name .well-known/openid-configuration
curl -s "https://${AZURE_STORAGE_ACCOUNT}.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}/.well-known/openid-configuration"

Obtenga la clave pública del emisor de la cuenta de servicio del clúster de su clave privada. Es probable que tenga que ejecutar este comando como superusuario. El siguiente ejemplo es para k3s. El clúster puede almacenar la clave privada del emisor de la cuenta de servicio en otra ubicación.
```
sudo openssl rsa -in /var/lib/rancher/k3s/server/tls/service.key -pubout -out sa.pub
```
Descargue la herramienta de línea de comandos azwi más reciente, que puede usar para crear un documento JWKS a partir de la clave pública y destarlo:
```
tar -xzf <path to downloaded azwi tar.gz>
```

Genere el documento JWKS. Cárguelo en la cuenta de almacenamiento y compruebe que es accesible públicamente.

./azwi jwks --public-keys sa.pub --output-file jwks.json
az storage blob upload --container-name "${AZURE_STORAGE_CONTAINER}" --file jwks.json --name openid/v1/jwks
curl -s "https://${AZURE_STORAGE_ACCOUNT}.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}/openid/v1/jwks"

Configuración del emisor del token de cuenta de servicio del clúster con la dirección URL hospedada

El clúster también debe configurarse para emitir tokens de cuenta de servicio con un campo de dirección URL del emisor (service-account-issuer) que apunte a la cuenta de almacenamiento que creó en la sección anterior. Para obtener más información sobre la configuración de federación, consulte Configuración del clúster para un emisor de OIDC.

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

El clúster de Kubernetes debe ejecutar la versión 1.27 o posterior de Kubernetes.

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.
```
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 de echo $SERVICE_ACCOUNT_ISSUER.
```
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

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 y uso del almacén de secretos

Secret Store 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.

Secret Store se instala como una extensión de Azure Arc

Instalación de cert-manager y trust-manager

cert-manager y trust-manager 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.

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml

Instale trust-manager.

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait

Instalación de la extensión de Azure Arc de Secret Store

Asegúrese de que el clúster de Kubernetes está conectado a Azure Arc antes de instalar la extensión.

Establezca dos variables de entorno para el grupo de recursos y el nombre del clúster conectado. Si ha seguido el inicio rápido vinculado anteriormente, estos son "AzureArcTest" y "AzureArcTest1", respectivamente.
```
export ARC_RESOURCE_GROUP="AzureArcTest"
export ARC_CLUSTER_NAME="AzureArcTest1"
```

Instale la extensión Secret Store en el clúster habilitado para Arc mediante el siguiente comando:

az k8s-extension create \
  --cluster-name ${ARC_CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --extension-type microsoft.azure.secretstore \
  --resource-group ${ARC_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 el Almacén de secretos comprueba o actualiza el secreto que administra.	`3600` (1 hora)

Configuración del almacén de secretos

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

El almacén de secretos 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 el almacén de secretos.

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

El almacén de secretos 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 el almacén de secretos usa para administrar sus secretos.	Quite la etiqueta y el secreto existentes y permita que el almacén de secretos vuelva a crear el secreto: `kubectl delete secret <secret-name>` Para forzar que el almacén de secretos 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 el almacén de secretos usa para administrar sus secretos.	Quite la anotación y el secreto existentes y permita que el almacén de secretos vuelva a crear el secreto: `kubectl delete secret <secret-name>` Para forzar que el almacén de secretos 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 Almacén de secretos 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`	El almacén de secretos 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 el Almacén de secretos para administrar sus secretos.	Quite la etiqueta y el secreto existentes y permita que el almacén de secretos vuelva a crear el secreto: `kubectl delete secret <secret-name>` Para forzar que el almacén de secretos 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 el Almacén de secretos para administrar sus secretos.	Quite la anotación y el secreto existentes y permita que el almacén de secretos vuelva a crear el secreto: `kubectl delete secret <secret-name>` Para forzar que el almacén de secretos 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 el almacén de secretos 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 el almacén de secretos.	Compruebe los registros del Almacén secreto 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 el Almacén de secretos modificó el secreto o si se produjeron problemas durante una actualización del almacén de secretos.	Intente eliminar el secreto y el objeto `SecretSync` y, a continuación, deje que el almacén de secretos 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>`

Eliminación del almacén de secretos

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

az k8s-extension delete --name ssarcextension --cluster-name $ARC_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.

Partekatu honen bidez:

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

Configuración de una identidad para acceder a secretos

Hospedar información pública de OIDC sobre el emisor de la cuenta de servicio del clúster

Configuración del emisor del token de cuenta de servicio del clúster con la dirección URL hospedada

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 y uso del almacén de secretos

Instalación de cert-manager y trust-manager

Instalación de la extensión de Azure Arc de Secret Store

Configuración del almacén de secretos

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

Eliminación del almacén de secretos

Pasos siguientes

Oharrak

Baliabide gehigarriak

Partekatu honen bidez:

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

Configuración de una identidad para acceder a secretos

Hospedar información pública de OIDC sobre el emisor de la cuenta de servicio del clúster

Configuración del emisor del token de cuenta de servicio del clúster con la dirección URL hospedada

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 y uso del almacén de secretos

Instalación de cert-manager y trust-manager

Instalación de la extensión de Azure Arc de Secret Store

Configuración del almacén de secretos

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

Eliminación del almacén de secretos

Pasos siguientes

Oharrak

Baliabide gehigarriak

Crear un recurso `SecretProviderClass`

Cree un objeto `SecretSync`