Import Alibaba Cloud KMS service credentials using ack-secret-manager - Key Management Service: Central de Documentação do Alibaba Cloud

Como funciona

Dois tipos de definição de recurso personalizado (CRD) conduzem o processo de sincronização:

SecretStore (nível de namespace) / ClusterSecretStore (nível de cluster): define como o ack-secret-manager se autentica no KMS.
ExternalSecret (nível de namespace) / ClusterExternalSecret (nível de cluster): especifica quais secrets do KMS devem ser sincronizados e onde armazená-los no cluster.

Ao processar um ExternalSecret, o ack-secret-manager lê o SecretStore referenciado para obter as credenciais de autenticação, recupera o secret especificado no KMS e cria ou atualiza um Kubernetes Secret com o mesmo nome e namespace do ExternalSecret.

Considerações de segurança

A leitura de secrets baseada em arquivos apresenta problemas de compatibilidade em relação ao acesso direto ao KMS, e o ack-secret-manager resolve essas questões. Antes de ativar a sincronização de secrets, avalie os seguintes riscos:

Travessia do sistema de arquivos: Secrets montados via sistema de arquivos podem ficar expostos se aplicações vulneráveis forem exploradas para executar ataques de travessia de diretórios.
Exposição em debug e logs: Breakpoints de depuração mal configurados ou permissões excessivas de acesso a logs podem vazar Secrets. Referenciar Secrets por variáveis de ambiente é inseguro e não recomendado.
Permissões excessivas: Aplique o princípio do menor privilégio ao conceder acesso do ack-secret-manager ao KMS.

Se sua aplicação não precisar persistir secrets localmente, conceda permissões mínimas aos pods usando {{XREF_0}} e chame {{XREF_1}} diretamente da aplicação. Essa abordagem evita totalmente a exposição de secrets no sistema de arquivos do pod ou em Kubernetes Secrets.

Pré-requisitos

Você possui um cluster ACK. Tipos de cluster suportados:
- {{XREF_2}}
- {{XREF_3}}
- {{XREF_4}}
- ACK dedicated cluster
- ACK Edge cluster
{{XREF_5}}.

Etapa 1: Instalar o ack-secret-manager

Na página ACK Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Applications > Helm.
Na página Helm, clique em Deploy. Na seção Chart do painel Deploy, localize e selecione ack-secret-manager e clique em Next.

Na caixa de diálogo de confirmação, o chart é instalado no namespace kube-system por padrão. Clique em Yes para continuar. Para usar um namespace personalizado, configure Application Name e Namespace na etapa Basic Information.

Na etapa Parameters, selecione a versão mais recente do chart e configure os parâmetros abaixo conforme necessário. Em seguida, clique em OK.

Categoria	Parâmetro	Descrição
Autenticação RRSA	`rrsa.enable`	Defina como `true` para ativar RAM Roles for Service Accounts (RRSA). Isso permite que o `ack-secret-manager` se autentique usando a identidade da conta de serviço, sem gerenciar pares de AccessKey.
Sincronização agendada	`command.disablePolling`	Defina como `false` para ativar a sincronização periódica de secrets.
Sincronização agendada	`command.pollingInterval`	Frequência de sincronização. O valor padrão é `120s`.
Limitação de taxa	`command.maxConcurrentKmsSecretPulls`	Número máximo de requisições simultâneas de secrets do KMS por segundo. O padrão é `10`. Evita limitações de taxa do KMS ou RAM em clusters com muitos `ExternalSecrets`.
Endpoint do KMS	`command.kmsEndpoint`	Endpoint global do KMS para todas as requisições. Também é possível configurar endpoints no nível de secret. Consulte {{XREF_6}}.
Controle entre namespaces	`command.enableCrossNamespaceSecretStore`	Defina como `false` para impedir que um `ExternalSecret` referencie um `SecretStore` em outro namespace.
Controle entre namespaces	`command.enableCrossNamespaceAuthRef`	Defina como `false` para impedir que um `SecretStore` referencie recursos de autenticação em outro namespace.
CRDs de nível de cluster	`crds.createClusterSecretStore`	Defina como `true` para instalar o CRD `ClusterSecretStore`.
	`crds.createClusterExternalSecret`	Defina como `true` para instalar o CRD `ClusterExternalSecret`.
	`command.processClusterSecretStore`	Defina como `true` para permitir que o controlador processe recursos `ClusterSecretStore`.
	`command.processClusterExternalSecret`	Defina como `true` para permitir que o controlador processe recursos `ClusterExternalSecret`.

