Configure a end-to-end criptografia para aplicativos na Amazon EKS usando cert-manager e Let's Encrypt - Recomendações da AWS
ResumoPré-requisitos e limitaçõesArquiteturaFerramentasÉpicosRecursos relacionados

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Configure a end-to-end criptografia para aplicativos na Amazon EKS usando cert-manager e Let's Encrypt

Criado por Mahendra Revanasiddappa () e Vasanth Jeyaraj () AWS AWS

Repositório de códigos: nd-to-end criptografia E na Amazon EKS

Ambiente: PoC ou piloto

Tecnologias: DevOps; Contêineres e microsserviços; Segurança, identidade e conformidade

Workload: todas as outras workloads

AWSserviços: AmazonEKS; Amazon Route 53

Resumo

A implementação da end-to-end criptografia pode ser complexa e você precisa gerenciar certificados para cada ativo em sua arquitetura de microsserviços. Embora você possa encerrar a conexão Transport Layer Security (TLS) na borda da rede Amazon Web Services (AWS) com um Network Load Balancer ou API Amazon Gateway, algumas organizações end-to-end exigem criptografia.

Esse padrão usa o NGINX Ingress Controller para entrada. Isso ocorre porque quando você cria uma entrada do Kubernetes, o recurso de entrada usa um Network Load Balancer. O Network Load Balancer não permite fazer o upload de certificados de cliente. Portanto, você não pode obter reciprocidade TLS com o ingresso do Kubernetes.

Esse padrão é destinado a organizações que exigem autenticação mútua entre todos os microsserviços em seus aplicativos. A Mutual TLS reduz a carga de manter nomes de usuário ou senhas e também pode usar a estrutura de segurança pronta para uso. A abordagem desse padrão é compatível se sua organização tiver um grande número de dispositivos conectados ou precisar cumprir rígidas diretrizes de segurança.

Esse padrão ajuda a aumentar a postura de segurança da sua organização implementando end-to-end criptografia para aplicativos executados no Amazon Elastic Kubernetes Service (Amazon). EKS Esse padrão fornece um exemplo de aplicativo e código no EKS repositório de nd-to-end criptografia GitHub E na Amazon para mostrar como um microsserviço é executado com end-to-end criptografia na Amazon. EKS A abordagem do padrão usa o gerenciador de certificados, um complemento do Kubernetes, com o Let's Encrypt como autoridade de certificação (CA). O Let's Encrypt é uma solução econômica para gerenciar certificados e fornece certificados gratuitos válidos por 90 dias. O Cert-Manager automatiza o provisionamento sob demanda e a rotação de certificados quando um novo microsserviço é implantado na Amazon. EKS 

Público-alvo

Esse padrão é recomendado para usuários com experiência com KubernetesTLS, Amazon Route 53 e Domain Name System (). DNS

Pré-requisitos e limitações

Pré-requisitos

  • Uma conta da AWS ativa.

  • Um EKS cluster existente da Amazon.

  • AWSInterface de linha de comando (AWSCLI) versão 1.7 ou posterior, instalada e configurada no macOS, Linux ou Windows.

  • O utilitário de linha de kubectl comando, instalado e configurado para acessar o EKS cluster da Amazon. Para obter mais informações sobre isso, consulte Instalando o kubectl na documentação da AmazonEKS.

  • Um DNS nome existente para testar o aplicativo. Para obter mais informações, consulte Registrar nomes de domínio usando o Amazon Route 53 na documentação do Amazon Route 53. 

  • A versão mais recente do Helm instalada em sua máquina local. Para obter mais informações sobre isso, consulte Usando o Helm com a Amazon EKS na EKS documentação da Amazon e no repositório do GitHub Helm. 

  • A nd-to-end criptografia GitHub E no EKS repositório da Amazon, clonada em sua máquina local. 

  • Substitua os seguintes valores nos trustpolicy.json arquivos policy.json e da nd-to-end criptografia GitHub E clonada no EKS repositório da Amazon:

    • <account number>— Substitua AWS pelo ID da conta na qual você deseja implantar a solução. 

    • <zone id>: substitua pelo ID de zona do Route 53 do nome de domínio. 

    • <node_group_role>— Substitua pelo nome da função AWS Identity and Access Management (IAM) associada aos EKS nós da Amazon.

    • <namespace>— Substitua pelo namespace Kubernetes no qual você implanta o NGINX Ingress Controller e o aplicativo de amostra.

    • <application-domain-name>— Substitua pelo nome de DNS domínio do Route 53.

