DEV Community: Isadora de Menezes

Usando Ngnix-Controller com MetalLB no meu Home Lab

Isadora de Menezes — Sun, 19 Nov 2023 17:12:29 +0000

Fala pessoal! Estou estudando Kubernetes (Fazendo o sensacional PICK da LinuxTips) e resolvi compartilhar o setup que preparei para o meu home lab.

Meu objetivo é ter o Nginx Controller balanceando as requisições para os meus serviços e diponível num FQDN (Full Qualified Domain Name) que eu separei pra ele.

Os manifestos usados na configuração podem ser achados aqui.

Esse post está divido em:

Setup Inicial
Conceitos Importantes
Tipos de Serviço
O que é ingress (com foco no Nginx Controller)
O que é Metal LB
Configurando tudo

Setup Inicial

Inicialmente meu cluster tem 1 Control Plane e 2 Workers, os três estão rodando na AWS, usando Ubuntu 22.04, em instâncias t3.mediume possuem IP's públicos efêmeros (eles mudam toda vez que eu reincio essas máquinas).

Eu segui uma instalação básica do K8S, e me guiei principalmente pelo Descomplicando o Kubernetes.

Conceitos Importantes

Disclaimer: Se, assim como eu você está começando a estudar o Kubernetes, ou se quer refrescar alguns conceitos, os próximos tópicos são pra você. Caso você já tenha uma boa ideia de toda a base, eu sugiro pular para o tópico "Configurando Tudo".

Tipos de Serviço

Antes de mais nada, um serviço no Kubernetes é uma forma de expor uma aplicação que esteja rodando num Pod na rede, de forma que se um Pod for recriado, ou se mais Pods de uma aplicação forem criados, todas as instâncias sejam acessíveis através do mesmo "canal".

Quando um serviço é criado (seja através do kubectl create svc ou do kubectl expose deploy), um objeto chamado "Endpoint" é criado junto. Esse objeto mantém a lista com os IPs de todos os Pods ativos rodando aquele determinado serviço. Quando um Pod é criado ou destruído a lista é atualizada.

Por exemplo, na imagem abaixo 2 Pods com App-A e App-B estão rodando. É importante relembrar que as aplicaçoes dentro desses Pods compartilham recursos como o endereço IP. Ao criar um serviço para expor a App-A, o Kubernetes identifica os endereços de todos os Pods rodando a aplicação (através das labels e selectors) e cria o serviço apontando para esses Pods. Para acessar a App-A de dentro do cluster nesse caso, é possível executar um curl http://10.100.100.100 e a requisição será encaminhada para qualquer dos Pods disponívels.

Finalmente, os serviços podem ser de quatro tipos:

Cluster IP: Esse é o tipo padrão de serviços, ele expõe a aplicação apenas dentro do cluster.
Load Balancer: Expõe a aplicação através de um load balancer, com IP fixo fora do cluster.
Node Port: Torna a aplicação acessível atravpes de uma porta específica em cada nó do cluster. Permite o acesso externo ao cluster.
External Name: É uma exceção aos demais, invés de usar labels para definir os endpoints, usa DNS. É usado para apontar para serviços externos ao cluster.

O que é um Ingress?

O Ingress é um objeto no Kubernetes que ajuda no gerenciamento de acesso aos serviços. Através dele é possível definir regras de acesso, rotas, SSL certificados (com integrações) e outras coisas mais.

Para funcionar, o Ingress requer um Ingress Controller, que não é criado na instalação padrão no Kubernetes. É através do controller que toda a configuração do Ingress será feita, e há várias opções disponíveis. Aqui nessa página você pode checar a lista completa.

Um dos controllers mais utilizados (e um dos três suportados oficialmente projeto Kubernetes) é o Nginx-Controller. Ele é uma implementação do Nginx e pode fazer o balancemaento de requisições WebSocket, gRPC, TCP e UDP, além de suportar o redirecionamento de rotas e terminação TLS/SSL.

O que é MetalLB:

O MetalLB é uma implementação de LoadBalancer para Kubernetes que rodam em bare-metal (fora da cloud). Ele é capaz de alocar IP's para serviços do tipo LoadBalancer e essa é a principal característica que eu vou utilizar no meu HomeLab.

