Apresentação sobre caso de uso do Kubernetes no Governo Federal do Brasil (SERPRO), orientado à metodologia abordada para a implantação segura da tecnologia como base para a Plataforma como Serviço

1. Kubernetes no
Governo Federal

2. Projeto Estaleiro
Modernização de Infraestrutura de Produção de Serviços dentro do SERPRO, com o objetivo de
uma entrega rápida e segura de novos serviços
● PaaS - Kubernetes
● STaaS - CEPH
● DBaaS - Openstack Trove
● Componentes periféricos que auxiliem na produção desses serviços - Graylog, Elasticsearch,
CA APM, NGINX, HAProxy, etc
● Empoderamento do desenvolvedor
● Produção passa a ser produção

3. Overview

4. Requisitos
● Segmentação - Serviços de Cliente A não impactem / influenciem / realizem acesso não
autorizado em Serviços de Cliente B.
● Segregação de papéis - Desenvolvedor responsável por produto A só tenha acesso aos
recursos desse produto
● Auditoria - Se alguém mudou algo no ambiente, quem foi e quando.
● Controle de vulnerabilidades - Algum pacote do Container desatualizado? Alguma
configuração inadequada?
● “Isso existia no ambiente tradicional” - Pré requisitos já existentes em um ambiente
tradicional, se eles são aplicáveis, e como aplicá-los
○ Ex.: Autenticação via certificado digital, Stickness de sessão

5. Segregação de rede
● A maior preocupação das equipes de Segurança
○ Uma aplicação chamando outra indevidamente
○ Uma aplicação chamando o ambiente tradicional indevidamente
○ Uma aplicação indo na Internet indevidamente (Facebook,
Wikipedia..)
○ Falta de rastreabilidade de rede (quem chamou e quando?)
○ Normas federais, Sindicâncias, auditorias, Polícia Federal :)

6. Segregação de rede

7. Segmentação de redes - Calico
● Calico - Projeto da Tigera
● Responsável pela parte de Networking e também pela implementação de Network Policies
● Principais funcionalidades:
○ Conectividade com o mundo externo via BGP (1 IP real por POD, se assim quiser)
○ Possibilidade de associar um range de IPs específico (inclusive IPv6) por POD ou
ReplicaSet
○ Possibilidade de criar regras de entrada e saída (o Kubernetes só suporta regras de
entrada)
● Baseado em Felix, Confd, IPTables e backend ETCD :)
● É tema inteiro para uma próxima palestra (quem se dispõe??)

8. Demonstração Calico

9. Network Policy
apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
name: allow-http
namespace: demonstracao
spec:
ingress:
- ports:
- port: 8080
protocol: TCP
podSelector:
matchLabels:
app: dummy-app-1

10. Network Policy
apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
name: allow-icmp
namespace: demonstracao
spec:
ingress:
- from:
- podSelector:
matchLabels:
app: dummy-app-1
ports:
- protocol: ICMP
podSelector:
matchLabels:
app: dummy-app-1

11. Segregação de papéis
● Caso: Um desenvolvedor participa de mais de um projeto, mas não pode ter acesso ao
cluster inteiro
● RBAC: Nem todos podem ser admin :)
○ Atenção: roles ainda estão em Beta no Kubernetes 1.6
○ Objetos de um projeto: Namespace, ReplicaSet, DaemonSet, PODs, Network Policies,
Ingress Controllers, Service, etc etc etc
○ Manter o acesso de cada um apenas a seus objetos é um sofrimento!!
● Roles pré existentes: Node (sim, nodes também são usuários do Cluster), Sys admin.
● Grupos: Podem ser utilizados
○ No nosso caso usamos autenticação via Certificado Digital, então o grupo tem que
fazer parte do certificado no atributo ‘O’.
○ Ex.: "/CN=rkatz/O=projeto1/O=projeto2"

12. Problema 3 - Segregação de projetos e papéis

