Proteger workloads com certificados do Kubernetes - Amazon EKS
Exemplo de geração de CSR com signerName

Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Proteger workloads com certificados do Kubernetes

A API Certificates do Kubernetes automatiza o provisionamento de credenciais X.509. Ela tem uma interface de linha de comandos para os clientes de APIs do Kubernetes solicitarem e receberem 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. Suas solicitações são aprovadas ou negadas antes de serem assinadas. O Kubernetes é compatível com signers incorporados e 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.

Se você desejar usar a CA do Amazon EKS para gerar certificados em seus clusters, deverá usar um signatário personalizado. 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 signer 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