

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 no Amazon EKS usando cert-manager e Let's Encrypt
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt"></a>

*Mahendra Revanasiddappa e Vasanth Jeyaraj, Amazon Web Services*

## Resumo
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-summary"></a>

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 Amazon API Gateway, algumas organizações exigem criptografia. end-to-end

Esse padrão usa o controlador do Ingress NGINX 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 o TLS mútuo com a entrada do Kubernetes.

Esse padrão é destinado a organizações que exigem autenticação mútua entre todos os microsserviços em seus aplicativos. O TLS mútuo reduz a carga de manter nomes de usuário ou senhas e também pode usar a estrutura de segurança turnkey. 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 na GitHub [End-to-end criptografia no repositório Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme) para mostrar como um microsserviço é executado com end-to-end criptografia no Amazon EKS. A abordagem do padrão usa o [gerenciador de certificados](https://cert-manager.io/docs/), um complemento do Kubernetes, com o [Let's Encrypt](https://letsencrypt.org/) 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 Gerenciador de certificados automatiza o provisionamento sob demanda e a alternância de certificados quando um novo microsserviço é implantado no Amazon EKS. 

**Público-alvo**

Esse padrão é recomendado para usuários com experiência com Kubernetes, TLS, Amazon Route 53 e Sistema de Nomes de Domínio (DNS).

## Pré-requisitos e limitações
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-prereqs"></a>

**Pré-requisitos **
+ Uma conta AWS ativa
+ Um cluster do Amazon EKS existente.
+ AWS Command Line Interface (AWS CLI) versão 1.7 ou superior, instalada e configurada no macOS, Linux ou Windows
+ O utilitário de linha de comando `kubectl`, instalado e configurado para acessar o cluster Amazon EKS. Para obter mais informações, consulte [Instalação do kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) na documentação do Amazon EKS.
+ O nome de um DNS existente para testar o aplicativo. Para obter mais informações, consulte [Registrar nomes de domínio usando o Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html) na documentação do Amazon Route 53. 
+ A versão mais recente do [Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html) instalada em sua máquina local. Para obter mais informações sobre isso, consulte [Usando o Helm com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html) na documentação do Amazon EKS e no repositório do GitHub [Helm](https://github.com/helm/helm). 
+ A GitHub [End-to-end criptografia no repositório Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme), clonada em sua máquina local. 
+ Substitua os seguintes valores nos `trustpolicy.json` arquivos `policy.json` e da GitHub [End-to-end criptografia clonada no repositório Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme):
  + `<account number>`: substitua pelo ID da conta da AWS para a 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 do AWS Identity and Access Management perfil do (IAM) associado aos nós do Amazon EKS.
  + `<namespace>`: substitua pelo namespace Kubernetes no qual você implanta o controlador do Ingress NGINX e o aplicativo de amostra.
  + `<application-domain-name>`: substitua pelo nome de domínio DNS do Route 53.

**Limitações**
+ Esse padrão não descreve como alternar certificados e apenas demonstra como usar certificados com microsserviços no Amazon EKS. 

## Arquitetura
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-architecture"></a>

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

![\[Fluxo de trabalho para configurar criptografia em aplicações no Amazon EKS usando “cert-manager” e “Let’s Encrypt”.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/images/pattern-img/9aa3ee9e-73db-41f5-a467-b5c47fef496e/images/40692ede-6fb3-474e-8c9e-85c51529e8ad.png)


O diagrama mostra o seguinte fluxo de trabalho:

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

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

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

1. O controlador do Ingress NGINX executa o roteamento baseado em caminhos conforme a solicitação do cliente ao serviço do aplicativo.

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

1. Os pods executam o aplicativo de amostra usando os certificados do gerenciador de certificados. A comunicação entre o controlador do Ingress NGINX 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 ao controlador do Ingress NGINX.  | 
| --- |

## Ferramentas
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-tools"></a>

**Serviços da AWS**
+ O [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) é um serviço gerenciado que você pode usar para executar o Kubernetes na AWS , eliminando a necessidade de instalar, operar e manter seus próprios nós ou ambiente de gerenciamento ou nós do Kubernetes.
+ O [Balanceador de carga Elastic](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) distribui automaticamente seu tráfego de entrada entre vários destinos, contêineres e endereços IP.
+ O [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) ajuda você a gerenciar com segurança o acesso aos seus recursos da AWS, controlando quem está autenticado e autorizado a usá-los.
+ O [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) é um serviço web de DNS altamente disponível e escalável.

**Outras ferramentas**
+ O [gerenciador de certificado](https://cert-manager.io/docs/installation/supported-releases/) é um complemento do Kubernetes que solicita certificados, os distribui para contêineres do Kubernetes e automatiza a renovação de certificados.
+ [O controlador do Ingress NGINX](https://kubernetes.github.io/ingress-nginx/) é uma solução de gerenciamento de tráfego para aplicativos nativos de nuvem em Kubernetes e ambientes em contêineres.

## Épicos
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-epics"></a>

### Crie e configure uma zona hospedada pública com o Route 53
<a name="create-and-configure-a-public-hosted-zone-with-route-53"></a>


| Tarefa | Description | Habilidades necessárias | 
| --- | --- | --- | 
| Crie uma zona hospedada no Route 53. | Faça login no Console de Gerenciamento da AWS, abra o console do Amazon Route 53, escolha **zona hospedada** e, em seguida, escolha **Criar zona hospedada**. Crie uma zona hospedada pública e registre o ID da zona. Para obter mais informações, consulte [Criar uma zona hospedada pública](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html) na documentação do Amazon Route 53.O ACME DNS01 usa o provedor de DNS para publicar um desafio, permitindo que o “cert-manager” emita o certificado. Esse desafio pede que você comprove que controla o DNS do seu nome de domínio colocando um valor específico em um registro TXT sob esse nome de domínio. Depois que o Let's Encrypt fornece um token ao seu cliente ACME, seu cliente cria um registro TXT derivado desse token e da chave da sua conta, e coloca esse registro em `_acme-challenge.<YOURDOMAIN>`. Depois, o Let's Encrypt consulta o DNS desse registro. Se encontrar uma correspondência, você pode continuar a emitir um certificado. | AWS DevOps | 

### Configure um perfil do IAM para permitir que o gerenciador de certificado acesse a zona hospedada pública
<a name="configure-an-iam-role-to-allow-cert-manager-to-access-the-public-hosted-zone"></a>


| Tarefa | Description | Habilidades necessárias | 
| --- | --- | --- | 
| Crie a política do IAM para o gerenciador de certificado.  | É necessária uma política do IAM para fornecer ao gerenciador de certificado permissão para validar que você é proprietário do domínio Route 53. O `policy.json` exemplo de política do IAM é fornecido no `1-IAMRole` diretório na GitHub [End-to-end criptografia clonada no repositório Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme).Use o seguinte comando da AWS CLI para criar a política do IAM.<pre>aws iam create-policy \<br />  --policy-name PolicyForCertManager \<br />  --policy-document file://policy.json</pre> | AWS DevOps | 
| Crie o perfil do IAM para gerenciador de certificado. | Após criar a política do IAM, é necessário criar um perfil do IAM. O exemplo `trustpolicy.json` de perfil do IAM é fornecido no diretório `1-IAMRole`.Use o seguinte comando da AWS CLI para criar o perfil do IAM.<pre>aws iam create-role \<br />  --role-name RoleForCertManager \<br />  --assume-role-policy-document file://trustpolicy.json</pre> | AWS DevOps | 
| Anexe a política ao perfil. | Execute o comando a seguir para anexar a política do IAM ao perfil do IAM. Substitua `AWS_ACCOUNT_ID` pelo seu ID da sua conta da AWS. <pre>aws iam attach-role-policy \<br />  --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \<br />  --role-name RoleForCertManager</pre> | AWS DevOps | 

### Configure o controlador de entrada NGINX no Amazon EKS
<a name="set-up-the-nginx-ingress-controller-in-amazon-eks"></a>


| Tarefa | Description | Habilidades necessárias | 
| --- | --- | --- | 
| Implante o controlador de entrada NGINX. | 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 controlador de entrada NGINX executando o seguinte comando Helm a partir do diretório `5-Nginx-Ingress-Controller`.`helm install test-nginx nginx-stable/nginx-ingress  -f  5-Nginx-Ingress-Controller/values_internal_nlb.yaml` | AWS DevOps | 
| Verifique se o controlador do Ingress NGINX está instalado. | Digite o comando `helm list`. A saída deve mostrar que o controlador do Ingress NGINX está instalado. | AWS DevOps | 
| Crie um registro A da Route 53. | O registro A aponta para o Network Load Balancer criado pelo controlador do Ingress NGINX.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 

### Configure o NGINX no VirtualServer Amazon EKS
<a name="set-up-nginx-virtualserver-on-amazon-eks"></a>


| Tarefa | Description | Habilidades necessárias | 
| --- | --- | --- | 
| Implante o NGINX VirtualServer. | O VirtualServer recurso NGINX é uma configuração de balanceamento de carga que é uma alternativa ao recurso de entrada. A configuração para criar o VirtualServer recurso NGINX está disponível no `nginx_virtualserver.yaml` arquivo no `6-Nginx-Virtual-Server` diretório. Digite o comando a seguir `kubectl` para criar o recurso NGINX VirtualServer .`kubectl apply -f  nginx_virtualserver.yaml`Certifique-se de atualizar o nome de domínio da aplicação, o segredo do certificado e o nome do serviço da aplicação no arquivo `nginx_virtualserver.yaml`. | AWS DevOps | 
| Verifique se o NGINX VirtualServer foi criado. | Insira o comando a seguir `kubectl` para verificar se o VirtualServer recurso NGINX foi criado com sucesso.`kubectl get virtualserver`Verifique se a coluna `Host` corresponde ao nome de domínio da sua aplicação. | AWS DevOps | 
| Implante o servidor web NGINX com o TLS ativado. | Esse padrão usa um servidor web NGINX com TLS habilitado como aplicativo para testar a criptografia. end-to-end 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:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 
| Valide o aplicativo. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 

## Recursos relacionados
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-resources"></a>

**Recursos da AWS**
+ [Criar registros usando o console do Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html) (documentação do Amazon Route 53)
+ [Como usar um Network Load Balancer com o controlador de entrada NGINX no Amazon EKS](https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/) (publicação no blog da AWS)

**Outros recursos**
+ [Route 53](https://cert-manager.io/docs/configuration/acme/dns01/route53/) (documentação do gerenciador de certificado)
+ [Como configurar o DNS01 Challenge Provider](https://cert-manager.io/docs/configuration/acme/dns01/) (documentação do gerenciador de certificado)
+ [Desafio do Let's Encrypt DNS](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) (documentação do Let's Encrypt)