13. RBAC - Objetos
● ClusterRole - Papel existente no Cluster inteiro. Uma permissão global.
○ Ex.: readonly (para um bilhetador, por exemplo), node (para um node)
● Role - Papel existente apenas no contexto de um namespace.
○ Ex.: Um desenvolvedor dentro de um namespace com permissão apenas de mexer nos
objetos de Ingress.
● Uma ClusterRole pode ser associada a um grupo em uma namespace, limitando seu
escopo.
○ Ex.: Grupo X possui a ClusterRole readonly apenas no projeto prj1, podendo ver (mas
não modificar) qualquer recurso desse namespace
● Mais infos: https://kubernetes.io//docs/admin/authorization/rbac/
● Demonstração de funcionamento!

14. Auditoria
● Grandes poderes, grandes responsabilidades!
● Para cada acesso à API do Kubernetes uma entrada de auditoria é gerada, com as seguintes
informações:
○ ID da requisição
○ Quando
○ Quem (usuário e IP)
○ Onde (namespace e objeto do Kubernetes)
○ Conseguiu? - Essa auditoria é uma linha à parte, com o mesmo ID da requisição e o
Return Code da transação
● Demo time - Essa é rapida :)

15. Auditoria

16. Análise de vulnerabilidades
● O software em meu container está atualizado?
● O container está com alguma abominação instalada? SSH, clientes telnet, nc, etc
● O Dockerfile do container especifica um usuário (USER)? Ou roda como ‘root’?
● Proposta: Não se publica um container diretamente no registry. Apenas a integração
contínua o faz.
○ IC faz as análises de conteúdo do container, Dockerfile, pacotes, etc
○ CoreOS Clair faz a análise dos pacotes existentes e sua atualização
● Container com qualquer problema de segurança não é publicado no registry, e
consequentemente não é publicado
● WIP - O Harbor ainda não se integra com o Clair. Mas o Jenkins sim! Então estamos
trabalhando nisso.

17. Análise de vulnerabilidades - Onde queremos chegar?

18. Ingress Controller

19. Necessidades ambiente tradicional
● O foco nesse momento é em como as aplicações são ‘chamadas’
● Ingress - Objeto que especifica a forma de ‘entrada’ de um serviço.
○ Obs.: É diferente do objeto ‘Service’ que especifica como um conjunto de PODs é
exposto no cluster
● Hoje suporta protocolos HTTP/s, com especificação de URL, certificado digital a ser usado,
configurações de cabeçalho, configurações de protocolos SSL/TLS habilitados.
● Ingress Controller - Programa responsável por ler os objetos do Kubernetes (Ingress,
Service, Secrets e PODs) e reconfigurar o frontend conforme esses objetos
○ Nosso frontend hoje é o NGINX, mas existe implementação também para HAProxy
● https://github.com/kubernetes/ingress e https://github.com/jcmoraisjr/haproxy-ingress
● Demo time :)

20. Links interessantes
● https://www.serpro.gov.br
● https://landing.google.com/sre/book.html - Livro sobre SRE do Google
● http://docs.projectcalico.org/v2.1/reference/cni-plugin/configuration - Configuração do
plugin CNI do Calico, inclusive com as referências a alocação de IPs diferentes por POD
● https://github.com/kubernetes/ingress - Repositório oficial Ingress Controller
● https://github.com/jcmoraisjr - Repositório do João Morais (Serpro) com alguns softwares
desenvolvidos para o Estaleiro (omaha-server, ingress-haproxy, coreos-bootstrap, etc)
● https://github.com/rikatz/coreos-kube-lab - Repositório com os userdata que estavam
sendo utilizados para montar os laboratórios (WIP)
● https://www.graylog.org/ - Página oficial do Projeto Graylog
● https://quay.io/ - Docker Registry com Análise de vulnerabilidades

21. Dúvidas?
Agradecemos pela atenção.
Ricardo Pchevuzinske Katz
ricardo.katz@serpro.gov.br
ricardo.katz@gmail.com
@katzsp
https://www.linkedin.com/in/katzricardo/