Configurar Kubernetes

Este documento fornece informações sobre como configurar o perfil de publicação Kubernetes para que seja possível instalar e publicar certificados em recursos do cluster.

Requisitos

• Um certificado gerado e assinado por uma CA. Mais informações em Como criar uma requisição e Como assinar uma requisição. O certificado precisa ter uma chave privada.
• Um cluster Kubernetes cadastrado como dispositivo no Segura®.
• Uma conectividade HTTPS no dispositivo, configurada com a porta da API do Kubernetes (por exemplo, 6443). Sem ela, a publicação falha com o erro Equipment without HTTPS connectivity.
• Uma credencial de acesso cuja senha é o bearer token de uma ServiceAccount do Kubernetes. A ServiceAccount precisa de permissão RBAC para patch em secrets e nos deployments, statefulsets e daemonsets que serão reimplantados.

Configurar o Kubernetes

Para configurar o Kubernetes, veja os passos a seguir:

1. No Segura®, na barra de navegação, passe o mouse sobre o Menu de produtos e selecione Certificate Manager.
2. No menu lateral, selecione Publicações > Perfis de publicação.
3. Clique no botão de ações e selecione Kubernetes.
4. Na aba Configurações, preencha os seguintes campos:
   1. No campo Nome do perfil *, insira o nome do perfil.
   2. No campo Username da credencial, insira o nome da credencial.
   3. Opcional: Marque a opção Utilizar uma credencial cadastrada para acessar todos os dispositivos, e, no campo Credencial de acesso cadastrada do sistema, selecione uma credencial de acesso cadastrada no Segura®.
5. Clique em Continuar.
6. Na aba Kubernetes, preencha as seguintes tabelas. Você pode adicionar várias linhas em cada tabela.

   1. Na tabela Secrets, adicione os secrets que armazenam o certificado. Para cada linha, preencha:

      • Secret: o nome do secret.
      • Namespace: o namespace do secret.

      Cada secret precisa existir previamente e conter as chaves tls.crt e tls.key, como em um secret do tipo kubernetes.io/tls. O Segura® substitui os valores dessas duas chaves e não cria o secret.

   2. Na tabela Redeploy automático, adicione os recursos a reimplantar após a atualização dos secrets. Para cada linha, preencha:

      • Tipo: selecione Deployment, StatefulSet ou DaemonSet.
      • Nome: o nome do recurso.
      • Namespace: o namespace do recurso.

      O Segura® reimplanta cada recurso atualizando o label redeploytimestamp em spec.template.metadata.labels.

7. Clique em Continuar.
8. Na aba Dispositivos, selecione o cluster Kubernetes.
   1. O dispositivo deve ter sido cadastrado previamente no Segura®.
9. Na aba Revisão, verifique todas as informações inseridas anteriormente e clique em Salvar.

Verifique seus resultados

Após publicar um certificado no Kubernetes, verifique o log de execução para confirmar o resultado.

O log identifica qual Network Connector a publicação utilizou para acessar o cluster.

Se o secret ou o redeploy do recurso não forem atualizados, a execução termina em Error.

Se o Segura® não conseguir se conectar à API do Kubernetes, a execução falha com a seguinte mensagem. A conexão expira após 10 segundos, e a requisição completa após 60 segundos.

Unable to reach the Kubernetes API at <ip>:<port> (<route>): <connection error>

Se a API do Kubernetes responder com erro, a execução falha com uma das seguintes mensagens:

Kubernetes publishing failed for <N> secret(s): <namespace/name>, …
Kubernetes redeploy failed for <N> resource(s): <namespace/type/name>, …

<route> é via Network Connector <agent> (o próprio agente do dispositivo, ou, se o dispositivo não tiver um, o Network Connector padrão) ou direct connection. Se a atualização de um secret falhar, o redeploy não é executado. A coluna de erro em Publishing status trunca a mensagem em cerca de 255 caracteres; o log de execução mostra o texto completo.

As linhas de log registradas antes da falha são mantidas; elas não são removidas.

Clusters atrás de um proxy ou de um load balancer que roteia por hostname, como Rancher ou um load balancer de nuvem, se conectam através do Network Connector, porque o Segura® mantém o hostname do cluster para o SNI e o cabeçalho Host.