Após a instalação, o console do ACK redireciona para a página ack-secret-manager. Verifique a instalação confirmando se os recursos esperados foram criados.

Etapa 2: Configurar a autenticação do ack-secret-manager

Crie um SecretStore para definir como o ack-secret-manager se autentica no KMS. Escolha um dos quatro métodos de autorização abaixo com base no tipo de cluster e nos requisitos de segurança.

Método	Tipos de cluster aplicáveis	Principal vantagem
{{XREF_7}}	ACK managed cluster s e ACK Serverless cluster s executando Kubernetes 1.22 ou posterior	Oferece isolamento rigoroso no nível de namespace/pod. Ideal para arquiteturas multilocatário. Não requer AccessKeys.
{{XREF_8}}	ACK managed cluster s e ACK Serverless cluster s executando Kubernetes 1.22 ou posterior	Configuração simples de RRSA para clusters monolocatário. Concede acesso global ao KMS para o add-on. Não requer AccessKeys.
{{XREF_9}}	ACK managed cluster s, ACK dedicated cluster s e registered cluster s	Configuração mais simples. Utiliza as funções de nó existentes. Não exige credenciais adicionais nem recursos `SecretStore`.
{{XREF_10}}	Todos os tipos de cluster	Suportado universalmente em todos os ambientes.

RRSA granular por ServiceAccount

Este método proporciona isolamento de acesso ao KMS entre diferentes namespaces e ServiceAccounts, sendo ideal para cenários multilocatário.

Ative RRSA OIDC para o cluster no ACK console. Consulte {{XREF_11}}.

Nota
Defina rrsa.enable como true na configuração do ack-secret-manager.

Crie funções RAM separadas para diferentes ServiceAccounts. Defina Principal Type como Identity Provider e configure os parâmetros a seguir. Para mais detalhes, consulte {{XREF_12}}.

Parâmetro	Descrição
Identity Provider Type	Selecione OIDC.
Identity Provider	Selecione `ack-rrsa-<CLUSTER_ID>`, onde `<CLUSTER_ID>` é o ID do seu cluster.
Condition	oidc:iss: Mantenha a configuração padrão. oidc:aud: Mantenha a configuração padrão. oidc:sub: Adicione esta condição manualmente. Key: Selecione oidc:sub. Operator: Selecione StringEquals. Value: Insira `system:serviceaccount:<NAMESPACE>:<SERVICEACCOUNT_NAME>`, onde `<NAMESPACE>`é o namespace do ack-secret-manager e `<SERVICEACCOUNT_NAME>` é o nome da conta de serviço. Neste exemplo, insira `system:serviceaccount:kube-system:ack-secret-manager`.

Crie e anexe a política de acesso ao KMS à função RAM.

Crie a seguinte política. Para mais detalhes, consulte {{XREF_13}}.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Anexe a política à função RAM. Para mais detalhes, consulte {{XREF_14}}.

Crie uma ServiceAccount no namespace da sua aplicação, anotada com o ARN da função RAM.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Crie um SecretStore que referencie essa ServiceAccount.

Crie um arquivo chamado secretstore-rrsa.yaml com o conteúdo abaixo. Substitua os placeholders conforme descrito.

<NAME>: Nome do SecretStore.
<NAMESPACE>: Namespace Kubernetes de destino.

<SERVICEACCOUNT_NAME>: Nome da ServiceAccount criada na etapa anterior.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Aplique o SecretStore.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

RRSA global para ack-secret-manager

Este método concede acesso global ao KMS para o próprio add-on.

Ative RRSA OIDC para o cluster no ACK console. Consulte {{XREF_15}}.

Nota
Defina rrsa.enable como true na configuração do ack-secret-manager.

Crie uma função RAM para o ack-secret-manager.

Defina Principal Type como Identity Provider e configure os parâmetros a seguir. Para mais detalhes, consulte {{XREF_16}}.

Parâmetro	Descrição
Identity Provider Type	Selecione OIDC.
Identity Provider	Selecione `ack-rrsa-<CLUSTER_ID>`, onde `<CLUSTER_ID>` é o ID do seu cluster.
Condition	oidc:iss: Mantenha a configuração padrão. oidc:aud: Mantenha a configuração padrão. oidc:sub: Adicione esta condição manualmente. Key: Selecione oidc:sub. Operator: Selecione StringEquals. Value: Insira `system:serviceaccount:<NAMESPACE>:<SERVICEACCOUNT_NAME>`, onde `<NAMESPACE>`é o namespace do ack-secret-manager e `<SERVICEACCOUNT_NAME>` é o nome da conta de serviço. Neste exemplo, insira `system:serviceaccount:kube-system:ack-secret-manager`.

