Documentação do Oracle Cloud Infrastructure

Criptografando Segredos do Kubernetes em Repouso no Etcd

Descubra como criptografar dados de configuração armazenados como segredos do Kubernetes no etcd ao usar o Kubernetes Engine (OKE).

O plano de controle de cluster do Kubernetes armazena dados de configuração confidenciais (como tokens de autenticação, certificados e credenciais) como objetos secretos do Kubernetes no etcd. O Etcd é um armazenamento de chave/valor distribuído de código-fonte aberto que o Kubernetes utiliza para coordenação de cluster e gerenciamento de estado. Nos clusters do Kubernetes criados pelo Kubernetes Engine, o etcd grava e lê os dados de/para volumes de armazenamento em blocos no serviço Oracle Cloud Infrastructure Block Volume. Por padrão, a Oracle criptografa dados em volumes em blocos em repouso, incluindo segredos etcd e Kubernetes. A Oracle gerencia essa criptografia padrão usando uma chave de criptografia mestra, sem exigir nenhuma ação da sua parte. Para obter controle adicional sobre o ciclo de vida da chave de criptografia principal e como ela é usada, você mesmo pode optar por gerenciar a chave de criptografia principal, em vez de fazer com que a Oracle a gerencie para você.

Se você mesmo optar por gerenciar a chave mestra de criptografia, especifique a chave a ser usada e tenha controle sobre quando a chave será girada. A chave mestra de criptografia é armazenada no serviço Oracle Cloud Infrastructure Vault (consulte Gerenciamento de Chaves). Os segredos do Kubernetes em repouso no etcd são criptografados usando uma chave de criptografia de dados (uma DEK) usando o algoritmo de criptografia AES-CBC com preenchimento PKCS#7. Uma nova DEK é gerada para cada criptografia. As chaves de criptografia de dados são criptografadas usando a chave de criptografia mestra (a MEK), um conceito conhecido como criptografia de envelope.

Para poder criar um cluster para o qual você mesmo deseja gerenciar a chave de criptografia mestra, é necessário:

  • criar uma chave principal de criptografia adequada no Vault (ou obter o nome e o OCID dessa chave)
  • criar um grupo dinâmico que inclua todos os clusters do compartimento no qual você criará o novo cluster
  • criar uma política autorizando o grupo dinâmico a usar a chave de criptografia mestra

Depois de criar o cluster e especificar que você mesmo deseja gerenciar a chave de criptografia principal, opcionalmente, você poderá restringir o uso da chave de criptografia principal modificando o grupo dinâmico para incluir apenas esse cluster.

Observe o seguinte:

  • Você só pode selecionar a opção para gerenciar a chave de criptografia principal você mesmo ao criar um novo cluster no workflow 'Criação Personalizada'. Você não pode optar por gerenciar a chave de criptografia mestra ao criar um novo cluster no workflow 'Criação Rápida'. E você não pode optar por gerenciar as chaves de criptografia principais dos clusters criados anteriormente no workflow 'Criação Personalizada'.
Cuidado

Se você selecionar a opção de gerenciar a chave de criptografia principal por conta própria, não exclua subsequentemente a chave de criptografia principal no serviço Vault. Assim que você programar a exclusão de uma chave no serviço Vault, os segredos do Kubernetes armazenados para o cluster no etcd ficarão inacessíveis. Se você já tiver programado a chave para exclusão, ela ainda poderá estar no estado Exclusão Pendente. Nesse caso, cancele a exclusão de chave programada (consulte Cancelando uma Exclusão de Chave de Criptografia Principal) para restaurar o acesso aos segredos do Kubernetes. Se você permitir que a operação de exclusão de chave programada seja concluída e a chave de criptografia mestra seja excluída, os segredos do Kubernetes armazenados para o cluster no etcd ficarão inacessíveis permanentemente. Como resultado, haverá falha nos upgrades do cluster. Nessa situação, não há outra opção, exceto excluir e recriar o cluster.

Configurando o Acesso da Chave Mestra de Criptografia

