Você está na página 1de 9

 

ngnix com HTTPS 


PRIMEIRO SEMESTRE DE 2020 
Residência TI-JFRN 
PROFESSOR: ANDRÉ SOLINO 
andresolino@imd.ufrn.br 
ALUNA: ANA AMARANTE 
anapma22@gmail..com 
 

14 de abril de 2020 

Este  documento  foi  desenvolvido  durante a disciplina DevOps na Residência em tecnologia 


da  informação  aplicada  à  área  jurídica  -  turma  JF/IMD,  na  área  de  Redes  e  Infraestrutura, 
ministrado pelo Prof Me. André Solino.   

O  objetivo  deste  é  ser  um  tutorial  de  instalação  do  HTTPS  com  o  nginx.  Os  certificados 
serão gerados por meio do Let’s Encrypt. 

   

 

 

 
 

Sumário 
14 de abril de 2020 1 
Sumário 2 
Histórico de versões 2 
Definição teórica 2 
Instalando o Cert-Manager 3 
Implantando o emissor de produção 4 
Configuração do yaml principal 5 
Configuração do yaml referente ao certificado 7 
Verificação do resultado 7 
Referências 9 

Histórico de versões 

Versão  Alteração  Autor  Data 

1.0  Criação de arquivo  Ana Paula  14/04/2020 


inicial 

1.1  Alteração no yaml  Ana Paula  19/04/2020 


certificate.yaml 

Definição teórica 

O  HTTPS  é  uma  parte  fundamental  nos  deploys  de  aplicações  para  internet.  Ele  permite 
que  as  conexões  entre cliente e servidor sejam encriptografadas. A sua instalação pode ser 
complexa,  porém  o  Let’s  Encrypt  promove  os  certificados  SSL/TLS  e  uma  API  para  gerar 
esses certificados. 

O  HTTPS  alinhado  ao  Kubernetes  nos  permite  especificar  toda  nossa  aplicação,  no 
contexto de réplicas, rede e certificados, tudo como IaC. 

 

 

 
 

A partir deste tutorial já temos o cluster configurado com o master e os workers, HAProxy e 
NFS configurado. Isso está explicado nos tutoriais anteriores. 

Instalando o Cert-Manager 
1. Vamos instalar o cert-manager, ele é ​ um serviço do Kubernetes que fornece 
certificados TLS gratuitos do ​Let’s Encrypt​ e outras autoridades certificadoras​. 
2. Antes de iniciar a instalação do cert-manager, é preciso criar um namespace que ele 
possa operar: 

kubectl create namespace cert-manager 

3. Agora, vamos pegar a versão mais atualizada e estável do cert-manager com o yaml 
pronto.  

Todos os recursos (CustomResourceDefinitions, cert-manager, namespace, e 


webhook component) estão definidos aqui. 

a. Caso queira verificar se já existe outra versão mais atualizada, entre neste 
link​ e verifique. Em caso positivo, troque o “​0.14.2​
” pelo número da nova 
versão no comando abaixo. 

kubectl apply --validate=false -f 


https://github.com/jetstack/cert-manager/releases/download/v0.14.2/cer
t-manager.yaml 

4. A partir do comando anterior, os pods devem ter sido criados. Use o comando 
abaixo para verificar. 

a. É normal que o pod cert-manager-webhook não inicie junto com os outros, 


pode levar de 2 a 3 minutos para que ele mude o status para Running. Isso 
acontece em razão dos ativos TLS necessários para o webhook funcionem 
sejam provisionados.  

kubectl get pods --namespace cert-manager 

Figura 1 - Saída esperada do comando para verificação dos pods 

 

 

 
 

Implantando o emissor de produção 

5. Antes de começar a emitir certificados, você deve configurar pelo menos um 
recurso Issuer, o emissor ou ClusterIssuer no seu cluster. Ele vai especificar a 
autoridade certificadora da qual será possível obter os certificados x509 assinados.  

Vamos criar o arquivo. 

vim prod_issuer.yaml  
 

6. Insira as definições abaixo no arquivo e salve em seguida. Se atente para o que está 
em negrito. 

Será criado um objeto de ClusterIssuer chamado de letsencrypt-prod para usar o 


servidor de preparação do Let’s Encrypt. Será criado um Kubernetes Secret 
chamado letsencrypt-staging para armazenar a chave privada da conta ACME.  

Também habilitamos o mecanismo de desafio do HTTP-01. Segundo o site do Let’s 


Encrypt, este é o tipo de desafio mais comum hoje em dia. O Let’s Encrypt fornece 
um token para o seu cliente ACME, e o cliente ACME coloca um arquivo no servidor 
web em http: // <YOUR_DOMAIN> /.well-known/acme-challenge/ <TOKEN>. Este 
arquivo contém o token, além de uma impressão digital da chave da sua conta. 

Depois que o cliente ACME informar o Let's Encrypt que o arquivo está pronto, o 
Let’s Crypt criptografará o arquivo. Se as verificações de validação obtiverem as 
respostas válidas do seu servidor web, a validação será considerada bem-sucedida e 
você poderá emitir seu certificado. Se as validações falharem, você precisará tentar 
novamente com um novo certificado. 

apiVersion: cert-manager.io/v1alpha2 
kind: ClusterIssuer 
metadata: 
name: letsencrypt-prod 
namespace: cert-manager 
spec: 
acme: 
  server:  https://acme-v02.api.letsencrypt.org/directory  #  The  ACME 
server URL 
  email:  ​
seu_email@test.com  ​ #  Email  address  used  for  ACME 
registration 
  privateKeySecretRef:  ​#  ​
