🥇Lançado cert-manager 1.0

Se você perguntar a um experiente engenheiro muito sábio o que ele acha do cert-manager e por que todos o utilizam, ele suspirará, te abraçará de maneira confidente e dirá cansado: "Todos o utilizam porque não há alternativas viáveis. Nossas mentes choram, sofrem, mas continuam vivendo com este cacto. Por que amamos? Porque funciona. Por que não amamos? Porque novas versões são lançadas constantemente, que usam novos recursos. E temos que atualizar o cluster repetidamente. E as versões antigas param de funcionar porque há uma conspiração e um grande e misterioso xamanismo".

Mas os desenvolvedores garantem que com cert-manager 1.0 tudo vai mudar.

Vamos acreditar?

O cert-manager é o controlador 'nativo' de gerenciamento de certificados do Kubernetes. Com ele, é possível emitir certificados de várias fontes: Let’s Encrypt, HashiCorp Vault, Venafi, pares de chaves para assinatura e certificados autoassinados. Ele também permite manter as chaves atualizadas dentro do seu período de validade e tenta atualizar automaticamente os certificados no tempo definido antes de sua expiração. O cert-manager é baseado no kube-lego e também utilizou algumas técnicas de outros projetos semelhantes, como o kube-cert-manager.

Notas de lançamento

Com a versão 1.0, nós colocamos um selo de confiança após três anos de desenvolvimento do projeto cert-manager. Nesse tempo, ele evoluiu significativamente em funcionalidade e estabilidade, mas mais importante — na comunidade. Hoje, vemos muitas pessoas utilizando-o para proteger seus clusters Kubernetes e também implementando-o em várias partes do ecossistema. Nos últimos 16 lançamentos, um grande número de erros foi corrigido. E o que precisava ser quebrado, foi quebrado. Várias iterações no trabalho com a API melhoraram sua interação com os usuários. Resolvemos 1500 problemas no GitHub com um número ainda maior de pedidos de mesclagem de 253 membros da comunidade.

Ao lançar a versão 1.0, afirmamos oficialmente que o cert-manager é um projeto maduro. Também prometemos manter a compatibilidade de nossa API v1.

Um enorme agradecimento a todos que nos ajudaram a fazer o cert-manager durante esses três anos! Que a versão 1.0 seja o primeiro de muitos grandes feitos futuros.

O lançamento 1.0 é uma versão estável com várias direções prioritárias:

v1 API;
Time kubectl cert-manager status, para ajudar na análise de problemas;
Uso das APIs estáveis mais recentes do Kubernetes;
Melhorias de registro;
Melhorias no ACME.

Antes de atualizar, leia atentamente as notas de atualização.

API v1

A versão v0.16 funcionava com o API v1beta1. Isso trouxe algumas alterações estruturais, assim como melhorou a documentação dos campos do API. A versão 1.0 se baseia em tudo isso com o API v1. Este API é nosso primeiro estável, ao mesmo tempo em que já garantimos compatibilidade, mas com o API v1 prometemos manter a compatibilidade por muitos anos.

As alterações feitas (nota: nossas ferramentas de conversão cuidarão de tudo para você):

Certificado:

emailSANs agora é chamado de emailAddresses
uriSANs — uris

Essas alterações adicionam compatibilidade com outros SAN (nomes alternativos de assunto, Nota do tradutor), assim como com o Go API. Estamos removendo esse termo de nosso API.

Atualizar

Se você está usando Kubernetes 1.16+ — os webhooks de conversão permitirão que você trabalhe simultaneamente e sem interrupções com versões do API v1alpha2, v1alpha3, v1beta1 e v1. Com eles, você poderá usar a nova versão do API sem alterar ou reimplantar seus recursos antigos. Recomendamos fortemente atualizar seus manifests para o API v1, uma vez que as versões anteriores em breve serão descontinuadas. Usuários legacy da versão cert-manager ainda terão acesso apenas a v1, os passos para atualização podem ser encontrados aqui.

Equipe kubectl cert-manager status

