Documentação do Oracle Cloud Infrastructure

Protegendo o Kubernetes Engine

Este tópico fornece recomendações de segurança para usar o Kubernetes Engine do Oracle Cloud Infrastructure (também conhecido como OKE).

Clusters Multitenant

Cargas de Trabalho Mutuamente Confiáveis

Nesse momento, não é recomendável executar cargas de trabalho mutuamente não confiáveis no mesmo cluster. Por exemplo, você não deve executar as seguintes cargas de trabalho no mesmo cluster:

  • Cargas de trabalho de desenvolvimento e cargas de trabalho de produção
  • Plano de controle e plano de dados
  • Cargas de trabalho que executam código de cliente arbitrário

Cargas de Trabalho com Diferentes Níveis de Confiança

Considere ter clusters separados se você tiver vários tenants, equipes ou usuários que acessem o mesmo cluster com níveis diferentes de confiança. Conforme mencionado em seções subsequentes, o Kubernetes e o OKE oferecem métodos para isolar cargas de trabalho. No entanto, esses métodos não são suficientes no momento para a hard multitenancy.

Os Kubelets têm Acesso de Leitura aos Recursos

Um kubelet em execução em um nó de trabalho em um cluster criado pelo OKE não pode modificar recursos que não pertençam ao nó do kubelet. Para obter mais informações, consulte detalhes sobre o controlador de admissão NodeRestriction na documentação do Kubernetes.

Observe, particularmente ao executar cargas de trabalho multitenant, que, embora um kubelet não possa modificar recursos que não pertençam ao nó, o kubelet ainda pode ler esses recursos. Tais recursos podem incluir:

  • serviços
  • pontos finais
  • nós
  • pods
  • segredos, configmaps e volumes persistentes vinculados ao nó do kubelet

Para obter mais informações, consulte Usando a Autorização de Nó na documentação do Kubernetes.

Controle de Acesso Baseado em Atribuição (RBAC)

O Kubernetes fornece um componente RBAC (Role-Based Access Control) integrado que correlaciona um usuário ou grupo de entrada a um conjunto de permissões que são agrupadas em atribuições. Essas permissões combinam os verbos (obter, criar, excluir) com recursos (pods, serviços, nós) e podem ter como escopo um namespace ou cluster. Um conjunto de atribuições pré-configuradas é fornecido, o qual oferece separação de responsabilidade padrão razoável, dependendo de quais ações um cliente queira executar.

É importante entender como as atualizações em um objeto podem causar ações em outros locais. Por exemplo, um usuário pode não ser capaz de criar pods diretamente, mas permitir que ele crie uma implantação, que cria pods em seu nome, o que permitirá que ele crie esses pods indiretamente. Da mesma forma, a exclusão de um nó da API resultará em pods programados para esse nó sendo encerrados e recriados em outros nós. As atribuições pré-configuradas representam um equilíbrio entre a flexibilidade e os casos de uso comuns, mas mais atribuições limitadas devem ser revisadas cuidadosamente para evitar a escalação acidental do privilégio. Você poderá tornar as atribuições específicas do seu caso de uso se as atribuições pré-configuradas não atenderem às suas necessidades.

Você sempre deve seguir o princípio do privilégio mínimo para garantir que os usuários e as Contas do Serviço Kubernetes tenham o conjunto mínimo de privilégios necessários. Por padrão, qualquer usuário com acesso USE CLUSTER no Oracle Cloud Infrastructure IAM ou em qualquer Conta do Serviço Kubernetes não terá acesso à API do Kubernetes, exceto as atribuições de descoberta. Consulte Sobre o Controle de Acesso e o Serviço Kubernetes Engine (OKE) para saber como o serviço IAM se integra com o OKE.

Você deve usar o OCID do Principal ao criar associações RBAC (por exemplo, OCID do usuário, OCID da instância e nome do serviço).

Segurança do Cluster

Você pode controlar as operações que os pods têm permissão para executar em um cluster criado com o serviço Kubernetes Engine, configurando políticas de segurança de pod para o cluster. Políticas de segurança de pod são uma forma de garantir que os pods atendam às condições relacionadas à segurança para que possam ser aceitos por um cluster. Por exemplo, você pode usar políticas de segurança de pod para:

  • limitar as opções de armazenamento disponíveis para os pods
  • restringir a rede e portas do host que os pods podem acessar
  • impedir que os pods sejam executados como usuário-raiz
  • impedir que os pods sejam executados no modo privilegiado

