Questão de Engenharia de Software — Software livre — INSTITUTO AOCP 2023

Segurança no Kubernetes: TLS, certificados e RBAC

Gabarito: letra D. A comunicação segura entre os componentes do cluster Kubernetes exige a combinação de criptografia TLS, certificados válidos e controle de acesso baseado em função (RBAC). Essa é a abordagem que garante autenticação, autorização e confidencialidade dos dados trafegados, conforme as boas práticas de segurança do Kubernetes.

O Kubernetes é uma plataforma de orquestração de contêineres que gerencia um conjunto de componentes — como o API server, o etcd, o kubelet e o kube-proxy — que precisam se comunicar entre si. Essa comunicação é o alvo principal de ataques, pois é por ela que trafegam informações sensíveis, como credenciais, chaves e dados de configuração. Por isso, a segurança do cluster depende de três pilares fundamentais: criptografia em trânsito, autenticação e autorização.

A criptografia TLS (Transport Layer Security) protege os dados em trânsito, impedindo que sejam interceptados ou adulterados por terceiros. Para que o TLS funcione corretamente, é necessário usar certificados válidos, emitidos por uma autoridade certificadora (CA) confiável. Certificados autoassinados, embora possam ser usados em ambientes de desenvolvimento, não são recomendados para produção, pois não oferecem a mesma garantia de autenticidade. A validação de certificados é essencial para garantir que o componente com o qual você está se comunicando é realmente quem diz ser.

A autenticação é o processo de verificar a identidade de quem está tentando acessar o cluster. O Kubernetes oferece vários métodos de autenticação, como certificados de cliente, tokens e integração com provedores de identidade externos. A autorização, por sua vez, define o que um usuário autenticado pode fazer. O RBAC (Role-Based Access Control) é o mecanismo padrão de autorização do Kubernetes, que permite criar papéis (roles) com permissões específicas e associá-los a usuários, grupos ou contas de serviço. Com o RBAC, é possível aplicar o princípio do menor privilégio, garantindo que cada entidade tenha apenas as permissões necessárias para executar suas tarefas.

Na prática, a configuração segura de um cluster Kubernetes envolve:

• Habilitar o TLS para todas as comunicações entre componentes (API server, kubelet, etcd, etc.).

• Usar certificados emitidos por uma CA confiável e validar esses certificados em todas as conexões.

• Habilitar o RBAC e criar papéis com permissões granulares, evitando o uso de permissões amplas ou de acesso de administrador por padrão.

• Armazenar segredos (como chaves e credenciais) de forma segura, preferencialmente usando o etcd com criptografia em repouso.

A banca explora exatamente a combinação desses elementos: a alternativa correta é a que reúne TLS, certificados válidos e RBAC. As demais alternativas apresentam práticas inseguras ou incompletas, que comprometem a segurança do cluster.

Alternativa A — ❌ Incorreta

Desabilitar o RBAC e permitir acesso a todos os usuários e serviços é o oposto do que se deve fazer. O RBAC é o mecanismo que garante a autorização adequada, aplicando o princípio do menor privilégio. Sem ele, qualquer usuário ou serviço autenticado teria acesso total ao cluster, o que representa uma vulnerabilidade gravíssima. A alternativa confunde a ideia de "simplicidade" com "segurança", mas, na prática, desabilitar o controle de acesso é uma falha crítica.

Alternativa B — ❌ Incorreta

Usar certificados autoassinados e ignorar a validação de certificados é uma prática insegura. Certificados autoassinados não são emitidos por uma autoridade certificadora confiável, o que torna impossível verificar a autenticidade do componente com o qual se está comunicando. Ignorar a validação de certificados abre espaço para ataques de man-in-the-middle, em que um atacante pode interceptar e modificar a comunicação. A alternativa propõe exatamente o que deve ser evitado.

Alternativa C — ❌ Incorreta

O etcd é o armazenamento de dados do cluster, incluindo credenciais e chaves, mas a alternativa está incompleta e imprecisa. Implementar políticas de segurança usando o etcd como armazenamento centralizado de credenciais é uma prática válida, mas não é a abordagem completa para garantir comunicação segura. A alternativa não menciona a criptografia TLS nem o RBAC, que são essenciais. Além disso, o etcd deve ser protegido com criptografia em repouso e controle de acesso, mas isso é apenas uma parte da solução.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta alternativa reúne os três pilares da segurança no Kubernetes: criptografia TLS, certificados válidos e controle de acesso baseado em função (RBAC). A criptografia TLS protege os dados em trânsito, os certificados válidos garantem a autenticidade dos componentes e o RBAC assegura a autorização adequada, aplicando o princípio do menor privilégio. Essa é a abordagem correta e completa para implementar comunicação segura entre os componentes do cluster.

Alternativa E — ❌ Incorreta

Utilizar redes não criptografadas entre os componentes do cluster é uma prática insegura, pois expõe os dados trafegados a interceptação e adulteração. A criptografia é essencial para proteger a confidencialidade e a integridade das comunicações. A alternativa prioriza o desempenho em detrimento da segurança, o que é inaceitável em um ambiente de produção.

Gabarito: letra D