Segurança do Cluster

Entendendo como manter e gerenciar um cluster Kubernetes com segurança.

  8 minute read  

Em linhas gerais o que veremos a seguir é a aplicação do modelo 4C's da segurança nativa da nuvem, não necessariamente na ordem apresentada.

Fonte.: Doc K8S — Visão geral da segurança nativa da nuvem .

A Segurança no Kubernetes

O Kubernetes é formado por Nodes , portanto o primeiro passo é garantir a segurança dos mesmos, desabilitando a autenticação por senha e habilitando a autenticação por chave SSH;

Como a comunicação dentro de um cluster Kubernetes, os comandos, o gerenciamento, etc. passa pelo API Server, não podemos esquecer:

API Server Seguro == Kubernetes Seguro

Para manter a segurança no acesso ao API Server, precisamos pensar em:

  • Quem pode acessar (Autenticação) e;
  • O que pode fazer (Autorização);

Para garantir a segurança nas comunicações entre os componentes do cluster é fundamental o uso do TLS.

E como a premissa do Kubernetes é que todos os Pods podem se comunicar entre si, temos as Network Policies para implementar um controle nestas comunicações.

Link’s úteis:

Autenticação

Link’s úteis:

Conceitos básicos sobre TLS

O TLS (Transport Layer Security) é um protocolo de criptografia projetado para garantir a privacidade (confidencialidade), integridade e autenticidade na comunicação em uma rede de computadores através do uso de certificados digitais , ele é a base do HTTPS (Hypertext Transfer Protocol Secure) .

Link’s úteis:

TLS no Kubernetes

No Kubernetes para garantir a comunicação segura e confiável entre os componentes nos Worker Nodes, o kubelet e o kube-proxy , e os componentes no Control Plane , principalmente o kube-apiserver é altamente recomendável usar certificados TLS.

Fonte.: Curso - Certified Kubernetes Administrator (CKA) with Practice Tests .

Link’s úteis:

Certificates API / API de Certificados

A API de certificados permite a automação do provisionamento de credenciais X.509 fornecendo uma interface programática para clientes da API Kubernetes solicitarem e obterem certificados X.509 de uma Autoridade de Certificação (CA).

Um recurso CertificateSigningRequest (CSR) é usado para solicitar que um certificado seja assinado por um assinante indicado, após o qual a solicitação pode ser aprovada ou negada antes de ser finalmente assinada.

Link’s úteis:

KubeConfig

Utilize arquivos kubeconfig para organizar informações sobre clusters, usuários, namespaces e mecanismos de autenticação. A ferramenta de linha de comando kubectl faz uso dos arquivos kubeconfig para encontrar as informações necessárias para escolher e se comunicar com o serviço de API de um cluster.

Por padrão, o kubectl procura por um arquivo de nome config no diretório $HOME/.kube. Você pode especificar outros arquivos kubeconfig através da variável de ambiente KUBECONFIG ou adicionando a opção --kubeconfig.

Link’s úteis:

API Groups / Grupos de API

Os grupos de API facilitam a extensão da API do Kubernetes. O grupo de APIs é especificado em um caminho REST e no campo apiVersion de um objeto serializado.

Existem vários grupos de API no Kubernetes:

  • O grupo principal ou core (também chamado de legado) é encontrado no caminho REST /api/v1. O grupo principal não é especificado como parte do campo apiVersion, por exemplo, apiVersion: v1.

Fonte.: Curso - Certified Kubernetes Administrator (CKA) with Practice Tests .

  • Os grupos nomeados estão no caminho REST /apis/$GROUP_NAME/$VERSION e usam apiVersion: $GROUP_NAME/$VERSION (por exemplo, apiVersion: batch/v1). Podemos encontrar a lista completa de grupos de API compatíveis na referência da API do Kubernetes .

Fonte.: Curso - Certified Kubernetes Administrator (CKA) with Practice Tests .

Link’s úteis:

Autorização