É importante ressaltar que o MetalLB não cria os IP's, ele apenas faz a alocação de IP's baseado em ranges definidos pelo usuário.

Configurando tudo

Eu sugiro começar a configuração pelo MetalLB

Minha configuração final é a seguinte:

O guia completo da Instalação e Configuração pode ser encontrado aqui.

O primeiro passo para a instalação é habilitar o modo 'strict ARP':

kubectl edit configmap -n kube-system kube-proxy

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

Após sair salvando (:wq!), é hora de fazer a instalção do MetalLB:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml

Esse comando vai criar o namespace metallb-system com um controller no control-plane e um speaker em cada nó do cluster. Após todos os pods estarem rodando, alguma configuração é necessária:

ipaddrpool.yml

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: k8s-lab
  namespace: metallb-system
spec:
  addresses:
  #No meu caso esses são os IPs que eu tenho disponíveis, caso queira aplicar no seu ambiente, atualize esses IPs
  - 54.152.233.228/32 
  - 54.167.93.192/32

Como eu estou usando a configuração via ARP, também é necessário criar um L2Advertsiment:

L2Advertsiment.yml

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: k8s-lab
  namespace: metallb-system
spec:
  ipAddressPools:
  - k8s-lab

E então:

k apply -f ipaddrpool.yml
k apply -f L2Advertsiment.yml

Checando se tudo está criado:

A configuração do MetalLB está feita, para validar, precisamos criar um serviço. Optei pelo bom e velho Nginx:

nginx-deployment.yml


apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 0.5
            memory: 256Mi
          requests:
            cpu: 0.3
            memory: 64Mi

k apply -f nginx-deployment.yml

A forma mais rápida de validar se o MetalLB está sendo capaz de fornecer IPs para os serviços, é expondo o deploy que acabamos de criar utilizando o serviço do tipo loadBalancer:

kubectl expose deploy nginx --port 80 --target-port 80 --type LoadBalancer

E com um curl 54.167.93.192 recebemos a mensagem padrão do Nginx.

Okay, o MetalLB está funcionando e é possível acessar o serviço através do IP de dentro do cluster, mas eu quero que esse serviço esteja disponível no meu FQDN k8s-lab.ibmenezes.com. É hora de installar o nginx-controller.

O getting started dessa instalação pode ser encontrado aqui.

Como estamos em uma instalação 'bare-metal', a instalação será:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/baremetal/deploy.yaml

Após alguns segundos (talvez minutos) temos o pod do ingress-controller rodando no Control Plane. Além disso, o serviço do ingress-controler é criado no namespace ingress-nginx, e o External IP é atribuído pelo MetalLB:

Nesse momento já é possível acessar o ingress controller no browser com https://54.152.233.228:31333/. Esse acesso retorna um 503 porque não existe nenhum service associado a ingress nesse momento.

Para corrigir isso, a criação do ingress:

ingress.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: k8s-lab
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    cert-manager.io/issuer: "letsencrypt-staging"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - k8s-lab.ibmenezes.com
    secretName: "k8s-lab-tls"
  rules:
  - host: k8s-lab.ibmenezes.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx
            port:
              number: 80

Aqui algumas coisas são importantes:
A primeira annotation nginx.ingress.kubernetes.io/rewrite-target: / determina que todas as vezes que uma requisição for encaminhada para a /, ela será redirecionada ao path (que falaremos mais abaixo).

A segunda anotação, cert-manager.io/issuer: "letsencrypt-staging" é associada à criação de certificados SSL usando o letsencrypt. Nesse setup não iremos a fundo nisso, na próxima sessão explico os motivos. O bloco tls também está associado ao certificado.

Já nas especificações, o bloco de rules vai determinar:

- host: k8s-lab.ibmenezes.com -> O FQDN onde o ingress espera ouvir a requisição 
http.paths.path -> O caminho da applicação para onde o trafego será redirecionado quando o usuário digitar `/` (da annotation)
http.paths.pathType ->  O tipo de path, esse valor é requerido quando o tipo é Prefix ou Exact
http.paths.backend -> as configurações do serviço para o qual o ingress estará apontando