Limitações

  • Esse padrão não descreve como alternar certificados e apenas demonstra como usar certificados com microsserviços na Amazon. EKS 

Arquitetura

O diagrama a seguir mostra o fluxo de trabalho e os componentes da arquitetura desse padrão.

Fluxo de trabalho para configurar a criptografia para aplicativos na Amazon EKS usando o cert-manager e o Let's Encrypt.

O diagrama mostra o seguinte fluxo de trabalho:

  1. Um cliente envia uma solicitação para acessar o aplicativo com o DNS nome.

  2. O registro do Route 53 é um CNAME para o Network Load Balancer.

  3. O Network Load Balancer encaminha a solicitação para o NGINX Ingress Controller que está configurado com um ouvinte. TLS A comunicação entre o NGINX Ingress Controller e o Network Load Balancer HTTPS segue o protocolo.

  4. O NGINX Ingress Controller executa o roteamento baseado em caminhos com base na solicitação do cliente ao serviço do aplicativo.

  5. O serviço do aplicativo encaminha a solicitação para o pod do aplicativo. O aplicativo é projetado para usar o mesmo certificado chamando segredos.

  6. Os pods executam o aplicativo de amostra usando os certificados do gerenciador de certificados. A comunicação entre o NGINX Ingress Controller e os pods usa. HTTPS

Observação: o gerenciador de certificados é executado em seu próprio namespace. Ele usa uma função de cluster do Kubernetes para provisionar certificados como segredos em namespaces específicos. Você pode anexar esses namespaces aos pods de aplicativos e NGINX ao Ingress Controller.

Ferramentas

AWSserviços

Outras ferramentas

  • O gerenciador de certificado é um complemento do Kubernetes que solicita certificados, os distribui para contêineres do Kubernetes e automatiza a renovação de certificados.

  • NGINXO Ingress Controller é uma solução de gerenciamento de tráfego para aplicativos nativos da nuvem em Kubernetes e ambientes em contêineres.

Épicos

TarefaDescriçãoHabilidades necessárias

Crie uma zona hospedada no Route 53.

Faça login no AWS Management Console, abra o console do Amazon Route 53, escolha Hosted zones e, em seguida, escolha Create hosted zone. Crie uma zona hospedada pública e registre o ID da zona. Para obter mais informações, consulte Criar uma zona hospedada pública na documentação do Amazon Route 53.

Nota: ACME DNS 01 usa o DNS provedor para publicar um desafio para o cert-manager emitir o certificado. Esse desafio pede que você prove que controla o seu nome DNS de domínio colocando um valor específico em um TXT registro sob esse nome de domínio. Depois que o Let's Encrypt fornece um token ao seu cliente, ele cria um TXT registro derivado desse token e da chave da sua conta, e coloca esse registro em_acme-challenge.<YOURDOMAIN>. ACME Em seguida, o Let's Encrypt consulta o DNS para esse registro. Se encontrar uma correspondência, você pode continuar a emitir um certificado.

AWS DevOps
TarefaDescriçãoHabilidades necessárias

Crie a IAM política para o cert-manager.

É necessária uma IAM política para fornecer ao cert-manager permissão para validar que você é proprietário do domínio do Route 53. O policy.json exemplo IAM de política é fornecido no 1-IAMRole diretório da nd-to-end criptografia GitHub E clonada no EKS repositório da Amazon.

Digite o comando a seguir AWS CLI para criar a IAM política.

aws iam create-policy \
  --policy-name PolicyForCertManager \
  --policy-document file://policy.json
AWS DevOps

Crie a IAM função para cert-manager.

Depois de criar a IAM política, você deve criar uma IAM função. A IAM função de trustpolicy.json exemplo é fornecida no 1-IAMRole diretório.

Digite o comando a seguir AWS CLI para criar a IAM função.

aws iam create-role \
  --role-name RoleForCertManager \
  --assume-role-policy-document file://trustpolicy.json
AWS DevOps

Anexe a política ao perfil.