Com as novas melhorias em nossa extensão ao kubectl ficou mais fácil explorar problemas relacionados à falta de emissão de certificados. kubectl cert-manager status agora fornece muito mais informações sobre o que está acontecendo com os certificados, assim como mostra a fase de emissão do certificado.

Depois de instalar a extensão, você pode executar kubectl cert-manager status certificate, o que resultará na busca do certificado com o nome especificado e quaisquer recursos relacionados, como CertificateRequest, Secret, Issuer, assim como Order e Challenges em caso de uso de certificados da ACME.

Exemplo de depuração de um certificado ainda não pronto:

$ kubectl cert-manager status certificate acme-certificate

Nome: acme-certificate
Namespace: default
Criado em: 2020-08-21T16:44:13+02:00
Condições:
  Pronto: Falso, Motivo: Não Existe, Mensagem: Emitindo certificado, pois o Secret não existe
  Emitindo: Verdadeiro, Motivo: Não Existe, Mensagem: Emitindo certificado, pois o Secret não existe
Nomes DNS:
- example.com
Eventos:
  Tipo    Motivo     Idade   De            Mensagem
  ----    ------     ----  ----          -------
  Normal  Emitindo    18m   cert-manager  Emitindo certificado, pois o Secret não existe
  Normal  Gerado     18m   cert-manager  Armazenou nova chave privada no recurso Secret temporário "acme-certificate-tr8b2"
  Normal  Solicitado  18m   cert-manager  Criou novo recurso CertificateRequest "acme-certificate-qp5dm"
Emissor:
  Nome: acme-issuer
  Tipo: Emissor
  Condições:
    Pronto: Verdadeiro, Motivo: ACMEAccountRegistered, Mensagem: A conta ACME foi registrada no servidor ACME
erro ao encontrar Secret "acme-tls": secrets "acme-tls" não encontrado
Não Antes: 
Não Depois: 
Tempo de Renovação: 
CertificateRequest:
  Nome: acme-certificate-qp5dm
  Namespace: default
  Condições:
    Pronto: Falso, Motivo: Pendente, Mensagem: Aguardando emissão de certificado da ordem default/acme-certificate-qp5dm-1319513028: "pendente"
  Eventos:
    Tipo    Motivo        Idade   De            Mensagem
    ----    ------        ----  ----          -------
    Normal  OrdemCriada  18m   cert-manager  Criou recurso Order default/acme-certificate-qp5dm-1319513028
Ordem:
  Nome: acme-certificate-qp5dm-1319513028
  Estado: pendente, Motivo:
  Autorizações:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identificador: example.com, Estado Inicial: pendente, Curvas: falso
Desafios:
- Nome: acme-certificate-qp5dm-1319513028-1825664779, Tipo: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Chave: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Estado: pendente, Motivo: erro ao obter a conta de serviço clouddns: secret "clouddns-accoun" não encontrado, Processando: verdadeiro, Apresentado: falso

O comando também pode ajudar a descobrir mais sobre o conteúdo do certificado. Exemplo de detalhes para um certificado emitido pelo Letsencrypt:

$ kubectl cert-manager status certificate example
Nome: example
[...]
Secret:
  Nome: example
  País do Emissor: EUA
  Organização do Emissor: Let's Encrypt
  Nome Comum do Emissor: Let's Encrypt Authority X3
  Uso da Chave: Assinatura Digital, Criptografia de Chave
  Usos Extendidos da Chave: Autenticação de Servidor, Autenticação de Cliente
  Algoritmo da Chave Pública: RSA
  Algoritmo da Assinatura: SHA256-RSA
  ID da Chave do Assunto: 65081d98a9870764590829b88c53240571997862
  ID da Chave da Autoridade: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Número de Série: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Eventos: 
Não Antes: 2020-06-02T04:29:56+02:00
Não Depois: 2020-08-31T04:29:56+02:00
Tempo de Renovação: 2020-08-01T04:29:56+02:00
[...]

Uso das APIs mais recentes e estáveis do Kubernetes