O Kubernetes autoriza solicitações de API usando o API Server. Ele avalia todos os atributos de solicitação em relação a todas as políticas e permite ou nega a solicitação. Todas as partes de uma solicitação de API devem ser permitidas por alguma política para prosseguir. Isso significa que as permissões são negadas por padrão.

Quando vários módulos de autorização são configurados, cada um é verificado em sequência. Se algum autorizador aprovar ou negar um pedido, essa decisão é imediatamente devolvida e nenhum outro autorizador é consultado. Se todos os módulos não tiverem opinião sobre a solicitação, a solicitação será negada. Uma negação retorna um código de status HTTP 403.

Link’s úteis:

RBAC (Role-Based Access Control)

O RBAC (Role-Based Access Control ou Controle de Acesso Baseado em Função) é um método de regular o acesso a recursos de computador ou rede com base nas funções de usuários individuais em sua organização.

A autorização RBAC usa o rbac.authorization.k8s.io Grupo de API para orientar as decisões de autorização, permitindo configurar políticas dinamicamente por meio da API do Kubernetes.

Para habilitar o RBAC, inicie o API Server com o sinalizador --authorization-modes definido para uma lista separada por vírgulas que inclua RBAC, por exemplo:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Link’s úteis:

Cluster Roles e Role Bindings

Uma Role ou ClusterRole RBAC contém regras que representam um conjunto de permissões. As permissões são puramente aditivas (não há regras de “negação”).

  • Uma Role sempre define permissões em um determinado namespace; ao criar uma Role, precisa ser especificado o namespace ao qual ela pertence.
  • ClusterRole, por outro lado, é um recurso sem namespace, se aplica ao cluster inteiro.

Os recursos têm nomes diferentes (Role e ClusterRole) porque um objeto Kubernetes sempre precisa ter namespace ou não; não pode ser os dois.

Link’s úteis:

Services Accounts / Contas de Serviços

Segue abaixo algumas caracteristicas das Services Accounts ou Contas de Serviço:

  • São para processos, que são executados em pods.
  • São vinculadas a um namespace.
  • Processo de criação mais leve, permitindo que os usuários do cluster criem contas de serviço para tarefas específicas seguindo o princípio de privilégio mínimo.

Link’s úteis:

Segurança de Imagens

Uma imagem de container representa dados binários que encapsulam um aplicativo e todas as suas dependências de software, são pacotes de software executáveis ​​que podem ser executados de forma independente e que fazem suposições muito bem definidas sobre seu ambiente de tempo de execução.

Normalmente se cria uma imagem de contêiner de seu aplicativo e a envia para um registro antes de se referir a ela em um Pod.

Link’s úteis:

Security Context ou Contexto de Segurança

Os Security Contexts configuram Pods e Containers em tempo de execução.

Os Security Contexts são definidos como parte das especificações do Pod e do Container no manifesto do Pod e representam parâmetros para o tempo de execução do container.

Link’s úteis:

Network Policy

Por padrão todas as conexões de entrada e saída em um Pod são permitidas, as Network Policies implementam um controle no fluxo do tráfego tanto de entrada Ingress, quanto de saída Egress.

As Network Policies não entram em conflito, elas são aditivas. Se alguma política ou políticas se aplicarem a um determinado Pod para uma determinada direção, as conexões permitidas nessa direção desse Pod serão a união do que as políticas aplicáveis ​​permitem. Assim, a ordem de avaliação não afeta o resultado da política.

Para que uma conexão de um Pod de origem a um Pod de destino seja permitida, a política de saída no Pod de origem e a política de entrada no Pod de destino precisam permitir a conexão, se um dos lados não permitir a conexão, ela não acontecerá.

Link’s úteis:


Última modificação 27 de Oct de 2022: Reorganização da estrutura de pastas. - Agrupando todo o conteúdo como 'documentação'. - Deixando a estrutura de 'blog' para as novidades do site. (a02118c4)