Usar o operador de secrets externos

Nesta página, descrevemos como usar o operador de secrets externos (ESO, na sigla em inglês) para sincronizar secrets do Secret Manager com seus clusters conectados do Google Distributed Cloud.

O External Secrets Operator é um operador do Kubernetes de código aberto que integra sistemas externos de gerenciamento de secrets. O operador lê informações de APIs externas e injeta automaticamente os valores em um secret do Kubernetes.

Pré-requisitos

Antes de usar o operador External Secrets, faça o seguinte:

  • Crie um cluster conectado do Distributed Cloud funcional.
  • Verifique se as APIs a seguir estão ativadas no seu Google Cloud projeto. Para informações sobre como ativar APIs, consulte Como ativar serviços:
    • secretmanager.googleapis.com
    • iamcredentials.googleapis.com

  • Verifique se você tem as seguintes ferramentas de linha de comando instaladas:

    • A versão mais recente da Google Cloud CLI, que inclui gcloud, a ferramenta de linha de comando para interagir com Google Cloud.
    • kubectl

    Se você estiver usando o Cloud Shell como ambiente shell para interagir com Google Cloud, essas ferramentas estarão instaladas.

  • Verifique se você inicializou a CLI gcloud para usar com seu projeto.

  • Ative a federação de identidade da carga de trabalho no cluster. O pool de Identidade da carga de trabalho fica disponível automaticamente e segue o formato PROJECT_ID.svc.id.goog.

  • Instale o operador External Secrets no cluster. Para instruções de instalação, consulte a documentação do operador External Secrets. Recomendamos instalar o operador em um namespace dedicado, como external-secrets. Não instale em namespaces gerenciados pelo sistema, como kube-system ou gke-system.

Os clusters conectados do Distributed Cloud são registrados automaticamente em uma frota no projeto em que são criados.

Autenticação

O operador External Secrets exige autenticação para acessar o Secret Manager. O Distributed Cloud Connected usa a federação de identidade da carga de trabalho da frota para permitir que as cargas de trabalho se autentiquem nas APIs doGoogle Cloud .

Para configurar a autenticação do operador de secrets externos:

  1. Configure a relação de confiança entre o cluster e Google Cloud seguindo as instruções em Autenticação de cluster da Identidade da carga de trabalho.
  2. Verifique se a conta de serviço do Google usada pelo operador de secrets externos tem o papel Acessador de secrets do Secret Manager (roles/secretmanager.secretAccessor) nos secrets que você quer acessar.

  3. Configure o pod do operador External Secrets para usar a federação de identidade da carga de trabalho seguindo as instruções de Configurar a carga de trabalho.

    A maioria dos clientes usa a federação de identidade da carga de trabalho para autenticação. Para configurar a federação de identidade da carga de trabalho, anote a ServiceAccount do Kubernetes usada pelo operador com a conta de serviço do Google. Para adicionar essa anotação, execute o comando kubectl annotate:

    kubectl annotate serviceaccount KSA_NAME \
    --namespace OPERATOR_NAMESPACE \
    iam.gke.io/gcp-service-account=GSA_EMAIL

    Como alternativa, adicione a anotação ao YAML da ServiceAccount:

    apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: GSA_EMAIL
  name: KSA_NAME
  namespace: OPERATOR_NAMESPACE

    Substitua os seguintes valores:

    • KSA_NAME: o nome da ServiceAccount do Kubernetes usada pelo operador
    • OPERATOR_NAMESPACE: o namespace em que você instalou o operador
    • GSA_EMAIL: o endereço de e-mail da conta de serviço do Google

  4. Forneça o arquivo de configuração de credencial para o pod do operador. Para mais informações, consulte Configurar a carga de trabalho.

Criar recursos do ESO para sincronizar secrets

Depois de configurar a autenticação, é possível criar recursos do operador External Secrets para sincronizar secrets.

Criar um SecretStore

Um SecretStore especifica como acessar o sistema externo de gerenciamento de secrets. É possível criar recursos SecretStore no mesmo namespace que o operador External Secrets ou em namespaces de aplicativos. Para mais informações, consulte SecretStore na documentação do Kubernetes.

  1. Crie um arquivo chamado secret-store.yaml com o conteúdo a seguir:

    apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gcp-store
  namespace: NAMESPACE