Crie e anexe a política de acesso ao KMS à função RAM.

Crie a seguinte política. Para mais detalhes, consulte {{XREF_17}}.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Anexe a política à função RAM. Para mais detalhes, consulte {{XREF_18}}.

Crie e implante um SecretStore.

Crie um arquivo chamado secretstore-rrsa.yaml.

<ACCOUNT_ID>: ID da conta Alibaba Cloud usada para sincronizar secrets do KMS.
<CLUSTER_ID>: ID do seu cluster ACK.

<ROLE_NAME>: Nome da função RAM criada em {{XREF_19}}.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Execute o comando a seguir para implantar o SecretStore.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Conceder permissões à função RAM do worker

Crie uma política RAM personalizada com o conteúdo abaixo. Para mais detalhes, consulte {{XREF_20}}.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Anexe a política à função RAM do worker do cluster. Para mais detalhes, consulte {{XREF_21}}.

Ao usar este método, não é necessário configurar um SecretStore . O campo secretStoreRef no seu ExternalSecret também pode ser omitido.

Especificar um par de AccessKey para assumir uma função RAM

{{XREF_22}} para uso pelo add-on ack-secret-manager.

Ao selecionar a conta Alibaba Cloud confiável, selecione Current Account .

Crie uma política RAM personalizada que conceda acesso aos secrets do KMS e anexe-a à função RAM.

Crie uma política personalizada com o conteúdo abaixo. Para mais detalhes, consulte {{XREF_23}}.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Anexe a política à função RAM. Para mais detalhes, consulte {{XREF_24}}.

Crie uma política RAM personalizada que permita a um usuário RAM assumir a função RAM e anexe-a ao usuário RAM.
1. Crie uma política com o conteúdo abaixo. Para mais informações, consulte {{XREF_25}}.
  
  Substitua <account-id> pelo ID da conta Alibaba Cloud proprietária da função RAM e substitua <role-name> pelo nome da função RAM. Para detalhes sobre como encontrar o ARN da função, consulte {{XREF_26}}
```
  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"
```
2. Anexe a política ao usuário RAM. Para mais detalhes, consulte {{XREF_27}}.

Crie um Kubernetes Secret para armazenar o par de AccessKey do usuário RAM.

Crie um arquivo chamado ramuser.yaml com o conteúdo abaixo. Substitua AccessKey ID e AccessKey Secret pelos respectivos valores codificados em Base64.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Aplique o Secret.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Crie um SecretStore usando o par de AccessKey.
1. Crie um arquivo chamado secretstore-ramrole.yaml com o conteúdo abaixo. Substitua os placeholders conforme descrito.
  - <ACCOUNT_ID>: ID da conta Alibaba Cloud usada para sincronizar secrets do KMS.
  - <ROLE_NAME>: Nome da função RAM criada em {{XREF_28}}.
  - <SECRET_NAME> : Nome do Kubernetes Secret que armazena o par de AccessKey.
  - <SECRET_NAMESPACE> : Namespace do Kubernetes Secret.
  - <SECRET_KEY_AK> e <SECRET_KEY_SK> : As chaves no campo data do Secret que armazenam o AccessKey ID e o AccessKey Secret.
  - <ROLE_SESSION_NAME>: Nome da sessão da função (qualquer string personalizada).
```
  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"
```
2. Aplique o SecretStore.
```
  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"
```

Etapa 3: Sincronizar secrets do KMS com o cluster

Crie um ExternalSecret para especificar quais secrets do KMS devem ser sincronizados.

O namespace e o nome do Kubernetes Secret resultante correspondem exatamente aos do ExternalSecret.

Crie um arquivo chamado external.yaml com o conteúdo abaixo. Substitua os placeholders conforme descrito.