Quase tudo pronto, alguns detalhes finais:

É importante remover o serviço que criamos anteriormente:

kubectl delete svc nginx

Isso vai liberar o IP anteriormente atribuido ao serviço e prevenir que a gente valide o serviço errado. Antes de criar o ingress é importante criar o serviço definido em http.paths.backend. Como eu defini o meu se chamando 'nginx', me basta:

kubectl expose deploy nginx --port 80

Para criar o ingress a partir do manifesto criado anteriormente basta executar:

kubectl apply -f ingress.yml

Com um describe é possível verificar que o ingress recebe o mesmo IP do ingress-controller recebeu anteriormente.

A última configuração necessária é no provedor de DNS, no meu caso eu criei uma entrada tipo A apontando para o IP do ingress.

Para validar o balanceamento, editei o index.html de cada Pod:

k exec -it nginx-f888bbf65-j94fk /bin/bash
echo "Eu sou o pod nginx-f888bbf65-j94fk" > /usr/share/nginx/html/index.html

k exec -it nginx-f888bbf65-tcmvz/bin/bash
echo "Eu sou o pod nginx-f888bbf65-tcmvz" > /usr/share/nginx/html/index.html

E, acessando 'https://k8s-lab.ibmenezes.com:31333' pelo browser temos:

Resumindo como tudo funciona de forma superficial:

Eu tenho uma entrada DNS 'k8s-lab.ibmenezes.com' do tipo A, aonde eu precisei atualizar o IP de destino;
A lista de IP's disponíveis para a virtualização foi feita a partir dos IP's públicos das minhas máquinas na AWS e passada para o MetalLB;
O MetalLB forneceu um dos IP's disponíveis para o nginx-controller
Ta pronto o sorvetinho! Agora eu consigo acessar meus serviços externamente.

Hashicorp Vault Operations Professional (HCVOP) - Minha experiência

Isadora de Menezes — Sat, 29 Jul 2023 19:19:01 +0000

Nesse post eu estou compartilhando como foi minha preparação e a experiência de fazer a certificação HCVOP-002 esse ano (2023). Ele está dividido em:

Introdução - Informações gerais sobre a certificação, o Vault, e promessas de novos posts
Informações mais específicas sobre a certificação - duração, nota de corte, conteúdo
Como eu me preparei
O dia da prova
O que eu sugiro praticar

É importante ressaltar que tudo o que será escrito aqui é baseado na minha experiência e eu vou usar esse termo várias vezes. Se você está pensando em fazer a certificação esse post não é um guia de estudos ou caminho das pedras, é apenas o caminho que eu fiz com o maior número de detalhes que eu posso fornecer. Não é minha intenção replicar qualquer questão do exame nesse post. Siga a documentação oficial da Hashicorp na sua preparação.

1. Introdução
A HCVOP é focada em pessoas que trabalham no deploy, configuração, gerenciamento e monitoramento do Hashicorp Vault (você pode conferir todos os detalhes na página da Hashicorp).

Se você não sabe o que é, para que serve ou do que se alimenta o Vault, eu pretendo iniciar uma sequência em breve (sem compromissos com datas por aqui) com alguns detalhes sobre o que é, como usar algumas funcionalidades e talvez com alguns laboratórios que eu ache interessante. Apenas para rápida contextualização, o Vault - desenvolvido pela Hashicorp - é uma ferramenta de segurança, focado em gerenciamento de segredos e dados sensíveis, que permite a manipulação segura desses dados durante todo o "ciclo de vida" deles. Quer saber mais agora mesmo? Dá uma olhada na página oficial do Vault. Nesse post eu vou assumir que você já conhece algumas terminologias sobre o Vault e as funcionalidades, então se algo ficar confuso por hoje espero que os próximos posts esclareçam.

2. A certificação segundo a Hashicorp

A primeira coisa é possível perceber quando a gente lê a página da Hashicorp é que esta não é uma certificação para quem usa o Vault só como cliente, essa prova - que tem parte teórica e prática - vai exigir que você saiba gerenciar o Vault em si, habilitar e configurar funcionalidades, monitorar os logs e identificar problemas por lá, usar as features enterprise (funcionalidades pagas) de Disaster Recovery e Replica Performance.