Tendo definido uma política de segurança de pod para um cluster, você tem que autorizar o usuário ou solicitante a usar a política criando atribuições e bindings. Em seguida, você poderá especificar se um cluster impõe as políticas de segurança de pod definidas para ele ativando o controlador de admissão PodSecurityPolicy do cluster.

Para obter mais informações, consulte Usando Políticas de Segurança de Pod com o Kubernetes Engine (OKE).

Observação

O projeto upstream do Kubernetes obsoletou as políticas de segurança de pod no Kubernetes versão 1.21 e removeu o recurso no Kubernetes versão 1.25. Consequentemente, o Kubernetes Engine não suporta políticas de segurança de pod e o controlador de admissão PodSecurityPolicy em clusters que executam o Kubernetes versão 1.25 e posterior.

Se você precisar de uma funcionalidade semelhante, considere o uso de padrões de segurança de pod do Kubernetes e do controlador de admissão PodSecurity (junto com as políticas Privilegiada, Linha de Base e Restrita). Por padrão, o Kubernetes Engine permite o controlador de admissão PodSecurity em clusters que executam o Kubernetes versão 1.23 e posterior, a fim de suportar padrões de segurança de pod. Para obter mais informações sobre os padrões de segurança de pod do Kubernetes e o controlador de admissão PodSecurity, consulte Padrões de Segurança de Pod na documentação do Kubernetes.

Como alternativa, considere o uso de outras alternativas que estão sendo desenvolvidas no ecossistema do Kubernetes para impor políticas.

Se você decidir deixar de usar políticas de segurança de pod e o controlador de admissão PodSecurityPolicy para usar padrões de segurança de pod e o controlador de admissão PodSecurity, consulte Migrar de PodSecurityPolicy para o Controlador de Admissão PodSecurity Incorporado na documentação do Kubernetes. Observe que é importante concluir a migração antes de criar um novo cluster executando o Kubernetes versão 1.25 ou antes de fazer upgrade de um cluster existente do Kubernetes versão 1.24 para executar o Kubernetes versão 1.25. Observe também que a Console fornece uma maneira conveniente de desativar o uso do controlador de admissão PodSecurityPolicy nos clusters existentes do Kubernetes criados e gerenciados pelo Kubernetes Engine (consulte Usando a Console para Desativar o Controlador de Admissão PodSecurityPolicy).

Segurança do Pool de Nós

Compartimentos do Pool de Nós

Os pools de nós em um cluster podem abranger compartimentos. No entanto, embora o uso de vários compartimentos seja uma forma conveniente de agrupar e gerenciar nós de trabalho, ele não oferece isolamento entre os nós de trabalho no cluster. Qualquer carga de trabalho pode ser programada em qualquer pool de nós, independentemente do compartimento. Um caso de uso válido de uso de mais de um compartimento para um pool de nós seria para criar facilmente grupos dinâmicos e políticas do serviço IAM para nós de trabalho. Um caso de uso inválido para vários compartimentos seria colocar cada pool de nós executando uma carga de trabalho do cliente em um compartimento separado, sob o pressuposto de que os compartimentos estão fornecendo algum tipo de limite ou isolamento de segurança.

Sub-redes do Pool de Nós

Recomendamos usar somente sub-redes privadas para pools de nós. Um gateway de serviço deve ser configurado para fornecer acesso aos serviços do Oracle Cloud Infrastructure. Um gateway de serviço não poderá ser usado se as sub-redes forem públicas com um gateway de internet. Se as suas sub-redes privadas precisarem de acesso à internet, use um gateway NAT.

Controlando Quais Nós os Pods Podem Acessar

Por padrão, um pod pode ser programado em qualquer nó do cluster. O Kubernetes oferece um amplo conjunto de políticas para controlar o posicionamento de pods em nós e o posicionamento e a recuperação de pods com base em taint que estão disponíveis para os usuários finais. Para muitos clusters, o uso dessas políticas para cargas de trabalho separadas pode ser uma convenção que os autores adotem ou apliquem por meio de ferramentas. Esses controles de posicionamento não são adequados em um ambiente multitenant quando os usuários com recursos de implantação não são confiáveis. Caso você tenha usuários não confiáveis implantando código, deverá considerar um cluster por grupo não confiável.

