Partilhar via

Usar a extensão Secret Store para buscar segredos para acesso offline em clusters Kubernetes habilitados para Azure Arc

  • Artigo

A extensão do Repositório Secreto do Cofre de Chaves do Azure para Kubernetes ("SSE") sincroniza automaticamente segredos de um Cofre de Chaves do Azure para um cluster Kubernetes habilitado para Azure Arc para acesso offline. Isso significa que você pode usar o Azure Key Vault para armazenar, manter e girar seus segredos, mesmo ao executar seu cluster Kubernetes em um estado semidesconectado. Os segredos sincronizados são armazenados no armazenamento secreto do cluster, tornando-os disponíveis como segredos do Kubernetes para serem usados de todas as maneiras usuais: montados como volumes de dados ou expostos como variáveis de ambiente a um contêiner em um pod.

Os segredos sincronizados são ativos de negócios críticos, portanto, o SSE os protege por meio de namespaces e nós isolados, políticas RBAC (controle de acesso baseado em função) e permissões limitadas para o sincronizador de segredos. Para proteção extra, criptografe o armazenamento secreto do Kubernetes em seu cluster.

Gorjeta

O SSE é recomendado para cenários em que o acesso offline é necessário ou se você precisar de segredos sincronizados no repositório secreto do Kubernetes. Se você não precisar desses recursos, poderá usar a extensão Azure Key Vault Secrets Provider para gerenciamento de segredos em seus clusters Kubernetes habilitados para Arc. Não é recomendável executar a extensão online do Provedor de Segredos do Cofre de Chaves do Azure e o SSE offline lado a lado em um cluster.

Este artigo mostra como instalar e configurar o SSE como uma extensão do Kubernetes habilitada para Azure Arc.

Importante

O SSE está atualmente em pré-visualização. Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançadas para disponibilidade geral.

Pré-requisitos

  • Um cluster habilitado para Arc. Pode ser um que você conectou a si mesmo (os exemplos ao longo deste guia usam um cluster K3s ) ou um AKS gerenciado pela Microsoft habilitado pelo cluster Azure Arc . O cluster deve estar executando o Kubernetes versão 1.27 ou superior e em uma das regiões suportadas (Leste dos EUA, Leste US2, Oeste dos EUA, Oeste dos EUA2, Oeste US3, Europa Ocidental, Europa do Norte). A região é definida pela região do grupo de recursos usada para criar o cluster Arc.
  • Certifique-se de atender aos pré-requisitos gerais para extensões de cluster, incluindo a versão mais recente da k8s-extension extensão CLI do Azure.
  • cert-manager é necessário para suportar TLS para comunicação de log intracluster. Os exemplos mais adiante neste guia direcionam você através da instalação. Para obter mais informações sobre cert-manager, consulte cert-manager.io

Instale a CLI do Azure e entre, se ainda não tiver entrado:

az login

Antes de começar, defina as variáveis de ambiente a serem usadas para configurar o Azure e os recursos de cluster. Se você já tiver uma identidade gerenciada, o Cofre da Chave do Azure ou outro recurso listado aqui, atualize os nomes nas variáveis de ambiente para refletir esses 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"

Ativar a federação de identidades de carga de trabalho em seu cluster

O SSE usa um recurso chamado federação de identidade de carga de trabalho para acessar e sincronizar segredos do Azure Key Vault. Esta seção descreve como configurar isso. As seções a seguir explicarão como ele é usado em detalhes.

Gorjeta

As etapas a seguir são baseadas no guia de instruções para configurar o Kubernetes habilitado para Arc com federação de identidade de carga de trabalho. Consulte essa documentação para obter assistência adicional.

Se o cluster ainda não estiver conectado ao Azure Arc, siga estas etapas. Durante estas etapas, habilite a federação de identidades de carga de trabalho como parte do connect comando:

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

Se o cluster já estiver conectado ao Azure Arc, habilite a identidade da carga de trabalho usando o update comando:

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

Agora, configure seu cluster para emitir tokens de Conta de Serviço com uma nova URL de emissor (service-account-issuer) que permita que o Microsoft Entra ID encontre as chaves públicas necessárias para validar esses tokens. Essas chaves públicas são para o próprio emissor de token de conta de serviço do cluster e foram obtidas e hospedadas na nuvem nessa URL como resultado da --enable-oidc-issuer opção definida acima.