Os pré requisitos listados na página da documentação (o link ta ali em cima pessoal) são:

Ter passado na certificação Associate do Vault (Recomendado, não obrigatório). Alguns anos atrás eu fiz esse gist com algumas notas de quando fiz o exame.
Linux (listar e editar arquivos)
Redes
Experiência com PKI, incluindo PGP e TLS
Fundamentos de segurança da informação, incluindo segurança de redes e RBAC (Role Based Access Control)
Containers

A versão do Vault rodando no ambiente vai ser 1.8.0 ou maior (post em Julho de 2023). É importante saber exatamente qual versão está rodando na hora da prova porquê o acesso a documentação da API é liberado dentro do ambiente (nada de acesso ao learn.hashicorp.com), e você não quer perder tempo consultando a versão errada. Aqui no canto direito é possível selecionar as opções disponíveis.

A prova dura até 4 horas e isso inclui uma pausa de até 15 minutos.

O preço com retake (você pode refazer caso não passe na primeira) é $295 (em dólar).

A prova está disponível apenas em inglês, e é válida por 2 anos.

Como mencionado anteriormente, você vai encontrar questões teóricas - na minha foram algo entre 15 e 20 se não me engano - e práticas - 4 ou 6 cenários com 2 a 4 itens cada.

A Hashicorp disponibiliza um guia para preparação com:

Na página da certificação os tópicos estão divididos em:

Criar a configuração e executar o Vault em certo cenário - que será fornecido na hora da prova
Monitoração do Vault
Emprego do modelo de segurança do Vault
Criação de ambientes tolerantes à falha
Entendimento da integração com HSM
Escalabilidade para performance
Configuração de controle de acesso
Configuração do Vault agent

Sobre a pontuação mínima para passar na prova eu não consegui achar a informação atualizada, quando eu fiz acredito que era de 85%.

3. Minha preparação e dicas

Meu primeiro contato com o Vault foi através do curso da LinuxTips na primeira edição do Chama as Minas lá em 2020, mesmo ano que eu comecei a atuar profissionalmente na instalação dele em ambientes corporativos. Em 2021 eu tive a chance de fazer a certificação de nível associate para participar do programa de parceiros da Hashicorp e tudo isso serviu de aprendizado e experiência pra mim. Depois disso eu foquei em outras coisas, até que no começo desse ano tive novamente a chance de participar de um projeto de implementação interessante, o que coincidiu com o convite para fazer o exame beta até 15 de Abril.

Eis então o cenário: eu não mexia no Vault desde o final de 2021, voltei a mexer em Fevereiro de 2023 e 01/03 eu recebi o convite da certificação. Dalí tive até 14/04 para me preparar.
E como foi isso? Bom, inicialmente eu procurei relatos de pessoas que já tinham feito a prova para entender melhor o que esperar, e achei basicamente esse post.

Olhando as páginas da documentação eu percebi que tinha MUITO conteúdo pra estudar e eu não tinha esse tempo todo, então para a parte mais básica e teórica eu optei por fazer um dos simulados para a prova associate do Bryan Krausen que eu tinha comprado em 2021. Isso me ajudou e identificar os pontos teóricos que eu precisa revisar antes de tudo.

Daí eu tinha outro problema, como fica claro na página da prova, essa certificação vai testar suas habilidades no nível enterprise, as funcionalidades pagas são a chave dessa prova, e como participante beta eu não recebi nenhuma licença para estudar. Eu entrei em contato com o suporte da Hashicorp que foi super parceiro e conseguiu me direcionar para o canal correto para solicitar uma licença temporária. Eles também me sugeriram outro curso do Bryan Krausen: Vault Operations Professional - O Bryan é certificado como exam contributor para essa prova e o curso dele dá acesso a esse ambiente prático com laboratórios que permititam treinar as funcionalidades pagas. Eu decidi comprar o curso e em relação ao conteúdo gravado não foi de super ajuda, mas os laboratórios podem dar uma visão legal sobre coisas que você talvez não pratique no dia a dia (como uma operação de disaster recovery, ou auto-auth com o vault agent). A balança para mim foi positiva aqui.