spec:
  provider:
    gcpsm:
      projectID: PROJECT_ID

    Substitua os seguintes valores:

    • NAMESPACE: o namespace em que você quer criar o SecretStore
    • PROJECT_ID: o ID do seu projeto Google Cloud em que os secrets são armazenados.

  2. Use o comando kubectl apply para aplicar o manifesto:

    kubectl apply -f secret-store.yaml

Criar um ClusterSecretStore

Um ClusterSecretStore é um recurso com escopo no cluster que os recursos ExternalSecret podem usar em qualquer namespace. Para mais informações, consulte ClusterSecretStore na documentação do Kubernetes.

  1. Crie um arquivo chamado cluster-secret-store.yaml com o conteúdo a seguir:

    apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: gcp-cluster-store
spec:
  provider:
    gcpsm:
      projectID: PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto Google Cloud em que os secrets estão armazenados.

  2. Aplique o manifesto:

    kubectl apply -f cluster-secret-store.yaml

Crie um ExternalSecret

Um ExternalSecret declara quais dados buscar e onde armazená-los no cluster. Crie recursos ExternalSecret no namespace em que os pods de aplicativo consomem o secret do Kubernetes resultante. Para mais informações, consulte ExternalSecret na documentação do Kubernetes.

  1. Crie um arquivo chamado external-secret.yaml com o conteúdo a seguir:

    apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: EXTERNAL_SECRET
  namespace: NAMESPACE
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: gcp-store
  target:
    name: K8S_SECRET_NAME
    creationPolicy: Owner
  data:
  - secretKey: K8S_SECRET_KEY
    remoteRef:
      key: SECRET_NAME

    Substitua os seguintes valores:

    • EXTERNAL_SECRET: o nome do recurso ;ExternalSecret
    • NAMESPACE: o namespace em que você criou o SecretStore.
    • K8S_SECRET_NAME: o nome do secret do Kubernetes a ser criado pelo ESO.
    • K8S_SECRET_KEY: a chave nos dados do secret do Kubernetes.
    • SECRET_NAME: o nome do secret noGoogle Cloud Secret Manager.

    Se você usar um ClusterSecretStore, defina kind: ClusterSecretStore e atualize o name em secretStoreRef.

  2. Aplique o manifesto:

    kubectl apply -f external-secret.yaml

Sincronizar várias chaves de um secret JSON

Se o secret no Secret Manager contiver uma string JSON, você poderá extrair todas as chaves como entradas individuais no secret do Kubernetes.

  1. Crie um arquivo chamado external-secret-json.yaml com o conteúdo a seguir:

    apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: EXTERNAL_SECRET
  namespace: NAMESPACE
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: gcp-store
  target:
    name: K8S_SECRET_NAME
    creationPolicy: Owner
  dataFrom:
  - extract:
      key: SECRET_NAME

  2. Aplique o manifesto:

    kubectl apply -f external-secret-json.yaml

Cada par de chave-valor no segredo JSON é mapeado para um par de chave-valor no segredo resultante do Kubernetes.

Solução de problemas

Se os secrets não forem sincronizados, siga estas etapas para resolver o problema:

  1. Use o comando kubectl get para verificar o status do recurso ExternalSecret:

    kubectl get externalsecret EXTERNAL_SECRET -n NAMESPACE -o yaml

    Examine a seção status para ver se há mensagens de erro ou condições com falha.

  2. Use o comando kubectl logs para verificar os registros do pod do controlador do operador External Secrets:

    kubectl logs -l app.kubernetes.io/name=external-secrets -n OPERATOR_NAMESPACE

  3. Verifique se a conta de serviço do Kubernetes usada pelo operador está anotada corretamente com o e-mail da conta de serviço do Google. Para mais informações, consulte Federação de identidade da carga de trabalho no cluster.

  4. Verifique se a conta de serviço do Google tem as permissões necessárias e se a federação de identidade da carga de trabalho está configurada corretamente. Para mais informações, consulte Federação de identidade da carga de trabalho no cluster.

A seguir