Opcionalmente, você também pode configurar limites nas próprias permissões do SSE como um recurso privilegiado em execução no plano de controle configurando OwnerReferencesPermissionEnforcement o controlador de admissão. Esse controlador de admissão restringe o quanto o SSE pode alterar outros objetos no cluster.

  1. Configure seu kube-apiserver com o campo URL do emissor e imposição de permissões. O exemplo a seguir é para um cluster k3s. Seu cluster pode ter diferentes meios para alterar os argumentos do servidor de API: --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement".

    • Obtenha o URL do emissor da conta de serviço.

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

    • Abra o arquivo de configuração do servidor K3s.

      sudo nano /etc/systemd/system/k3s.service

    • Edite a configuração do servidor para se parecer com o exemplo a seguir, substituindo <SERVICE_ACCOUNT_ISSUER pela saída acima de , lembrando-se> de echo $SERVICE_ACCOUNT_ISSUERincluir a barra à direita desta 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"

  2. Reinicie seu kube-apiserver.

    sudo systemctl daemon-reload
sudo systemctl restart k3s

Criar um segredo e configurar uma identidade para acessá-lo

Para acessar e sincronizar um determinado segredo do Cofre da Chave do Azure, o SSE requer acesso a uma identidade gerenciada do Azure com permissões apropriadas do Azure para acessar esse segredo. A identidade gerenciada deve ser vinculada a uma conta de serviço do Kubernetes usando o recurso de identidade de carga de trabalho que você ativou acima. O SSE usa a identidade gerenciada federada associada do Azure para extrair segredos do Cofre da Chave do Azure para seu repositório secreto do Kubernetes. As seções a seguir descrevem como configurar isso.

Criar um Azure Key Vault

Crie um Cofre da Chave do Azure e adicione um segredo. Se já tiver um Cofre da Chave do Azure e um segredo, pode ignorar esta secção.

  1. Crie um Cofre da Chave do Azure:

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

  2. Dê a si mesmo permissões de 'Oficial de Segredos' no cofre, para que você possa criar um segredo:

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

  3. Crie um segredo e atualize-o para ter duas versões:

    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'

Criar uma identidade gerida atribuída pelo utilizador

Em seguida, crie uma identidade gerenciada atribuída pelo usuário e conceda a ela permissões para acessar o Cofre da Chave do Azure. Se já tiver uma identidade gerida com as permissões de Utilizador do Key Vault Reader e Key Vault Secrets para o Azure Key Vault, pode ignorar esta secção. Para obter mais informações, consulte Criar identidades gerenciadas atribuídas pelo usuário e Usando permissões de segredo, chave e certificado do RBAC do Azure com o Cofre da Chave.

  1. Crie a identidade gerenciada atribuída pelo usuário:

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

  2. Dê à identidade Key Vault Reader e Key Vault Secrets permissões de usuário. Talvez seja necessário aguardar um momento para a replicação da criação de identidade antes que esses comandos sejam bem-sucedidos:

    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}

Criar uma credencial de identidade federada

Crie uma conta de serviço Kubernetes para a carga de trabalho que precisa de acesso a segredos. Em seguida, crie uma credencial de identidade federada para vincular entre a identidade gerenciada, o emissor da conta de serviço OIDC e a conta de serviço do Kubernetes.

  1. Crie uma conta de serviço do Kubernetes que será federada à identidade gerenciada. Anote-o com detalhes da identidade gerenciada atribuída pelo usuário associada.

    kubectl create ns ${KUBERNETES_NAMESPACE}

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

  2. Crie uma credencial de identidade 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}

Instalar o SSE

O SSE está disponível como uma extensão do Azure Arc. Um cluster do Kubernetes habilitado para Azure Arc pode ser estendido com extensões do Kubernetes habilitadas para Azure Arc. As extensões habilitam os recursos do Azure em seu cluster conectado e fornecem uma experiência orientada pelo Azure Resource Manager para a instalação da extensão e o gerenciamento do ciclo de vida.

cert-manager e trust-manager também são necessários para a comunicação segura de logs entre serviços de cluster e devem ser instalados antes da extensão Arc.

  1. Instale o 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

  2. Instale o gerenciador de confiança.

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

  3. Instale o SSE em seu cluster habilitado para Arc usando o seguinte 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

    Se desejar, você pode, opcionalmente, modificar o intervalo de sondagem de rotação padrão adicionando --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds>:

    Nome do parâmetro Description Default value
    rotationPollIntervalInSeconds Especifica a rapidez com que o SSE verifica ou atualiza o segredo que está gerenciando. 3600 (1 hora)