O post do Glen Yu me fez refletir sobre outra coisa que acho importante - e assim como ele eu reforço aqui: siga a orientação da Hashicorp, essa é uma conclusão nossa e você não quer ter uma surpresa por não estudar algo que estava no plano - o objetivo dessa prova é te testar em Vault, as possíveis integrações com provedores de nuvem (AWS, Azure, GCP), com métodos de autenticação externos (Okta, LDAP) e, principalmente com outros tipos de storage que não o raft, podem cair na prova, mas na minha opinião não é provável que caiam, isso me ajudou a afunilar os estudos cortando todas as integrações por minha conta e risco.

4. O Dia da Prova

Eu achei o ambiente da prova um pouco estranho, mas basicamente você tem acesso a um ambiente virtual com uma guia do Chrome vai receber as instruções pré-exame. Leia as instruções, elas vão te orientar como iniciar os cenários, como navegar no ambiente e o que você pode e não pode fazer.

As minhas 15 primeiras questões foram teóricas e elas também focaram bastante no nível enterprise, por exemplo sobre as funcionalidades relacionadas a FIPS 140-2, sobre como funciona a configuração de um cluster Replica Performance com e sem path filters, sobre policies e sobre o sentinel.

Logo após vieram as questões práticas. Eu não lembro de todas mas lembro que as questões abordaram:

Criação de tokens;
Criação de policies;
Configuração de secret engines;
Configuração de auth engines;
Disaster recovery (configuração e operação);
Replica Performance (configuração e operação);
Vault-agent (auto-auth e PKI);
Metricas.

É muito importante que você leia com calma e atenção o que as questões estão pedindo, a maioria delas vai pedir para você criar um arquivo em determinado diretório, ou escrever o resultado de determinada operação de um campo. Valide seu resultado antes de ir para a próxima questão. A questão pedia para criar um token em um arquivo com certa policy? Execute um vault login ou um token lookup para verificar se o token de fato tem aquela policy. O objetivo era criar um usuário? Valide que você consegue logar e acessar as coisas que aquele usuário deveria acessar. Cheque se seu cluster secundário está conectado, e assim por diante.

Quando eu finalmente acabei essas questões - elas consumiram mais de 3 horas no meu caso - haviam ainda mais 5 questões híbridas sobre logs de auditoria, basicamente eu precisei checar os logs dentro de um container e identificar quem performou determinada ação, ou em que horário algo ocorreu, e depois escrever isso nos campos disponíveis.

O resultado demorou bastante para chegar, a prova foi em Abril e eu só recebi o resultado em Julho, então é bom segurar a ansiedade depois do exame :)

5. O que eu sugiro praticar?

A resposta curta é: tudo :)
A resposta longa é: Não se desespere com a resposta curta, a documentação está ao seu lado e irá te ajudar.
A minha prova cobriu facilmente 90% do que está no programa, de forma prática ou teórica, então o ideal é você saber navegar na documentação de olhos fechados. Consultar qual endpoint chamar, quais parâmetros ele aceita, e até uma segunda confirmação sobre questões teóricas pode ajudar muito.

Como eu disse antes, baseada na minha experiência eu não focaria eu integrações externas, exceto talvez pelo caso de bancos de dados, já que essa é uma funcionalidade amplamente utilizada.

Alguns cenários que eu praticaria e pretendo trazer aqui na sequência sobre Vault:

Configuração de autounseal com transit engine
Configuração e inicialização segura e modelo de segurança
Segredos dinâmicos - DB
Criação e revogação de tokens - explorando diferentes tipos tokens de serviço e batch tokens, tokens periódicos, tokens com limite de uso, wrap e unwrap de token e assim por diante
Audit devices e audit logs
Vault PKI
Métodos de autenticação humana/maquina
Disaster Recovery
Performance Replication
Policies e controle de acesso
Sentinel Policies
Processo de Rekey e de Key Rotation
Namespaces
Vault agent

Por hoje é isso, obrigada por ter lido até aqui, espero voltar em breve com alguns laboratórios e se você está pensando em prestar esse exame e quer trocar uma ideia pode deixar um comentário por aqui :)