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.509CertificateSigningRequest
(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.
-
Execute o comando
openssl genrsa -out myserver.key 2048
para gerar uma chave RSA privada.openssl genrsa -out myserver.key 2048
-
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"
-
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 " ")
-
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
-
Envie a CSR.
kubectl apply -f mycsr.yaml
-
Aprove o certificado de serviço.
kubectl certificate approve myserver
-
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
-
Exporte o certificado emitido.
kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt