Projeto Prático Programa Intensivo em Containers e Kubernetes - Desenvolvimento e Otimização Segura de Aplicações Kubernetes
O objetivo deste projeto é criar e implementar uma aplicação em Kubernetes, utilizando as melhores práticas de segurança e otimização.
Este projeto utiliza como base a aplicação Giropops-Senhas.
- Docker
- Kubectl
- Helm
- kube-prometheus
- Cosign
- Trivy
- Zora Dashboard
- Ingress NGINX Controller
- Cert-Manager
- Kind
- Locust
- yamlint
- Digestabot
- Terrafom
A aplicação foi construída utilizando como base as imagens Python da Chainguard, que já possuem as melhores práticas de segurança implementadas. Utilizando a técnica de multi-stage build para reduzir o tamanho final e principalmente aumentar a segurança.
Você pode buildar a imagem localmente utilizando os arquivos na pasta 'giropops-senhas' com o comando:
docker build -t <login-docker-hub>/linuxtips-giropops-senhas:{versao} .E rodar testes de segurança utilizando o Trivy
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.47.0
trivy image <login-docker-hub>/linuxtips-giropops-senhas:{versao}Ou utilizar a imagem disponível no Docker Hub com a garantia de utilizar sempre a versão mais recente e livre de vulnerabilidades. Já que a imagem é buildada automaticamente sempre que houver qualquer alterção, utilizando o Digestabot para manter a imagem base sempre atualizada, o Trivy para verificar se a imagem possui alguma vulnerabilidade e o Cosign para assinar a imagem e garantir que ela não foi alterada.
- Caso tenha interesse em conhecer mais sobre o Digestabot, você pode ler o artigo Você já conhece o Digestabot? escrito por mim.
Como o objetivo deste projeto é aplicar as melhores práticas de segurança e otimização, foram utilizadas as seguintes técnicas:
- Secrets para armazenar as variáveis de ambiente??
- Limites de Recursos para limitar o uso de CPU e Memória
- Network Policies para limitar o acesso a aplicação
- Pod Security Policies para limitar o acesso a aplicação
- RBAC para limitar o acesso a aplicação
- Service Account para limitar o acesso a aplicação
- Pod Disruption Budget para garantir que sempre haverá pelo menos um pod rodando ??
- Horizontal Pod Autoscaler para escalar a aplicação horizontalmente
- Pod Affinity para garantir que os pods rodem no mesmo node
- ConfigMap para armazenar as configurações da aplicação
- Pod Monitor Para definir as métricas de monitoramento
- Strategy para garantir que a aplicação seja atualizada sem downtime
- Image Pull Policy para garantir que a aplicação utilize sempre a imagem mais recente
- Security Context para definir o usuário e grupo que a aplicação irá rodar
- Probes para verificar se a aplicação está saudável
A aplicação foi dividida nos seguintes componentes:
- giropops-senhas - Responsável por gerar as senhas
- redis - Responsável por armazenar as senhas
- locust - Responsável por gerar testes de carga na aplicação
- ingress-nginx - Responsável por gerar o ingress da aplicação
- kube-prometheus - Responsável por gerar o dashboard de monitoramento
- metrics-server - Responsável por gerar métricas de monitoramento
- zora-dashboard - Responsável por gerar um dashboard de vulnerabilidades
O deploy da aplicação pode ser feito utilizando de forma local, utilizando o Kind, ou em um cluster na Oracle Cloud.
- Local - Kind
- OCI - Oracle Cloud