Limitar Acesso Fornecido aos Principais da Instância

Por padrão, todos os pods de um nó podem acessar os certificados do controlador de instâncias usando o ponto final de metadados da instância. Para evitar a escalação do privilégio por meio de principais da instância, você deve isolar cargas de trabalho nos pools de nós com grupos dinâmicos distintos, de forma que os pods em um determinado pool de nós tenham o conjunto mínimo de privilégios necessários para funcionar.

Por exemplo, suponha que você tenha as duas cargas de trabalho a seguir, que exigem acesso distinto:

  • LogArchiver - requer acesso para gerenciar buckets e objetos no serviço Object Storage
  • HostMonitor - requer acesso à API do serviço Compute para gerenciar Instâncias

A abordagem mais simples seria programá-las no mesmo pool de nós e permitir que o controlador de instâncias tenha todo o acesso necessário. No entanto, isso aumenta o impacto no caso de uma das cargas de trabalho ficar comprometida. Uma abordagem melhor seria programar as cargas de trabalho em pools de nós separados com o conjunto limitado de acesso que os principais da instância exigem para a carga de trabalho aplicável.

Bloquear Acesso do Contêiner aos Metadados da Instância

A maneira preferida de bloquear o acesso é usar um plug-in de política de rede com uma política padrão de "negar tudo". Em seguida, você concederia explicitamente acesso a pods e redes usando recursos NetworkPolicy no Kubernetes por meio de seletores de label. Se você não tiver um plug-in de política de rede instalado, poderá usar uma regra IPTables para restringir o acesso de todos os pods do host. Recomendamos que você não use essa abordagem para bloquear um subconjunto de pods em um host.

Importante: O NetworkPolicys e a regra IPTable a seguir só se aplicam a contêineres na rede de sobreposição de pod. Os contêineres e serviços em execução na rede do host não são impactados por nenhuma das opções:

iptables --insert FORWARD 1 --in-interface veth+ --destination 169.254.0.0/16 --jump DROP

Segurança de Rede

Pods executados em seu Cluster OKE com frequência precisam se comunicar com outros pods no cluster ou com serviços fora do cluster. O Kubernetes Engine oferece várias opções para proteger a comunicação de/ para as cargas de trabalho no seu cluster. Para a melhor postura de segurança de rede, você deve avaliar o uso de uma combinação de políticas de rede (para proteger a comunicação de rede no nível do pod) e listas de segurança (para proteger a comunicação de rede no nível do host).

Políticas de Rede

As políticas de rede no Kubernetes permitem que os administradores definam como os grupos de pods podem se comunicar com outros pods do cluster. Além disso, as políticas de rede permitem definir como os grupos de pods podem se comunicar com serviços fora do cluster (por exemplo, serviços do Oracle Cloud Infrastructure).

Para restringir o acesso usando políticas de rede, você precisa instalar um plug-in de rede. Os plug-ins de rede configuram e aplicam as políticas de rede definidas no Kubernetes. Várias opções de plug-in de rede estão disponíveis. Você pode seguir nossas instruções aqui para instalar e configurar o Calico em seu cluster. Os plug-ins de política de rede funcionam restringindo o acesso no host. Para obter informações sobre como instalar o Calico no OKE, consulte Exemplo: Instalando o Calico e Configurando Políticas de Rede.

Listas de Segurança do Pool de Nós

Os administradores de rede podem definir regras da lista de segurança nas sub-redes do pool de nós para restringir o acesso a nós de trabalho de entrada e saída. A definição de regras de lista de segurança permite que os administradores imponham restrições de rede que não podem ser substituídas nos hosts do seu cluster.

Como todas as comunicações de pod a pod ocorrem em uma rede de sobreposição VXLAN nos nós de trabalho, você não pode usar regras de lista de segurança para restringir a comunicação de pod a pod. No entanto, você pode usar listas de segurança para restringir o acesso de/para seus nós de trabalho.