Placeholder	Descrição
`<KMS_SECRET_NAME>`	Obrigatório. Nome do secret do KMS a ser sincronizado.
`<KUBERNETES_SECRET_KEY>`	Obrigatório. Nome da chave no Kubernetes Secret onde o valor do secret do KMS será armazenado.
`<KMS_SECRET_VERSION_STAGE>`	Opcional. Rótulo de estágio da versão do secret do KMS, como `ACSCurrent`. Para usar um ID de versão, substitua `versionStage` por `versionId`. Secrets de RDS, PolarDB, Redis/Tair, RAM e ECS suportam apenas `ACSPrevious` e `ACSCurrent` e ignoram `versionId`. Para mais detalhes, consulte Elementos de secret.
`<KMS_SERVICE_ENDPOINT>`	Opcional. Endpoint de requisição do KMS. Substitui as configurações de endpoint globais e padrão. Para formatos de endpoint suportados, consulte Configurar endereços de endpoint do KMS.
`<SECRET_STORE_NAME>`	Opcional. Nome do `SecretStore` criado em {{XREF_29}}. Não é necessário ao usar a função RAM do worker.
`<SECRET_STORE_NAMESPACE>`	Opcional. Namespace do `SecretStore`. Não é necessário ao usar a função RAM do worker.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Aplique o ExternalSecret.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Verifique se existe um Kubernetes Secret.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Se existir um Kubernetes Secret, o secret do KMS foi sincronizado com sucesso para o seu cluster.

Configurações avançadas

Sincronizar secrets do KMS entre contas Alibaba Cloud

Use esta configuração para permitir que um cluster ACK na Conta B acesse uma instância do KMS na Conta A. O ack-secret-manager usa RRSA para assumir uma função RAM na Conta A por meio de um provedor OIDC na Conta B e, em seguida, importa o secret do KMS para o cluster.

Configurar permissões na Conta A

Use a Conta A para criar uma função RAM com a Conta B como entidade confiável. Selecione Other Account e insira o ID da Conta B. Para mais detalhes, consulte {{XREF_30}}.

Crie uma política RAM personalizada que conceda acesso aos secrets do KMS. Para mais informações, consulte {{XREF_31}}.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Anexe a política à função RAM. Para mais detalhes, consulte {{XREF_32}}.

Configurar permissões na Conta B

Ative RRSA OIDC para o cluster no ACK console. Consulte {{XREF_33}}.

Nota
Defina rrsa.enable como true na configuração do ack-secret-manager.

Crie uma função RAM para o ack-secret-manager.

Defina Principal Type como Identity Provider e configure os parâmetros a seguir. Para mais detalhes, consulte {{XREF_34}}.

Parâmetro	Descrição
Identity Provider Type	Selecione OIDC.
Identity Provider	Selecione `ack-rrsa-<CLUSTER_ID>`, onde `<CLUSTER_ID>` é o ID do seu cluster.
Condition	oidc:iss: Mantenha a configuração padrão. oidc:aud: Mantenha a configuração padrão. oidc:sub: Adicione esta condição manualmente. Key: Selecione oidc:sub. Operator: Selecione StringEquals. Value: Insira `system:serviceaccount:<NAMESPACE>:<SERVICEACCOUNT_NAME>`, onde `<NAMESPACE>`é o namespace do ack-secret-manager e `<SERVICEACCOUNT_NAME>` é o nome da conta de serviço. Neste exemplo, insira `system:serviceaccount:kube-system:ack-secret-manager`.

Crie uma política RAM personalizada na Conta B que permita assumir a função RAM na Conta A e anexe-a à função RAM da Conta B.
1. Crie uma política com o conteúdo abaixo, onde Resource é o ARN da função RAM criada na Conta A. Para detalhes sobre como encontrar o ARN, consulte {{XREF_35}}
```
  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"
```
2. Anexe a política à função RAM criada na Conta B. Para mais detalhes, consulte {{XREF_36}}.
Crie um SecretStore para acesso entre contas.
1. Crie um arquivo chamado secretstore-ramrole.yaml com o conteúdo abaixo. Substitua os placeholders conforme descrito.
  - <ACK-accountID>: ID da Conta B (a conta com o cluster ACK).
  - <clusterID>: ID do seu cluster ACK.
  - <ACK-roleName>: Nome da função RAM criada na Conta B.
  - <KMS-accountID>: ID da Conta A (a conta com a instância do KMS).
  - <KMS-roleName>: Nome da função RAM criada na Conta A.
  - <roleSessionName>: Nome da sessão da função (qualquer string personalizada).
```
  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"
```
Crie um ExternalSecret para especificar os detalhes da sincronização. Para mais detalhes, consulte Etapa 3: Sincronizar secrets do KMS com o cluster.

