Proteger workloads com certificados do Kubernetes

A API de certificados do Kubernetes automatiza o provisionamento de credenciais X.509. A API conta com uma interface de linha de comando para que os clientes de API do Kubernetes solicitem e recebam certificados X.509 de uma autoridade de certificação (CA). Você pode usa o recurso CertificateSigningRequest (CSR) para solicitar que um signatário indicado assine o certificado. As solicitações são aprovadas ou negadas antes de serem assinadas. O Kubernetes é compatível com os signatários integrados e signatários personalizados com comportamentos bem definidos. Dessa maneira, os clientes podem prever o que acontece com suas CSRs. Para saber mais sobre assinatura de certificados, consulte solicitações de assinatura.

Um dos signatários integrados é kubernetes.io/legacy-unknown. A API v1beta1 do recurso CSR respeitou esse signatário legacy-unknown. Porém, a API estável v1 de CSR não permite que o signerName seja definido como kubernetes.io/legacy-unknown.

A versão 1.21 e anteriores do Amazon EKS permitiam o valor legacy-unknown como o signerName na API de CSR v1beta1. Essa API permite que a Autoridade de certificação (CA) do Amazon EKS gere certificados. Porém, no Kubernetes versão 1.22, a API do CSR v1beta1 foi substituída pela API do CSR v1. Essa API não oferece suporte ao signerName “legacy-unknown”. Se você desejar usar a CA do Amazon EKS para gerar certificados em seus clusters, deverá usar um signatário personalizado. Ele foi introduzido na versão 1.22 do Amazon EKS. Para usar a versão v1 da API de CSR e gerar um novo certificado, você deverá migrar todos os manifestos e clientes de API existentes. Certificados existentes criados com a API v1beta1 existente são válidos e funcionarão até o certificado expirar. Essa transmissão inclui o seguinte:

• Distribuição de confiança: nada. Não há confiança ou distribuição padrão para esse signatário em um cluster do Kubernetes.

• Requerentes permitidos: qualquer

• Extensões x509 permitidas: respeita subjectAltName e extensões de uso de chaves e descarta outras extensões

• Usos de chaves permitidos: não deve incluir usos além de ["criptografia de chaves”, “assinatura digital”, “autenticação de servidor"]

  nota

  A assinatura de certificados de clientes não é possível.

• Vida útil de expiração/certificado: um ano (padrão e máximo)

• Bit de CA permitido/proibido: não permitido

Exemplo de geração de CSR com signerName

Estas etapas mostram como gerar um certificado de serviço para o nome de DNS myserver.default.svc usando signerName: beta.eks.amazonaws.com/app-serving. Use isso como orientação para seu próprio ambiente.

1. Execute o comando openssl genrsa -out myserver.key 2048 para gerar uma chave RSA privada.

   openssl genrsa -out myserver.key 2048

2. Use o seguinte comando para gerar uma solicitação de certificado:

   openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"

3. Gere um valor em base64 para a solicitação de CSR e armazene-o em uma variável para uso em uma etapa posterior.

   base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
   ")

4. Execute o seguinte comando para criar um arquivo chamado mycsr.yaml. No exemplo a seguir, beta.eks.amazonaws.com/app-serving é signerName.

   cat >mycsr.yaml <<EOF
   apiVersion: certificates.k8s.io/v1
   kind: CertificateSigningRequest
   metadata:
     name: myserver
   spec:
     request: $base_64
     signerName: beta.eks.amazonaws.com/app-serving
     usages:
       - digital signature
       - key encipherment
       - server auth
   EOF

5. Envie a CSR.

   kubectl apply -f mycsr.yaml

6. Aprove o certificado de serviço.

   kubectl certificate approve myserver

7. Confira se o certificado foi emitido.

   kubectl get csr myserver

   Veja um exemplo de saída abaixo.

   NAME       AGE     SIGNERNAME                           REQUESTOR          CONDITION
   myserver   3m20s   beta.eks.amazonaws.com/app-serving   kubernetes-admin   Approved,Issued

8. Exporte o certificado emitido.

   kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt

Considerações sobre a assinatura de certificado antes de atualizar seu cluster para o Kubernetes 1.24

No Kubernetes 1.23 e anteriores, certificados servidos pelo kubelet com Subject Alternative Names (SANs) IP e DNS não verificáveis são emitidos automaticamente com SANs não verificáveis. Os SANs são omitidos no certificado provisionado. Em clusters 1.24 e posteriores, os certificados servidos pelo kubelet não são emitidos se o SAN não puder ser verificado. Isso impede o funcionamento dos comandos kubectl exec e kubectl logs.

Antes de atualizar seu cluster para 1.24, execute as seguintes etapas a fim de determinar se ele tem certificate signing requests (CSR – Solicitações de assinatura de certificado) que não foram aprovadas:

1. Execute o seguinte comando:

   kubectl get csr -A

   Veja um exemplo de saída abaixo.

   NAME        AGE   SIGNERNAME                      REQUESTOR                                                  REQUESTEDDURATION   CONDITION
   csr-7znmf   90m   kubernetes.io/kubelet-serving   system:node:ip-192-168-42-149.region.compute.internal      <none>              Approved
   csr-9xx5q   90m   kubernetes.io/kubelet-serving   system:node:ip-192-168-65-38.region.compute.internal      <none>              Approved, Issued

   Se a saída retornada mostrar um CSR com um signatário kubernetes.io/kubelet-serving que seja Approved, mas não Issued para um nó, você precisará aprovar a solicitação.

2. Aprove a CSR manualmente. Substitua csr-7znmf pelos seus próprios valores.

   kubectl certificate approve csr-7znmf

Para aprovar automaticamente as CSRs no futuro, recomendamos que você crie um controlador de aprovação capaz de validar e aprovar automaticamente as CSRs que contenham SANs IP ou DNS que o Amazon EKS não possa verificar.