O documento discute como deixar um cluster Kubernetes seguro usando políticas de acesso e controle. Ele descreve soluções como RBAC, ABAC, Vault e políticas de rede para isolar pods e controlar acesso. Também discute Service Mesh como Istio para gerenciar tráfego entre serviços de forma segura.

1. Deixando
seu cluster
k8s em
quarentena:
Sobre políticas e controle de
acesso

2. WHOAMI
Github: https://github.com/Talits
Linkedin: https://www.linkedin.com/in/talits
Twitter: https://twitter.com/talits_bp
Whoami:
● Trabalho na Loggi;
● Sou mãe;
● Adoro essas paradas de contar história;
● Amo ler coisas aleatórias e amo café.

3. K8S AO INFINITO E ALÉM

4. K8s ao infinito e além
● 84% usam containers em
produção;
● 78% rodam Kubernetes em
produção;
● 19% possuem > 5000
containers rodando em
produção.
https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf

5. K8s ao infinito e além
● E por fim percebemos que
em segundo lugar vemos
que as mudanças refletem
em segurança
usando/deployando
containers (40%).

6. Criando um Cluster Seguro

8. PROBLEMA VS. SOLUÇÕES
Temos muitas (nativas, corps,
de provedores cloud e etc.)
Soluções
Um cluster de kubernetes
default ou mal configurado
gera problemas como
vulnerabilidades de
segurança, problemas de
rede, falhas de infraestrutura
entre outros.
Problema

9. Alguns Exemplos
● RBAC
● ABAC
● Vault
● IAM Authenticator
● Networking Policies
● Service Mesh
● Webhook

10. “Define um paradigma de controle de acesso pelo qual os direitos de acesso são concedidos aos
usuários por meio do uso de políticas que combinam atributos.”
ABAC (Attribute-based access control)
Detalharemos alguns

11. Detalharemos alguns
RBAC (Role-based access control)
“É um método de regular o acesso a recursos de computador ou rede com base nas funções de
usuários individuais em uma empresa. Nesse contexto, o acesso é a capacidade de um usuário
individual de executar uma tarefa específica, como exibir, criar ou modificar um arquivo.”

13. Detalharemos alguns
Networking Policies
Por default os pods não são isolados, podemos isolá-los em políticas de rede, que
podem ser do tipo:
● Ingress : Entrada
● Egress : Saída

15. Service Mesh

17. Service Mesh

18. Virtual Service: Define um conjunto de regras de roteamento de tráfego a serem aplicadas
quando um host é endereçado. Cada regra de roteamento define critérios de correspondência
para o tráfego de um protocolo específico. Se o tráfego for correspondido, ele será enviado para
um serviço de destino nomeado.
Destination Rule: Define políticas que se aplicam ao tráfego destinado a um serviço após o
roteamento.

19. Gateway: Descreve um balanceador de carga que opera na borda da malha, recebendo
conexões HTTP / TCP de entrada ou saída. A especificação descreve um conjunto de
portas que devem ser expostas, o tipo de protocolo a ser usado, etc.
Service Entry: Permite adicionar entradas adicionais ao registro de serviço interno do
Istio, para que os serviços descobertos automaticamente na malha possam acessar /
rotear para esses serviços especificados manualmente. Uma entrada de serviço descreve
as propriedades de um serviço (nome DNS, portas, protocolos, endpoints, etc)

22. Demo

23. Deixar seu cluster
em “quarentena”,
faz com que ele
permaneça
saudável.

24. Dicas
● Devops Nativo de Nuvem com Kubernetes
● Kubernetes up and running
● Kubernetes Doc
● Istio Doc

25. Dúvidas, anseios, desabafos?

26. Thanks!
Github: https://github.com/Talits
Linkedin: https://www.linkedin.com/in/talits
Twitter: https://twitter.com/talits_bp