Analisar secrets JSON e YAML

Extrair campos específicos de um secret JSON

Use jmesPath para extrair pares chave-valor específicos de um secret do KMS armazenado em formato JSON.

Por exemplo, dado o seguinte secret JSON armazenado no KMS Secrets Manager:

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Crie um ExternalSecret com jmesPath para extrair campos específicos:

path: Obrigatório. Expressão JMESPath para extrair o campo. Consulte a especificação JMESPath.
objectAlias: Obrigatório. Nome da chave no Kubernetes Secret resultante.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Analisar automaticamente um secret JSON

Se a estrutura JSON for desconhecida ou variável, use dataProcess.extract para analisar automaticamente todos os pares chave-valor de um secret JSON. Use dataProcess.replaceRule para renomear chaves que não estejam em conformidade com os requisitos de nomenclatura de chaves do Kubernetes Secret.

Por exemplo, dado o seguinte secret JSON com nomes de chave fora do padrão:

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Crie um ExternalSecret com jmesPath para extrair campos específicos:

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Extrair campos específicos de um secret YAML

Use jmesPath para extrair pares chave-valor específicos de um secret do KMS armazenado em formato YAML.

Por exemplo, dado o seguinte secret YAML armazenado no KMS Secrets Manager:

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Crie um ExternalSecret com jmesPath para extrair campos específicos:

path: Obrigatório. Expressão JMESPath para extrair o campo. Consulte a especificação JMESPath.
objectAlias: Obrigatório. Nome da chave no Kubernetes Secret resultante.

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Analisar automaticamente um secret YAML

Se a estrutura YAML for desconhecida ou variável, use dataProcess.extract para analisar automaticamente todos os pares chave-valor. Use dataProcess.replaceRule para lidar com nomes de chave fora do padrão.

Por exemplo, dado o seguinte secret YAML:

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Crie um ExternalSecret com jmesPath para extrair campos específicos:

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Configurar endereços de endpoint do KMS

O ack-secret-manager resolve o endpoint do KMS usando a seguinte ordem de prioridade:

Tipo	Campo	Prioridade	Descrição
Nível de secret	`ExternalSecret.spec.data.kmsEndpoint`	Mais alta	Aplica-se a um secret específico; substitui configurações globais e padrão.
Global	`command.kmsEndpoint` (parâmetro de inicialização)	Média	Aplica-se a todas as requisições ao KMS que não possuem um endpoint no nível de secret.
Padrão	Nenhum	Mais baixa	Usa `kms-vpc.{region}.aliyuncs.com`, onde `{region}` é a região do secret do KMS.

O exemplo a seguir mostra como os endpoints no nível de secret e globais interagem:

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Formatos de endpoint suportados:

Tipo de gateway	Tipo de domínio	Formato do endpoint	Requisitos
Gateway dedicado	Domínio privado do KMS	`{kms-instance-id}.cryptoservice.kms.aliyuncs.com`	Instância de secret do KMS e cluster na mesma região e VPC. Versão da instância do KMS 3.0 ou posterior.
Gateway compartilhado	Domínio VPC	`kms-vpc.{region}.aliyuncs.com`	Secret do KMS e cluster na mesma região. Este é o endpoint padrão.
Gateway compartilhado	Domínio público	`kms.{region}.aliyuncs.com`	O cluster deve ter acesso à internet pública.

Para mais informações, consulte Diferenças entre gateways compartilhados e dedicados para acessar o KMS.

Recursos CRD

SecretStore: Recurso de nível de namespace. Define configurações de autenticação (RRSA, AK, etc.).
ClusterSecretStore: Recurso de nível de cluster. Funciona de forma semelhante ao SecretStore, mas pode ser referenciado por recursos ExternalSecret em todos os namespaces. Suporta controle de acesso por meio de spec.conditions.
ExternalSecret: Recurso de nível de namespace. Define qual secret do KMS sincronizar e referencia um SecretStore.
ClusterExternalSecret: Recurso de nível de cluster. Provisiona automaticamente recursos ExternalSecret em múltiplos namespaces com base em spec.namespaceSelectors.

Recursos de nível de cluster

ClusterExternalSecret

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Campos spec