Importante: Deve existir um conjunto mínimo de regras de lista de segurança nas sub-redes do pool de nós para garantir que o cluster possa funcionar. Consulte Exemplo de Configurações de Recursos de Rede para obter informações sobre o conjunto mínimo de regras de lista de segurança antes de modificar as regras de lista de segurança.

Melhores Práticas para Segurança da Carga de Trabalho

Usar Compilações de Imagem em vez de Tags

Recomendamos que você só extraia imagens usando as compilações de imagens e não extraia imagens usando tags (porque tags de imagem são mutáveis). Compilações de imagem são a compilação sha256 de sua imagem, que permite que o docker verifique se a imagem que foi transferida por download é a que você esperava.

Exemplo de id de compilação de imagem:

sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Obtenha a imagem conforme mostrado no exemplo a seguir:

docker pull acme@sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

É possível usar o seguinte comando para mostrar todas as compilações para suas imagens locais:

docker images --digests

Limitar Utilização de Recursos

A Cota de recursos limita o número ou a capacidade de recursos concedidos a um namespace. Essa opção é usada com mais frequência para limitar o volume de CPU, memória ou disco persistente que um namespace pode alocar, mas também pode controlar quantos pods, serviços ou volumes existem em cada namespace.

As faixas limite restringem o tamanho máximo ou mínimo de alguns dos recursos acima para impedir que os usuários solicitem valores excessivamente altos ou baixos para recursos comumente reservados como memória ou para fornecer limites padrão quando nenhum for especificado.

O acesso a cotas de recursos pode ser restrito por meio de políticas RBAC no Kubernetes. Isso pode ajudar um administrador a garantir que os usuários de um cluster não possam usar recursos aos quais eles não devem ter acesso. Consulte Limitando o uso de recursos em um cluster na documentação do Kubernetes para obter mais informações.

Desativando o Complemento Tiller

O OKE oferece um add-on Tiller opcional. Ele oferece uma maneira fácil de instalar e usar o Helm+Tiller, permitindo que você provisione e execute rapidamente o Kubernetes. Não é recomendável usar este complemento para clusters de produção em decorrência dos riscos de segurança associados ao Tiller. Os clusters provisionados com o Tiller não têm autenticação ou autorização para chamadas de API feitas ao Tiller, o que significa que eles não podem fornecer atribuição para solicitações. Portanto, qualquer operador ou serviço que possa acessar o Tiller pode chamar suas APIs com acesso do Tiller.

Para solucionar os problemas de segurança associados ao Tiller, o Helm V3 foi desenvolvido. A release Helm V3 removeu completamente o Tiller do Helm. Recomendamos que você use o Helm V3 se quiser utilizar a funcionalidade oferecida pelo Helm+Tiller.

Observação:

Para desativar o complemento Tiller em um cluster existente, entre em contato com o Suporte Técnico da Oracle.

Desativando o Complemento de Painel de Controle do Kubernetes

O OKE oferece um complemento opcional de Painel de Controle do Kubernetes, fornecendo uma maneira fácil de instalar o Painel de Controle do Kubernetes. O Painel de Controle do Kubernetes é instalado pelo OKE com o conjunto mínimo de privilégios necessários para execução. Você não poderá usar o painel de controle sem fornecer credenciais adicionais. Consulte Acessando um Cluster Usando o Painel de Controle do Kubernetes para obter mais informações.

O painel de controle é particularmente útil para novos usuários do Kubernetes. No entanto, não recomendamos a instalação deste complemento em clusters de produção devido à falta de suporte de autenticação extensível. Consequentemente, você não pode especificar que deseja instalar o Painel de Controle do Kubernetes ao criar um cluster usando a Console. Se você decidir que deseja instalar o Painel de Controle do Kubernetes, crie o cluster usando a API e defina o atributo isKubernetesDashboardEnabled como verdadeiro.

Se você instalar o Painel de Controle do Kubernetes, recomendamos que você restrinja o acesso dentro do seu cluster, em vez de expô-lo externamente por meio de um balanceador de carga ou um controlador de entrada. O Painel de Controle do Kubernetes é um vetor de ataque comum usado para obter acesso a um Cluster do Kubernetes.

Observação:

Para desativar o complemento de Painel de Controle do Kubernetes em um cluster existente, entre em contato com o Suporte Técnico da Oracle.