Configurar o SSE

Configure a extensão instalada com informações sobre seu Cofre de Chaves do Azure e quais segredos sincronizar com seu cluster definindo instâncias de recursos personalizados do Kubernetes. Você cria dois tipos de recursos personalizados:

  • Um SecretProviderClass objeto para definir a conexão com o Cofre da Chave.
  • Um SecretSync objeto para cada segredo a ser sincronizado.

Criar um SecretProviderClass recurso

O SecretProviderClass recurso é usado para definir a conexão com o Cofre de Chaves do Azure, a identidade a ser usada para acessar o cofre, quais segredos sincronizar e o número de versões de cada segredo a serem mantidas localmente.

Você precisa de um separado SecretProviderClass para cada Cofre de Chaves do Azure que pretende sincronizar, para cada identidade usada para acessar um Cofre de Chaves do Azure e para cada namespace Kubernetes de destino.

Crie um ou mais SecretProviderClass arquivos YAML com os valores apropriados para seu Cofre de Chaves e segredos seguindo este exemplo.

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

Criar um SecretSync objeto

Cada segredo sincronizado também requer um SecretSync objeto para definir informações específicas do cluster. Aqui você especifica informações como o nome do segredo no cluster e nomes para cada versão do segredo armazenado no cluster.

Crie um SecretSync arquivo YAML de objeto para cada segredo, seguindo este modelo. O namespace do Kubernetes deve corresponder ao namespace do namespace correspondente 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

Aplicar as CRs de configuração

Aplique os recursos personalizados de configuração (CRs) usando o kubectl apply comando:

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

O SSE procura automaticamente os segredos e começa a sincronizá-los com o cluster.

Ver opções de configuração

Para exibir opções de configuração adicionais para esses dois tipos de recursos personalizados, use o kubectl describe comando para inspecionar os CRDs no cluster:

# 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

Observe os segredos sincronizados com o cluster

Depois que a configuração é aplicada, os segredos começam a ser sincronizados com o cluster automaticamente na cadência especificada durante a instalação do SSE.

Ver segredos sincronizados

Exiba os segredos sincronizados com o cluster executando o seguinte 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 estado da última sincronização

Para exibir o status da sincronização mais recente de um determinado segredo, use o kubectl describe comando para o SecretSync objeto. A saída inclui o carimbo de data/hora de criação secreto, as versões do segredo e mensagens de status detalhadas para cada evento de sincronização. Essa saída pode ser usada para diagnosticar erros de conexão ou configuração e para observar quando o valor secreto muda.

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

Ver valores de segredos

Para exibir os valores secretos sincronizados, agora armazenados no repositório secreto do Kubernetes, use o seguinte 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

Resolução de Problemas

O SSE é uma implantação do Kubernetes que contém um pod com dois contêineres: o controlador, que gerencia o armazenamento de segredos no cluster, e o provedor, que gerencia o acesso e a extração de segredos do Cofre de Chaves do Azure. Cada segredo sincronizado tem um SecretSync objeto que contém o status da sincronização desse segredo do Cofre da Chave do Azure para o armazenamento secreto do cluster.

Para solucionar um problema, comece examinando o SecretSync estado do objeto, conforme descrito em Exibir status da última sincronização. A tabela a seguir lista tipos de status comuns, seus significados e possíveis etapas de solução de problemas para resolver erros.