Digite o comando a seguir AWS CLI para anexar a IAM política à IAM função. AWS_ACCOUNT_IDSubstitua pelo ID da sua AWS conta. 

aws iam attach-role-policy \
  --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \
  --role-name RoleForCertManager
AWS DevOps
TarefaDescriçãoHabilidades necessárias

Implante o NGINX Ingress Controller.

Instale a versão mais recente do nginx-ingress usando o Helm. Você pode modificar a configuração nginx-ingress de acordo com seus requisitos antes de implantá-la. Esse padrão usa um Network Load Balancer anotado voltado para o interior e que está disponível no diretório 5-Nginx-Ingress-Controller. 

Instale o NGINX Ingress Controller executando o seguinte comando Helm a partir do 5-Nginx-Ingress-Controller diretório.

helm install test-nginx nginx-stable/nginx-ingress  -f  5-Nginx-Ingress-Controller/values_internal_nlb.yaml

AWS DevOps

Verifique se o NGINX Ingress Controller está instalado.

Digite o comando helm list. A saída deve mostrar que o NGINX Ingress Controller está instalado.

AWS DevOps

Crie um registro A da Route 53.

O registro A aponta para o Network Load Balancer criado pelo NGINX Ingress Controller.

  1. Obtenha o DNS nome do Network Load Balancer. Para obter instruções, consulte Como obter o DNS nome de um balanceador de ELB carga.

  2. No console do Amazon Route 53, escolha zonas hospedadas.

  3. Selecione a zona hospedada pública na qual você deseja criar o registro e escolha Criar registro.

  4. Insira um nome para o registro. 

  5. Em Tipo de registro, escolha A - Encaminha o tráfego para IPv4 e alguns AWS recursos.  

  6. Ative o Alias.

  7. Em Rotear tráfego para, faça o seguinte:

    1. Escolha um Alias para Network Load Balancer.

    2. Escolha a AWS região na qual o Network Load Balancer está implantado.

    3. Insira o DNS nome do Network Load Balancer.

  8. Escolha Create records (Criar registros).

AWS DevOps
TarefaDescriçãoHabilidades necessárias

Implantar NGINX VirtualServer.

O NGINX VirtualServer recurso é uma configuração de balanceamento de carga que é uma alternativa ao recurso de entrada. A configuração para criar o NGINX VirtualServer recurso está disponível no nginx_virtualserver.yaml arquivo no 6-Nginx-Virtual-Server diretório. Digite o comando a seguir kubectl para criar o NGINX VirtualServer recurso.

kubectl apply -f  nginx_virtualserver.yaml

Importante: certifique-se de atualizar o nome de domínio do aplicativo, o segredo do certificado e o nome do serviço do aplicativo no arquivo nginx_virtualserver.yaml.

AWS DevOps

Verifique NGINX VirtualServer se foi criado.

Digite o comando a seguir kubectl para verificar se o NGINX VirtualServer recurso foi criado com sucesso.

kubectl get virtualserver

Observação: verifique se a coluna Host corresponde ao nome de domínio do seu aplicativo.

AWS DevOps

Implante o servidor NGINX web com TLS ativado.

Esse padrão usa um servidor NGINX web TLS habilitado como aplicativo para testar a end-to-end criptografia. Os arquivos de configuração necessários para implantar o aplicativo de teste estão disponíveis no diretório demo-webserver. 

Execute o seguinte comando no kubectl para implantar o aplicativo.

kubectl apply -f nginx-tls-ap.yaml

AWS DevOps

Verifique se os recursos do aplicativo de teste foram criados.

Insira os seguintes comandos kubectl para verificar se os recursos necessários foram criados para o aplicativo de teste:

  • kubectl get deployments

    Observação: valide a coluna Ready e a coluna Available.

  • kubectl get pods | grep -i example-deploy

    Observação: os pods devem estar no estado running.

  • kubectl get configmap 

  • kubectl get svc 

AWS DevOps

Valide o aplicativo.

  1. Digite o comando a seguir substituindo o <application-domain-name> pelo DNS nome Route53 que você criou anteriormente.

    curl --verbose https://<application-domain-name>

  2. Verifique se você consegue acessar o aplicativo.

AWS DevOps

Recursos relacionados

AWSrecursos

Outros recursos