Cert-manager foi um dos primeiros a implementar CRDs do Kubernetes. Isso, juntamente com nosso suporte a versões do Kubernetes até a 1.11, levou a necessidade de suportar o legado apiextensions.k8s.io/v1beta1 para nossos CRDs, assim como admissionregistration.k8s.io/v1beta1 para nossos webhooks. Agora eles estão obsoletos e serão removidos no Kubernetes a partir da versão 1.22. Com nossa versão 1.0, agora oferecemos suporte total apiextensions.k8s.io/v1 e admissionregistration.k8s.io/v1 para Kubernetes 1.16 (onde foram adicionados) e versões mais recentes. Para usuários de versões anteriores, continuamos a oferecer suporte v1beta1 na nossa legacy versão.

Registro aprimorado

Nesta versão, atualizamos a biblioteca de registro para klog/v2, utilizada no Kubernetes 1.19. Também verificamos cada log que escrevemos para atribuir o nível apropriado. Fomos guiados pelo guia do Kubernetes. Existem cinco (na verdade — seis, Nota do tradutor) níveis de registro, começando com Erro (nível 0), que exibe apenas erros importantes, e terminando com Trace (nível 5), que ajuda a entender exatamente o que está acontecendo. Com essa alteração, reduzimos a quantidade de logs, caso você não precise de informações de depuração ao usar o cert-manager.

Dica: por padrão, o cert-manager opera no nível 2 (Info), você pode sobrescrever isso usando global.logLevel no Helm chart.

Nota: a visualização de logs é o último recurso ao solucionar problemas. Para mais informações, consulte nosso guia.

N.B. editor: Para saber mais sobre como tudo isso funciona por trás do Kubernetes, obter dicas valiosas de praticantes-educadores e receber ajuda de suporte técnico de qualidade, você pode participar de intensivos online Base Kubernetes, que ocorrerá de 28 a 30 de setembro, e Mega Kubernetes, que ocorrerá de 14 a 16 de outubro.

Melhorias do ACME

O uso mais comum do cert-manager está relacionado à emissão de certificados do Let’s Encrypt usando ACME. A versão 1.0 é notável pelo uso de feedback da comunidade para adicionar duas pequenas, mas importantes melhorias ao nosso emissor ACME.

Desativação da criação da chave da conta

Se você utiliza certificados ACME em grande escala, provavelmente usará a mesma conta em vários clusters, assim suas limitações de emissão de certificados afetarão todos eles. Isso já era possível no cert-manager ao copiar o segredo especificado em privateKeySecretRef. Essa forma de uso era bastante problemática, pois o cert-manager tentava ser útil e alegremente criava uma nova chave de conta se não a encontrasse. Portanto, adicionamos disableAccountKeyGeneration, para protegê-lo contra esse comportamento; ao configurar este parâmetro como verdadeiro — o cert-manager não criará a chave e avisará que não foi fornecida uma chave de conta.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    privateKeySecretRef:
      name: example-issuer-account-key
    disableAccountKeyGeneration: false

Cadeia preferida

29 de setembro Let’s Encrypt irá passar para o seu próprio centro de certificação raiz ISRG Root. Os certificados com assinaturas cruzadas serão trocados por Identrust. Essa alteração não requer modificações nas configurações do cert-manager; todos os certificados atualizados ou novos emitidos após essa data utilizarão a nova CA raiz.

A Let’s Encrypt já está assinando certificados com essa CA e os oferece como uma "cadeia alternativa de certificados" através do ACME. Nesta versão do cert-manager, há a possibilidade de definir acesso a essas cadeias nas configurações do emissor. No parâmetro preferredChain é possível especificar o nome da CA utilizada para emitir o certificado. Se houver um certificado CA disponível correspondente à solicitação, ele emitirá o seu certificado. Observe que essa é a opção preferencial; se nada for encontrado, um certificado padrão será emitido. Isso garantirá que você ainda faça a atualização do seu certificado após a remoção da cadeia alternativa no lado do emissor ACME.

Já é possível obter certificados assinados ISRG Root, assim:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

Se você preferir manter a cadeia IdenTrust — defina esse parâmetro como DST Root CA X3:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "DST Root CA X3"

Observe que esta CA raiz em breve será descontinuada; a Let’s Encrypt manterá essa cadeia ativa até 29 de setembro de 2021.

Fonte: habr.com