Tipo de status SecretSync Detalhes Passos para corrigir/investigar mais
CreateSucceeded O segredo foi criado com sucesso. n/d
CreateFailedProviderError A criação de segredos falhou devido a algum problema com o provedor (conexão com o Cofre de Chaves do Azure). Essa falha pode ser devido à conectividade com a Internet, permissões insuficientes para os segredos de sincronização de identidade, configuração incorreta do SecretProviderClass, ou outros problemas. Investigue mais observando os logs do provedor usando os seguintes comandos:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'
CreateFailedInvalidLabel A criação do segredo falhou porque o segredo já existe sem o rótulo Kubernetes correto que o SSE usa para gerenciar seus segredos. Remova o rótulo e o segredo existentes e permita que o SSE recrie o segredo: kubectl delete secret <secret-name>
Para forçar o SSE a recriar o segredo mais rápido do que o intervalo de sondagem de rotação configurado, exclua o SecretSync objeto (kubectl delete secretsync <secret-name>) e reaplique a classe de sincronização secreta (kubectl apply -f <path_to_secret_sync>).
CreateFailedInvalidAnnotation A criação do segredo falhou porque o segredo já existe sem a anotação correta do Kubernetes que o SSE usa para gerenciar seus segredos. Remova a anotação e o segredo existentes e permita que o SSE recrie o segredo: kubectl delete secret <secret-name>
Para forçar o SSE a recriar o segredo mais rápido do que o intervalo de sondagem de rotação configurado, exclua o SecretSync objeto (kubectl delete secretsync <secret-name>) e reaplique a classe de sincronização secreta (kubectl apply -f <path_to_secret_sync>).
UpdateNoValueChangeSucceeded O SSE verificou o Azure Key Vault em busca de atualizações no final do intervalo de sondagem configurado, mas não houve alterações na sincronização. n/d
UpdateValueChangeOrForceUpdateSucceeded O SSE verificou o Azure Key Vault em busca de atualizações e atualizou com êxito o valor. n/d
UpdateFailedInvalidLabel A atualização secreta falhou porque o rótulo no segredo que o SSE usa para gerenciar seus segredos foi modificado. Remova o rótulo e o segredo existentes e permita que o SSE recrie o segredo: kubectl delete secret <secret-name>
Para forçar o SSE a recriar o segredo mais rápido do que o intervalo de sondagem de rotação configurado, exclua o SecretSync objeto (kubectl delete secretsync <secret-name>) e reaplique a classe de sincronização secreta (kubectl apply -f <path_to_secret_sync>).
UpdateFailedInvalidAnnotation A atualização secreta falhou porque a anotação no segredo que o SSE usa para gerenciar seus segredos foi modificada. Remova a anotação e o segredo existentes e permita que o SSE recrie o segredo: kubectl delete secret <secret-name>
Para forçar o SSE a recriar o segredo mais rápido do que o intervalo de sondagem de rotação configurado, exclua o SecretSync objeto (kubectl delete secretsync <secret-name>) e reaplique a classe de sincronização secreta (kubectl apply -f <path_to_secret_sync>).
UpdateFailedProviderError A atualização secreta falhou devido a algum problema com o provedor (conexão com o Cofre da Chave do Azure). Essa falha pode ser devido à conectividade com a Internet, permissões insuficientes para os segredos de sincronização de identidade, configuração do SecretProviderClassou outros problemas. Investigue mais observando os logs do provedor usando os seguintes comandos:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'
UserInputValidationFailed A atualização secreta falhou porque a classe de sincronização secreta foi configurada incorretamente (como um tipo de segredo inválido). Revise a definição de classe de sincronização secreta e corrija quaisquer erros. Em seguida, exclua o SecretSync objeto (kubectl delete secretsync <secret-name>), exclua a classe de sincronização secreta (kubectl delete -f <path_to_secret_sync>) e reaplique a classe de sincronização secreta (kubectl apply -f <path_to_secret_sync>).
ControllerSpcError A atualização secreta falhou porque o SSE não conseguiu obter a classe de provedor ou a classe de provedor está configurada incorretamente. Revise a classe do provedor e corrija quaisquer erros. Em seguida, exclua o SecretSync objeto (kubectl delete secretsync <secret-name>), exclua a classe de provedor (kubectl delete -f <path_to_provider>) e reaplique a classe de provedor (kubectl apply -f <path_to_provider>).
ControllerInternalError A atualização secreta falhou devido a um erro interno no SSE. Verifique os logs SSE ou os eventos para obter mais informações:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager'
SecretPatchFailedUnknownError A atualização secreta falhou durante a aplicação de patches no valor secreto do Kubernetes. Essa falha pode ocorrer se o segredo foi modificado por alguém que não seja o SSE ou se houver problemas durante uma atualização do SSE. Tente excluir o segredo e SecretSync o objeto e, em seguida, deixe o SSE recriar o segredo reaplicando a CR de sincronização secreta:
kubectl delete secret <secret-name>
kubectl delete secretsync <secret-name>
kubectl apply -f <path_to_secret_sync>

Remover o SSE

Para remover o SSE e parar de sincronizar segredos, desinstale-o com o az k8s-extension delete comando:

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

A desinstalação da extensão não remove segredos, SecretSync objetos ou CRDs do cluster. Esses objetos devem ser removidos diretamente com kubectlo .

A exclusão do CRD SecretSync remove todos os SecretSync objetos e, por padrão, remove todos os segredos de propriedade, mas os segredos podem persistir se:

Nos casos acima, os segredos devem ser excluídos diretamente usando kubectlo .

Próximos passos