Se você optar por gerenciar a chave de criptografia principal que criptografa segredos do Kubernetes no armazenamento de chave/valor do etcd do cluster ao criar um novo cluster no workflow 'Criação Personalizada', configure o acesso à chave de criptografia principal:

  1. Faça log-in na Console.

  2. Caso saiba o OCID da chave de criptografia mestra a ser usado para criptografar segredos do Kubernetes, vá direto para a próxima etapa. Caso contrário:

    • Se já houver uma chave de criptografia principal adequada no Vault, mas você não tiver certeza de seu OCID, siga as instruções em Listando Chaves de Criptografia Principais e anote o OCID da chave de criptografia principal.
    • Se ainda não houver uma chave de criptografia principal adequada no Vault, siga as instruções em Criando uma Chave de Criptografia Principal para criar uma, definindo:
      • Modo de Proteção para Software ou HSM.
      • Forma da Chave: Algoritmo para AES, RSA ou ECDSA.
      • Forma da Chave: Tamanho para chaves AES (128, 256) e chaves RSA (2048, 3072, 4096) ou Forma da Chave: ID da Curva para chaves ECDSA (NIST_P256, NIST_P384, NIST_P521).
      Depois de criar uma nova chave de criptografia mestra, anote seu OCID.

  3. Conceda acesso à chave de criptografia principal no Vault.

    Você pode conceder acesso à chave de criptografia mestra de duas maneiras:

    Criar uma nova política de IAM (recomendado)
    1. Abra o menu de navegação e selecione Identidade e Segurança. Em Identidade, selecione Políticas.
    2. Siga as instruções em Para criar uma política e dê um nome à política (por exemplo, acme-oke-kms-policy).

    3. Informe uma instrução de política para conceder acesso à chave de criptografia mestra, no formato:

      Allow any-user to use keys in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key-ocid>'}

      em que:

      • <compartment-name> é o nome do compartimento que contém a chave de criptografia mestra.
      • <key-OCID> é o OCID da chave de criptografia mestra no serviço Vault.

      Por exemplo:

      Allow any-user to use keys in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.annrl______trfg'}
    4. Selecione Criar para criar a nova política.
    Criar um novo grupo dinâmico e, em seguida, criar uma nova política do serviço IAM
    1. Abra o menu de navegação e selecione Identidade e Segurança. Em Identidade, selecione Domínios. Em Domínio de identidades, selecione Grupos dinâmicos.
    2. Siga as instruções em Para criar um grupo dinâmico e dê um nome ao grupo dinâmico (por exemplo, acme-oke-kms-dyn-grp).

    3. Informe uma regra que inclua todos os clusters do compartimento no formato:

      ALL {resource.type = 'cluster', resource.compartment.id = '<compartment-ocid>'}

      em que <compartment-ocid> corresponde ao OCID do compartimento no qual você pretende criar o novo cluster.

      Por exemplo:

      ALL {resource.type = 'cluster', resource.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
    4. Selecione Criar Grupo Dinâmico.

      Depois de criar um grupo dinâmico que inclua todos os clusters no compartimento, você poderá criar uma política para conceder ao grupo dinâmico acesso à chave de criptografia mestra no serviço Vault.

    5. Abra o menu de navegação e selecione Identidade e Segurança. Em Identidade, selecione Políticas.
    6. Siga as instruções em Para criar uma política e dê um nome à política (por exemplo, acme-oke-kms-dyn-grp-policy).

    7. Informe uma instrução de política para conceder ao grupo dinâmico acesso à chave de criptografia mestra, no formato:

      Allow dynamic-group <dynamic-group-name> to use keys in compartment <compartment-name> where target.key.id = '<key-OCID>'

      em que:

      • <dynamic-group-name> é o nome do grupo dinâmico criado anteriormente.
      • <compartment-name> é o nome do compartimento que contém a chave de criptografia mestra.
      • <key-OCID> é o OCID da chave de criptografia mestra no serviço Vault.

      Por exemplo:

      Allow dynamic-group <acme-oke-kms-dyn-grp> to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.annrl______trfg'
    8. Selecione Criar para criar a nova política.

  4. Ao criar um novo cluster, selecione a opção Criptografar usando uma chave que você gerencia e especifique a chave de criptografia principal (consulte Usando a Console para criar um Cluster com Definições Definidas Explicitamente no workflow 'Criação Personalizada').

  5. (Opcional) Depois de criar o cluster, para maior segurança:

    1. Anote o OCID do cluster recém-criado.

    2. Restrinja o uso da chave de criptografia principal:

      • se você simplesmente criou uma política do serviço IAM, modifique a instrução de política para incluir explicitamente o OCID do novo cluster, em vez de todos os clusters no compartimento. Por exemplo:

        Allow any-user to use keys in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.annrl______trfg', request.principal.id = 'ocid1.cluster.oc1.iad.aaaaaaaaaf______yg5q'}

      • se você tiver criado um grupo dinâmico, modifique a regra do grupo dinâmico criada anteriormente para especificar explicitamente o OCID do novo cluster, em vez de todos os clusters do compartimento. Por exemplo:

        resource.id = 'ocid1.cluster.oc1.iad.aaaaaaaaaf______yg5q'

Girar a Chave de Criptografia Mestre

Se você selecionar a opção de gerenciar a chave de criptografia principal por conta própria, poderá rotacionar a chave de criptografia principal no serviço Vault, criando uma nova versão da chave de criptografia principal (consulte Rotacionando uma Chave de Vault).

Nessa situação, a chave de criptografia principal não é excluída (o recurso da chave de criptografia principal continua a existir, com o mesmo OCID), mas a chave de criptografia principal tem um novo valor. Qualquer novo segredo do Kubernetes armazenado para o cluster será criptografado usando o novo valor da chave de criptografia mestra. Todos os segredos criptografados existentes do Kubernetes ainda estarão acessíveis, porque a versão original da chave de criptografia principal ainda está disponível no serviço Vault. Se quiser que os segredos existentes do Kubernetes sejam criptografados usando a nova versão da chave de criptografia principal, você precisará rotacionar os segredos do Kubernetes para que eles sejam criptografados novamente. Por exemplo, ao executar este comando:
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="<time>"

em que <time> é uma string que indica quando executar a rotação. Por exemplo:

kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="20210909_2135"

Chaves Principais de Criptografia em Outras Tenancies

Você pode criar um cluster em uma tenancy que use uma chave principal de criptografia em uma tenancy diferente. Nesse caso, grave políticas de tenancy cruzada para permitir que o cluster em sua tenancy acesse a chave principal de criptografia na tenancy do serviço Vault. Observe que se você quiser criar um cluster e especificar uma chave principal de criptografia que esteja em uma tenancy diferente, não será possível usar a Console para criar o cluster.

Por exemplo, suponha que o cluster esteja na ClusterTenancy e que a chave principal de criptografia esteja na KeyTenancy. Os usuários que pertencem a um grupo (OKEAdminGroup) na ClusterTenancy têm permissões para criar clusters. Um grupo dinâmico (OKEAdminDynGroup) foi criado no cluster, com a regra ALL {resource.type = 'cluster', resource.compartment.id = 'ocid1.compartment.oc1..<unique_ID>'}, para que todos os clusters criados na ClusterTenancy pertençam ao grupo dinâmico.

No compartimento raiz da KeyTenancy, as seguintes políticas:

  • usam o OCID da ClusterTenancy para mapear a ClusterTenancy para o alias OKE_Tenancy
  • usam os OCIDs do OKEAdminGroup e do OKEAdminDynGroup para mapeá-los para os aliases RemoteOKEAdminGroup e RemoteOKEClusterDynGroup respectivamente
  • fornecem ao RemoteOKEAdminGroup e ao RemoteOKEClusterDynGroup a capacidade de listar, exibir e executar operações criptográficas com uma chave principal específica na KeyTenancy
Define tenancy OKE_Tenancy as ocid1.tenancy.oc1..<unique_ID>
Define dynamic-group RemoteOKEClusterDynGroup as ocid1.dynamicgroup.oc1..<unique_ID>
Define group RemoteOKEAdminGroup as ocid1.group.oc1..<unique_ID>
Admit dynamic-group RemoteOKEClusterDynGroup of tenancy ClusterTenancy to use keys in tenancy where target.key.id = 'ocid1.key.oc1..<unique_ID>'
Admit group RemoteOKEAdminGroup of tenancy ClusterTenancy to use keys in tenancy where target.key.id = 'ocid1.key.oc1..<unique_ID>'

No compartimento raiz da ClusterTenancy, as seguintes políticas:

  • usam o OCID da KeyTenancy para mapear a KeyTenancy para o alias KMS_Tenancy
  • fornecem ao OKEAdminGroup e ao OKEAdminDynGroup a capacidade de usar chaves principais na KeyTenancy
  • permitem que o OKEAdminDynGroup use uma chave principal específica obtida da KeyTenancy na ClusterTenancy
Define tenancy KMS_Tenancy as ocid1.tenancy.oc1..<unique_ID>
Endorse group OKEAdminGroup to use keys in tenancy KMS_Tenancy
Endorse dynamic-group OKEAdminDynGroup to use keys in tenancy KMS_Tenancy
Allow dynamic-group OKEAdminDynGroup to use keys in tenancy where target.key.id = 'ocid1.key.oc1..<unique_ID>'

Consulte Acessando Recursos de Armazenamento de Objetos nas Tenancies para obter mais exemplos de como gravar políticas de tenancy cruzada.

Tendo informado as políticas, agora você pode executar um comando semelhante ao seguinte para criar um cluster na ClusterTenancy que usa a chave principal obtida na KeyTenancy:
oci ce cluster create --name oke-with-cross-kms --kubernetes-version v1.16.8 --vcn-id ocid1.vcn.oc1.iad.<unique_ID> --service-lb-subnet-ids '["ocid1.subnet.oc1.iad.<unique_ID>"]' --compartment-id ocid1.compartment.oc1..<unique_ID> --kms-key-id ocid1.key.oc1.iad.<unique_ID>