Name  of  a  secret  used  to  store  the  ACME 
account private key 
name: letsencrypt-prod ​#isso é pedido no ingress 
solvers: #​ Enable the HTTP-01 challenge provider 
- http01: 
ingress: 

 

 

 
 

  class:  haproxy  ​
#muda  de  acordo  do  ingress  que  você  tiver 
configurado anteriormente 
7. Aplique o issuer configurado. 

kubectl create -f prod_issuer.yaml 


 

Configuração do yaml principal 


8. Agora vamos configurar o yaml que contém o deploy, service e ingress. 

vim lets-nginx.yaml  
9. Insira as definições abaixo e salve o arquivo. 

apiVersion: apps/v1 
kind: Deployment #​deploy the Ingress Controller pod 
metadata: 
labels: 
run: nginx 
name: lets-nginx 
# namespace: default #which to place the resources 
spec: 
replicas: 1 
selector: 
matchLabels: 
run: nginx 
template: 
metadata: 
labels: 
run: nginx 
spec: 
volumes: 
- name: nfs1 
persistentVolumeClaim: 
claimName: nfs-pvc 
containers: 
- image: nginx 
imagePullPolicy: Always 
name: nginx 
ports: 
- containerPort: 80 
protocol: TCP 
volumeMounts: 
- name: nfs1 #​mesmo nome do volume criado neste deploy 
  mountPath:  /usr/share/nginx/html  #path  que  será  criado 
dentro do container 
 

 

 

 
 

--- 
 
apiVersion: v1 
kind: Service​#allow traffic to reach the Ingress Controller 
metadata: 
labels: 
run: nginx 
  name:  lets-nginx  ​ #nome  do  service  que  deve  ter  o  mesmo  valor  que 
serviceName  no  Ingress,  caso  contrário  o  Endpoint  não  sera  encontrado 
#namespace: default #which to place the resources 
spec: 
selector: 
run: nginx 
ports: 
- name: http 
port: 80 
targetPort: 80 
 
--- 
 
apiVersion: extensions/v1beta1 
kind: Ingress 
metadata: 
name: nginx 
annotations: 
# kubernetes.io/ingress.class: "haproxy" 
  cert-manager.io/cluster-issuer:  "letsencrypt-prod"  ​ #foi  setado  no 
prod_issuer.yaml 
certmanager.k8s.io/acme-challenge-type: http01 
# namespace: cert-manager 
spec: 
tls: 
- hosts: 
- nginx-lets.34.66.16.93.nip.io ​#altere com seu IP 
secretName: lets-tls 
rules: 
- host: nginx-lets.34.66.16.93.nip.io​#altere com seu IP 
http: 
paths: 
- path: / 
backend: 
serviceName: lets-nginx 
servicePort: 80 
10. Aplique as alterações. 

kubectl apply -f lets-nginx.yaml 

Configuração do yaml referente ao certificado 

 

 

 
 

11. Por fim e não menos importante, vamos alterar o arquivo chave para o certificado. 

vim cert.yaml 
12. Insira o que está abaixo e salve o arquivo. 

apiVersion: cert-manager.io/v1alpha2 
kind: Certificate 
metadata: 
name: certificate-nginx 
namespace: default 
spec: 
secretName: nginx-tls 
duration: 24h 
renewBefore: 12h 
commonName: nginx-lets.34.66.16.93.nip.io ​#altere para seu IP 
dnsNames: 
- nginx-lets.34.66.16.93.nip.io # ​altere para seu domínio 
issuerRef: 
name: letsencrypt-prod 
kind: ClusterIssuer 
apiVersion: cert-manager.io/v1alpha2 
kind: Certificate 
metadata: 
name: certificate-nginx 
namespace: cert-manager 
spec: 
secretName: nginx-tls 
duration: 24h 
renewBefore: 12h 
commonName: nfs-nginx.35.226.108.169.nip.io #​altere para seu IP 
dnsNames: 
- nginx-lets.34.66.16.93.nip.io #
​altere para seu domínio 
issuerRef: 
name: letsencrypt-prod 
kind: ClusterIssuer 
13. Aplique as configurações: 

kubectl create -f cert.yaml 


 

Verificação do resultado 
14. Pode demorar alguns minutos, mas você verá que o certificado foi criado 
corretamente. Primeiro vamos verificar o clusterissuers: 

kubectl get clusterissuers 

 

 

 
 

 
Figura 2 - Saída esperada do comando para verificação dos clusterissuers 

15. Agora, vamos verificar o certificaterequest. A FIgura 3 é o final do comando abaixo: 

kubectl describe certificaterequest 


 

 
Figura 3 - Saída esperada do final do comando para verificação do certificaterequest 

16. Após isso, você já pode ir no seu host e verificar se o acesso acontece com HTTPS 
por meio de um certificado válido.  

 
Figura 4 - Host setado nos yamls acessando com HTTPS 

 

 

 
 

Referências 

1. Como configurar um Nginx Ingress com Cert-Manager no Kubernetes da plataforma 


DigitalOcean. Disponível em: 
<​https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingres
s-with-cert-manager-on-digitalocean-kubernetes-pt​>. Acessado em: 19 abr. 2020. 

2. Kubernetes. cert-manager. Disponível em: 


<​https://cert-manager.io/docs/installation/kubernetes/​>. Acessado em: 19 abr. 2020. 

3. HTTP01. cert-manager. Disponível em: 


<​https://letsencrypt.org/docs/challenge-types/#http-01-challenge​>. Acessado em: 19 
abr. 2020. 

4. Challenge Types. Let’s Encrypt. Disponível em: 


<​https://letsencrypt.org/docs/challenge-types/#http-01-challenge​. Acessado em: 19 
abr. 2020. 

 

Você também pode gostar