Campo	Descrição	Obrigatório
`externalSecretSpec`	Especificações do `ExternalSecret` a ser criado.	Sim
`externalSecretName`	Nome do `ExternalSecret` a ser criado. O padrão é o nome do `ClusterExternalSecret`.	Não
`externalSecretMetadata`	Metadados do `ExternalSecret` a ser criado.	Não
`namespaceSelectors`	Lista de seletores de rótulos usados para corresponder aos namespaces de destino.	Não
`rotationInterval`	Intervalo no qual o controlador verifica os rótulos do namespace e reconcilia os objetos.	Não

Campos externalSecretMetadata

Use o campo externalSecretMetadata para adicionar metadados extras automaticamente aos recursos ExternalSecret criados pelo ClusterExternalSecret.

Campo	Descrição	Obrigatório
`annotations`	Anotações para o `ExternalSecret` gerado.	Não
`labels`	Rótulos para o `ExternalSecret` gerado.	Não

ClusterSecretStore

  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"

Campos spec

Campo	Descrição	Obrigatório
`conditions`	Define condições para restringir o acesso a namespaces específicos.	Sim
`KMS`	Conecta-se ao KMS para recuperar secrets.	Não
`OOS`	Conecta-se ao Operation Orchestration Service (OOS) para recuperar parâmetros criptografados.	Não

Campos conditions

Campo	Descrição	Obrigatório
`namespaceSelector`	Seletor de rótulos usado para corresponder aos namespaces permitidos.	Sim
`namespaces`	Lista explícita de nomes de namespaces permitidos.	Não
`namespaceRegexes`	Lista de expressões regulares usadas para corresponder aos nomes de namespaces permitidos.	Não

Controle de acesso entre namespaces

Aumente a segurança restringindo referências entre namespaces.

Referências de SecretStore para ExternalSecret

Use o parâmetro command.enableCrossNamespaceSecretStore para controlar se um ExternalSecret pode referenciar um SecretStore em outro namespace.
O valor padrão é true, que permite referências entre namespaces.
Quando definido como false, um ExternalSecret só pode referenciar um SecretStore no mesmo namespace.

Referências de recursos de autenticação para SecretStore

Use o parâmetro command.enableCrossNamespaceAuthRef para controlar se um SecretStore pode referenciar recursos de autenticação (ServiceAccount, AccessKey Secret) em outro namespace.
O valor padrão é true, que permite referências entre namespaces.
Quando definido como false, um SecretStore só pode referenciar recursos de autenticação no mesmo namespace.

Controle de acesso do ClusterSecretStore

Use o campo spec.conditions para limitar quais namespaces podem acessar o ClusterSecretStore.
Os três métodos de controle de acesso a seguir são suportados. As condições são avaliadas com lógica OR:
- namespaceSelector: Corresponde aos namespaces permitidos usando um seletor de rótulos.
- namespaces: Lista explicitamente os nomes dos namespaces permitidos.
- namespaceRegexes: Corresponde aos nomes de namespaces permitidos usando expressões regulares.
```
  conditions: 
    - namespaceSelector:
        matchLabels:
          app: myapp
        matchExpressions: 
        - key: environment
          operator: In
          values:
          - dev
    - namespaces:
      - default
      - test
    - namespaceRegexes:
      - "kube-.*"
```

Recomendações

Abordagem recomendada para acesso entre namespaces

Para acesso entre namespaces, recomenda-se as seguintes combinações:

ClusterSecretStore + ExternalSecret: Use quando vários namespaces precisarem compartilhar a mesma configuração de autenticação.
ClusterSecretStore + ClusterExternalSecret: Indicado quando é necessário criar ExternalSecrets automaticamente com a mesma configuração em múltiplos namespaces.

Melhores práticas de segurança

Princípio do menor privilégio: Se o acesso entre namespaces não for necessário, desative enableCrossNamespaceSecretStore e enableCrossNamespaceAuthRef. Sempre priorize recursos de nível de namespace (SecretStore) em vez de recursos de nível de cluster.
Restrinja o ClusterSecretStore: Nunca crie um ClusterSecretStore sem configurar spec.conditions.
Evite exposição de AccessKey: Priorize autenticação baseada em RRSA ou ServiceAccount em vez de armazenar estaticamente pares de AccessKey em Kubernetes Secrets.
Limite o ClusterExternalSecret: Use ClusterExternalSecret apenas quando absolutamente necessário e defina estritamente namespaceSelectors para evitar proliferação não intencional de secrets.

Próximos passos

Para proteger os Kubernetes Secrets sincronizados do KMS e armazenados no etcd, ative a criptografia de Secrets. Para mais detalhes, consulte {{XREF_37}}.