Segurança para o IBM Cloud Kubernetes Service

É possível usar recursos de segurança integrada no IBM Cloud® Kubernetes Service para análise de risco e proteção de segurança. Esses recursos ajudam você a proteger a sua infraestrutura de cluster e a comunicação de rede, a isolar os seus recursos de cálculo e a assegurar a conformidade de segurança em seus componentes de infraestrutura e implementações de contêiner.

Para obter uma análise de diretrizes de segurança por versão de produto, consulte CIS Kubernetes Benchmark.

Visão geral de ameaças de segurança para seu cluster

Para proteger seu cluster de ser comprometido, deve-se entender as potenciais ameaças de segurança para seu cluster e o que é possível fazer para reduzir a exposição a vulnerabilidades.

Ataques externos
Invasores que ganham acesso ao seu cluster, recursos implementados, apps ou informações pessoais.
Implementações vulneráveis
As vulnerabilidades conhecidas são exploradas para obter acesso ao ambiente em nuvem e executar software malicioso.
Dados comprometidos ou perdidos
Armazenamento incorreto de dados confidenciais e falta de criptografia.
Funcionários e fornecedores terceirizados
A falta de isolamento e segmentação da rede pode levar ao uso indevido de permissões legítimas.

A segurança de nuvem e a proteção de seus sistemas, infraestrutura e dados contra ataques se tornaram muito importantes nos últimos dois anos, pois as empresas continuam a mover suas cargas de trabalho para a nuvem pública. Um cluster consiste em vários componentes que cada um pode colocar seu ambiente em risco de ataques maliciosos. Para proteger seu cluster com relação a essas ameaças de segurança, deve-se assegurar que você aplique os recursos e as atualizações de segurança mais recentes do IBM Cloud Kubernetes Service e do Kubernetes em todos os componentes do cluster.

Esses componentes incluem:

Servidor de API do Kubernetes e etcd

O servidor de API do Kubernetes e o armazenamento de dados etcd são os componentes mais sensíveis que são executados em seu mestre do Kubernetes. Deve-se evitar o acesso não autorizado a esses componentes porque eles configuram e armazenam as configurações para todos os recursos que são executados no cluster, incluindo algumas configurações de segurança dos aplicativos.

Kubernetes oferece controles de segurança e restringe o acesso para proteger esses componentes e reduzir o risco de ataques.

Como é concedido o acesso ao meu servidor de API?

Por padrão, o Kubernetes requer que cada solicitação passe por vários estágios antes que o acesso ao servidor de API seja concedido.

Autenticação
Valida a identidade de uma conta de usuário ou serviço registrado.
Autorização
Limita as permissões de usuários e de contas de serviço autenticados para assegurar que eles possam acessar e operar apenas os componentes de cluster desejados.
Controle de Admissão
Valida ou transforma solicitações antes de elas serem processadas pelo servidor de API do Kubernetes. Muitos recursos do Kubernetes exigem controladores de acesso para funcionar corretamente.

O que o IBM Cloud Kubernetes Service faz para proteger meu servidor de API e meu banco de dados etcd?

A imagem a seguir mostra as configurações de segurança de cluster padrão que tratam de autenticação, autorização, controle de admissão e conectividade segura entre os nós do mestre e do trabalhador do Kubernetes.

Descreve as etapas de segurança ao acessar o servidor da API.
Etapas de segurança ao acessar o servidor da API

Revise os recursos de segurança a seguir para o servidor de API do Kubernetes e o etcd.

Mestre do Kubernetes totalmente gerenciado e dedicado

Cada cluster no IBM Cloud Kubernetes Service é controlado por um mestre do Kubernetes dedicado que é gerenciado pela IBM em uma conta do IBM Cloud proprietária da IBM. O mestre do Kubernetes é configurado com os componentes dedicados a seguir que não são compartilhados com outros clientes IBM.

  • Armazenamento de dados etcd: armazena todos os recursos do Kubernetes de um cluster, como Services, Deployments e Pods. O ConfigMaps e o Secrets do Kubernetes são dados do app armazenados como pares chave-valor para que eles possam ser usados por um app que é executado em um pod. Os dados em etcd são armazenados no disco local do principal do Kubernetes e são submetidos a backup no IBM Cloud Object Storage. Os dados são criptografados durante o trânsito para o IBM Cloud Object Storage e em repouso. É possível optar por ativar a criptografia para seus dados etcd no disco local do seu mestre do Kubernetes ativando a criptografia do IBM Key Protect para o seu cluster. Quando os dados etcd são enviados para um pod, eles são criptografados por meio de TLS para assegurar a proteção de dados e a integridade.
  • kube-apiserver: serve como o ponto de entrada principal para todas as solicitações de gerenciamento de cluster do nó do trabalhador para o mestre do Kubernetes. O servidor de API valida e processa solicitações que mudam o estado de recursos do cluster, como pods ou serviços, e armazena esse estado no armazenamento de dados etcd.
  • kube-scheduler: decide onde implementar os pods, considerando as necessidades de capacidade e desempenho, as restrições de política de hardware e software, as especificações de antiafinidade e os requisitos de carga de trabalho. Se não puder ser localizado nenhum nó do trabalhador que corresponda aos requisitos, o pod não será implementado no cluster.
  • kube-controller-manager: responsável pelo monitoramento de conjuntos de réplicas e a criação de pods correspondentes para atingir o estado especificado.
  • Konnectivity: IBM Cloud Kubernetes Service — componente específico para fornecer conectividade de rede segura para toda a comunicação entre os nós mestre e de trabalho do Kubernetes. O servidor Konnectivity trabalha em conjunto com o agente Konnectivity para conectar com segurança o nó mestre ao nó de trabalho. Essa conexão suporta solicitações apiserver proxy para seus pods e serviços e solicitações kubectl top, exec, attach e logs para o kubelet. A conexão dos nós do trabalhador com o mestre é automaticamente protegida com certificados TLS.
Monitoramento contínuo por IBM Site Reliability Engineers (SREs)

O mestre do Kubernetes, incluindo todos os componentes principais, computação, rede e recursos de armazenamento são monitorados continuamente pelos IBM Site Reliability Engineers (SREs). Os SREs aplicam os padrões de segurança mais recentes, detectam e corrigem atividades maliciosas e trabalham para assegurar a confiabilidade e disponibilidade do IBM Cloud Kubernetes Service.

Referência principal do CIS Kubernetes

Para configurar IBM Cloud Kubernetes Service, os engenheiros da IBM seguem práticas relevantes de cibersegurança da referência principal do Kubernetes publicada pelo Centro de Segurança da Internet (CIS). O cluster mestre e todos os nós do trabalhador são implementados com imagens que atendem à referência.

Comunicação segura por meio de TLS

Para usar o IBM Cloud Kubernetes Service, deve-se autenticar com o serviço usando suas credenciais. Quando você é autenticado, o IBM Cloud Kubernetes Service gera certificados TLS que criptografam a comunicação para e do servidor de API do Kubernetes e armazenamento de dados etcd para assegurar uma comunicação de ponta a ponta segura entre os nós do trabalhador e o mestre do Kubernetes. Esses certificados nunca são compartilhados entre clusters ou entre os componentes do mestre do Kubernetes.

Conectividade com nós do trabalhador

Embora o Kubernetes proteja a comunicação entre os nós do mestre e do trabalhador usando o protocolo https, nenhuma autenticação é fornecida no nó do trabalhador por padrão. Para garantir a segurança dessa comunicação, o IBM Cloud Kubernetes Service configura automaticamente uma conexão Konnectivity entre o nó mestre Kubernetes e o nó de trabalho quando o cluster é criado.

Controle de acesso de baixa granularidade

Como o administrador da conta, você pode conceder acesso a outros usuários para IBM Cloud Kubernetes Service usando o gerenciamento de acesso e de identidade (IAM) da IBM Cloud. O IAM da IBM Cloud fornece autenticação segura com a plataforma IBM Cloud, IBM Cloud Kubernetes Service e todos os recursos em sua conta. Configurar funções e permissões adequadas do usuário é a chave para restringir quem pode acessar seus recursos e para limitar o dano que um usuário pode causar quando permissões legítimas são usadas indevidamente. É possível selecionar dentre as funções de usuário predefinidas a seguir que determinam o conjunto de ações que o usuário pode executar:

  • Funções de acesso à plataforma: determine as ações relacionadas ao gerenciamento do cluster e do nó do trabalhador que um usuário pode executar no IBM Cloud Kubernetes Service.
  • Funções de acesso ao serviço: determine a Função RBAC do Kubernetes que é designada ao usuário e as ações que um usuário pode executar em relação ao servidor de API do Kubernetes. Com as funções do RBAC, os usuários podem criar recursos do Kubernetes, como implementações de app, namespaces e configmaps. Para obter mais informações sobre as funções RBAC correspondentes atribuídas a um usuário e as permissões associadas, consulte Funções de acesso ao serviço IAM.
  • Infraestrutura clássica: Permite o acesso aos recursos da sua infraestrutura clássica. As ações de exemplo que são permitidas pelas funções de infraestrutura clássica são visualizar os detalhes das máquinas de nó do trabalhador de cluster ou editar recursos de rede e de armazenamento.
  • Infraestrutura do VPC: ativa o acesso aos recursos da infraestrutura de VPC. As ações de exemplo que são permitidas pelas funções de infraestrutura de VPC estão criando uma VPC, incluindo sub-redes, mudando endereços IP flutuantes e criando instâncias do VPC Block Storage.

Para obter mais informações sobre o controle de acesso em um cluster, veja Designando acesso ao clusters.

Acesso ao pod via token de conta de serviço

Para clusters que executam o Kubernetes 1.21 e mais recente, os tokens de conta de serviço que os pods usam para se comunicar com o servidor de API do Kubernetes são limitados por tempo, atualizados automaticamente, tem escopo definido para um público de usuários em particular (o pod) e invalidados após a exclusão do pod. Para continuar se comunicando com o servidor de API, deve-se projetar os apps para ler o valor do token atualizado em uma base regular, como a cada minuto. Para obter mais informações, consulte Tokens de conta do serviço ligados.

Controladores de admissão

Os controladores de admissões são implementados para recursos específicos no Kubernetes e IBM Cloud Kubernetes Service. Com os controladores de admissão, é possível configurar políticas em seu cluster que determinam se uma ação específica no cluster é permitida ou não. Na política, é possível especificar condições quando um usuário não pode executar uma ação, mesmo que essa ação faça parte das permissões gerais que você designou o usuário usando funções RBAC. Portanto, os controladores de admissão podem fornecer uma camada extra de segurança para seu cluster antes que uma solicitação de API seja processada pelo servidor de API do Kubernetes.

Quando um cluster é criado, o IBM Cloud Kubernetes Service instala automaticamente os Controladores de admissão do Kubernetes padrão em uma ordem específica no principal do Kubernetes, que não pode ser mudada pelo usuário. Consulte a ordem dos controladores de admissão padrão por versão do cluster nas informações de referência do componente “ kube-apiserver ”.

É possível instalar seus próprios controladores de admissão no cluster ou escolher um controlador de admissão opcional, como Portieris. Com o Portieris, é possível bloquear implementações de contêiner de imagens não assinadas.

Se você instalou manualmente os controladores de admissão e não quiser mais usá-los, certifique-se de removê-los inteiramente. Se os controladores de admissão não forem completamente removidos, eles poderão bloquear todas as ações que você deseja executar no cluster.

O que mais posso fazer para proteger meu servidor de API?

Você pode restringir a conectividade de rede com o mestre do cluster de várias maneiras

  • Habilite apenas o ponto de extremidade do serviço de nuvem privada: O ponto de extremidade do serviço público só é necessário para clusters OpenShift clássicos. Ele pode ser desativado para todos os clusters de VPC. Ele também pode ser desativado para clusters Kubernetes clássicos, desde que sua conta tenha o VRF e o Service Endpoint ativados. Isso protege o mestre do cluster contra ataques na rede pública.
  • Ativar restrições baseadas em contexto: Você pode proteger o acesso à rede aos pontos de extremidade de serviço públicos e privados do cluster usando restrições baseadas em contexto (CBR). Somente são permitidas solicitações autorizadas ao mestre do cluster originadas de sub-redes nas regras de CBR. Para obter mais informações, consulte Uso de restrições baseadas em contexto.

Nó do trabalhador

Os nós do trabalhador transportam as implementações e os serviços que compõem seu app. Ao hospedar cargas de trabalho na nuvem pública, você deseja assegurar-se de que o seu app esteja protegido contra acesso, mudança ou monitoramento de um usuário ou software não autorizado.

Quem é o proprietário do nó de trabalho e eu sou responsável por garantir a segurança dele?

A propriedade de um nó do trabalhador depende do tipo de cluster que você cria e do provedor de infraestrutura que você escolhe.

  • Clusters clássicos: os nós de trabalho são provisionados na sua conta do IBM Cloud. Os nós do trabalhador são dedicados a você e é sua responsabilidade solicitar as atualizações oportunas para os nós do trabalhador para assegurar que o S.O. do nó do trabalhador e os componentes do IBM Cloud Kubernetes Service apliquem as atualizações e correções de segurança mais recentes.
  • Clusters VPC: Os nós de trabalho são provisionados em uma conta do IBM Cloud, de propriedade de IBM, para permitir o monitoramento de atividades maliciosas e a aplicação de atualizações de segurança. Não é possível acessar nós do trabalhador usando o painel da VPC. No entanto, é possível gerenciar os nós do trabalhador usando o console, a CLI ou a API do IBM Cloud Kubernetes Service. As máquinas virtuais que compõem os nós do trabalhador são dedicadas a você e é sua responsabilidade solicitar as atualizações oportunas para que seu S.O. do nó do trabalhador e os componentes do IBM Cloud Kubernetes Service apliquem as atualizações de segurança e correções mais recentes.

Para obter mais informações, consulte Suas responsabilidades usando o IBM Cloud Kubernetes Service.

Utilize o comando ibmcloud ks worker update regularmente (por exemplo, mensalmente) para aplicar atualizações e patches de segurança ao sistema operacional e para atualizar a versão do Kubernetes executada pelos seus nós de trabalho. Quando as atualizações estão disponíveis, você é notificado ao visualizar informações sobre os nós do trabalhador e principal no console ou na CLI da IBM Cloud, como com os comandos ibmcloud ks clusters ls ou ibmcloud ks workers ls --cluster <cluster_name>. As atualizações do nó do trabalhador são fornecidas pela IBM como uma imagem de nó do trabalhador integral que inclui as correções de segurança mais recentes. Para aplicar as atualizações, o nó do trabalhador deve ser reformulado e recarregado com a nova imagem. As chaves para o usuário raiz são giradas automaticamente quando o nó do trabalhador é recarregado.

Como está a configuração do meu nó de trabalho?

A imagem a seguir mostra os componentes que são configurados para cada nó do trabalhador para proteger seu nó do trabalhador de ataques maliciosos.

A imagem não inclui componentes que asseguram a comunicação segura de ponta a ponta para e por meio do nó do trabalhador. Para obter mais informações, consulte segurança de rede.

Configuração do nó de trabalho em IBM Cloud Kubernetes Service, excluindo a segurança de rede.
Configuração do nó de trabalho em IBM Cloud Kubernetes Service, excluindo a segurança de rede

CIS-imagem compatível
Cada nó de trabalho é configurado com um sistema operacional que executa os testes de desempenho publicados pelo Center of Internet Security ( CIS ). O usuário ou o proprietário da máquina não podem mudar esse sistema operacional para outro sistema operacional. Para verificar a versão atual do sistema operacional, execute o comando kubectl get nodes -o wide``. A IBM trabalha com as equipes consultivas de segurança interna e externa para resolver vulnerabilidades de conformidade de segurança em potencial. As atualizações e correções de segurança para o sistema operacional são disponibilizadas por meio do IBM Cloud Kubernetes Service e devem ser instaladas pelo usuário para manter o nó do trabalhador seguro.

IBM Cloud Kubernetes Service usa um kernel Linux para nós de trabalho. É possível executar contêineres com base em qualquer distribuição do Linux no IBM Cloud Kubernetes Service. Entre em contato com o fornecedor das imagens de contêiner para verificar se elas podem ser executadas nesse kernel.

Monitoramento contínuo por Site Reliability Engineers (SREs)
A imagem que está instalada em seus nós do trabalhador é monitorada continuamente pelos IBM Site Reliability Engineers (SREs) para detectar vulnerabilidades e problemas de conformidade de segurança. Para tratar das vulnerabilidades, os SREs criam correções de segurança e fix packs para seus nós do trabalhador. Certifique-se de aplicar essas correções assim que estiverem disponíveis para garantir um ambiente seguro para seus nós de trabalho e para os aplicativos que você executa neles.
Referência de nó do trabalhador do CIS Kubernetes
Para configurar o IBM Cloud Kubernetes Service, os engenheiros da IBM seguem práticas relevantes de segurança cibernética da referência do nó do trabalhador do Kubernetes que é publicada pelo Center of Internet Security (CIS). É possível revisar a conformidade de nós do trabalhador em padrões CIS Kubernetes benchmark.
Isolamento de cálculo
Os nós do trabalhador são dedicados a um cluster e não hospedam cargas de trabalho de outros clusters. Ao criar um cluster clássico padrão, você pode optar por provisionar seus nós de trabalho como máquinas físicas (bare metal) ou como máquinas virtuais que rodam em hardware físico compartilhado ou dedicado. Os nós de trabalho em um cluster VPC podem ser provisionados apenas como máquinas virtuais em infraestrutura compartilhada.
Opção para implementar bare metal no clássico
Se você criar um cluster clássico padrão, será possível optar por provisionar os nós do trabalhador em servidores físicos bare metal (em vez de instâncias de servidor virtual). Com máquinas bare metal, você tem controle adicional sobre o host de cálculo, como a memória ou a CPU. Essa configuração elimina o hypervisor da máquina virtual que aloca recursos físicos para máquinas virtuais executadas no host. Em vez disso, todos os recursos em uma máquina bare metal são dedicados exclusivamente ao trabalhador, portanto, não é necessário se preocupar "vizinhos indesejados" que possam compartilhar recursos ou prejudicar o desempenho. Os servidores bare metal são dedicados a você, com todos os seus recursos disponíveis para uso do cluster.
Discos criptografados
Por padrão, cada nó do trabalhador é fornecido com duas SSD locais, partições de dados criptografados AES de 256 bits. A primeira partição contém a imagem do kernel que é usada para inicializar o nó do trabalhador e não está criptografada. A segunda partição contém o sistema de arquivos de contêiner e é desbloqueada usando chaves de criptografia LUKS. Cada nó do trabalhador em um cluster tem sua própria chave de criptografia LUKS exclusiva, gerenciada pelo IBM Cloud Kubernetes Service. Ao criar um cluster ou incluir um nó do trabalhador em um cluster existente, as chaves são obtidas de forma segura e, depois, descartadas após o disco criptografado ser desbloqueado. A criptografia pode impactar o desempenho de E/S do disco. Para cargas de trabalho que requerem E/S de disco de alto desempenho, teste um cluster com criptografia ativada e desativada para ajudá-lo a decidir se deseja desativar a criptografia.
Políticas do Expert AppArmor
Todo nó do trabalhador é configurado com políticas de segurança e acesso que são aplicadas por perfis do AppArmor carregados no nó do trabalhador durante a autoinicialização. Os perfis do appArmor não podem ser alterados pelo usuário ou proprietário da máquina.
SSH desativado
Por padrão, o acesso SSH é desativado no nó do trabalhador para proteger seu cluster de ataques maliciosos. Quando o acesso SSH está desativado, o acesso ao cluster é forçado por meio do servidor de API do Kubernetes. O servidor de API do Kubernetes requer que cada solicitação seja verificada com relação às políticas que estão configuradas no módulo de autenticação, autorização e controle de admissão antes de a solicitação ser executada no cluster.
Se você tem um cluster padrão e deseja instalar mais recursos no nó do trabalhador, é possível escolher entre os complementos fornecidos pelo IBM Cloud Kubernetes Service ou usar Conjuntos de daemons do Kubernetes para tudo o que você deseja executar em cada nó do trabalhador. Para qualquer ação única que você deve executar, use Tarefas do Kubernetes.

Rede

A abordagem clássica para proteger a rede de uma empresa é configurar um firewall e bloquear qualquer tráfego indesejado de rede para seus apps. Embora isso ainda seja verdadeiro, a pesquisa mostra que muitos ataques maliciosos vêm de internos ou usuários autorizados que usam indevidamente suas permissões designadas.

Segmentação de rede e privacidade para clusters clássicos

Para proteger sua rede e limitar o intervalo de danos que um usuário pode fazer quando o acesso a uma rede é concedido, deve-se assegurar que suas cargas de trabalho estejam tão isoladas quanto possível e que você limite o número de apps e nós do trabalhador que são expostos publicamente.

Que tipo de tráfego de rede é permitido por padrão para o meu cluster Classic?

Todos os contêineres são protegidos pelas configurações de política de rede predefinidas do Calico que são configuradas em cada nó do trabalhador durante a criação do cluster. Por padrão, todo o tráfego de rede de saída é permitido para todos os nós do trabalhador. O tráfego de rede de entrada está bloqueado com as exceções a seguir:

O acesso do master do Kubernetes ao kubelet do nó de trabalho é protegido por um túnel Konnectivity. Para obter mais informações, consulte a Arquitetura do IBM Cloud Kubernetes Service.

O que é segmentação de rede e como posso configurá-la para um cluster Classic?

A segmentação de rede descreve a abordagem para dividir uma rede em diversas sub-redes. É possível agrupar apps e dados relacionados para serem acessados por um grupo específico em sua organização. Os apps que são executados em uma sub-rede não podem ver ou acessar apps em outra sub-rede. A segmentação de rede também limita o acesso que é fornecido a um software de interno ou de terceiro e pode limitar o intervalo de atividades maliciosas.

O IBM Cloud Kubernetes Service fornece IBM Cloud VLANs que asseguram desempenho de rede de qualidade e isolamento de rede para nós do trabalhador. Uma VLAN configura um grupo de nós do trabalhador e pods como se eles estivessem conectados à mesma ligação física. As VLANs são dedicadas à sua conta do IBM Cloud e não são compartilhadas entre clientes IBM. Em clusters clássicos, caso haja várias VLANs para o cluster, várias sub-redes na mesma VLAN ou um cluster clássico de várias zonas, deve-se ativar uma Virtual Router Function (VRF) para a conta de infraestrutura do IBM Cloud para que os nós do trabalhador possam se comunicar entre si na rede privada. Para ativar o VRF, consulte Ativando o VRF. Para verificar se um VRF já está ativado, use o comando ibmcloud account show. Se não puder ou não quiser ativar a VRF, ative a Ampliação de VLAN. Para realizar essa ação, você precisa da permissão de infraestrutura “ Rede > Gerenciar a extensão de VLANs da rede ” ou pode solicitar ao proprietário da conta que a habilite. Para verificar se o spanning de VLAN já está habilitado, use o comando ibmcloud ks vlan spanning get --region .

Quando você ativa o VRF ou o VLAN Spanning para a sua conta, a segmentação de rede é removida para seus clusters.

Revise a tabela a seguir para ver suas opções de como alcançar a segmentação de rede quando ativar o VRF ou o VLAN Spanning para a sua conta.

Opções de segmentação de rede
Recurso de segurança Descrição
Configurar políticas de rede customizadas com o Calico É possível usar a interface integrada do Calico para configurar políticas de rede customizadas do Calico para os seus nós do trabalhador. Por exemplo, é possível permitir ou bloquear o tráfego de rede em interfaces de rede específicas, para pods específicos ou serviços. Para configurar políticas de rede customizadas, deve-se instalar a CLI calicoctl.
Suporte para firewalls de rede do IBM Cloud O IBM Cloud Kubernetes Service é compatível com todas as ofertas de firewall da IBM Cloud. Por exemplo, é possível configurar um firewall com políticas de rede customizadas para fornecer segurança de rede dedicada ao seu cluster padrão e para detectar e corrigir intrusão de rede. Por exemplo, você pode escolher configurar um Virtual Router Appliance para agir como seu firewall e bloquear tráfego indesejado. Ao configurar um firewall, deve-se também abrir as portas e os endereços IP necessários para cada região para que o mestre e os nós do trabalhador possam se comunicar.

O que mais posso fazer para reduzir a superfície de ataque externa dos clusters Classic?

Quanto mais apps ou nós do trabalhador você expõe publicamente, mais etapas devem ser executadas para evitar ataques maliciosos externos. Revise a tabela a seguir para localizar opções sobre como manter apps e nós do trabalhador privados.

Opções de serviços privados e nó do trabalhador
Recurso de segurança Descrição
Limitar o número de apps expostos Por padrão, os seus apps e serviços que são executados dentro do cluster não são acessíveis na Internet pública. É possível escolher se você deseja expor seus apps ao público ou se deseja que seus apps e serviços sejam acessíveis somente na rede privada. Quando você mantém seus apps e serviços privados, é possível alavancar os recursos de segurança integrados para assegurar a comunicação protegida entre os nós do trabalhador e os pods. Para expor serviços e apps à Internet pública, é possível utilizar o Suporte ao NLB e ao ALB do Ingress para tornar os serviços publicamente disponíveis de forma segura. Assegure-se de que apenas os serviços necessários sejam expostos e revisite a lista de apps expostos regularmente para assegurar que eles ainda sejam válidos.
Manter nós do trabalhador privados Ao criar um cluster, cada cluster é conectado automaticamente a uma VLAN privada. A VLAN privada determina o endereço IP privado que é designado a um nó do trabalhador. É possível escolher manter seus nós do trabalhador privados conectando-os somente a uma VLAN privada. Lembre-se de que, para se comunicar com o servidor principal do Kubernetes a partir da sua máquina local e para que o IBM Cloud Kubernetes Service se conecte aos serviços do IBM Cloud que não oferecem suporte a um endpoint de serviço em nuvem privada, é necessário configurar a conectividade pública para URLs e endereços IP específicos. Se os serviços da IBM Cloud aos quais você deseja se conectar tiverem um terminal em serviço de nuvem privada e sua conta estiver ativada para VRF, o tráfego de rede para/de esses serviços será roteado automaticamente por meio da rede privada e não será necessária nenhuma conexão de rede pública. Para configurar a conectividade pública para o cluster que está conectado a uma VLAN privada apenas, é possível configurar um firewall, como um Virtual Router Appliance, na frente de seus nós do trabalhador e ativar o tráfego de rede para essas URLs e endereços IP.
Limitar a conectividade de Internet pública com nós de borda Se você não criar um cluster com um gateway ativado, cada nó do trabalhador será configurado para aceitar pods de app e pods de balanceador de carga ou de ingresso associados. É possível rotular nós do trabalhador como nós de borda para forçar a implementação dos pods do balanceador de carga e do Ingress apenas nesses nós do trabalhador. Além disso, é possível contaminar os nós do trabalhador para que os pods de app não possam planejar nos nós de borda. Com os nós de borda, é possível isolar a carga de trabalho de rede em menos nós do trabalhador em seu cluster e manter outros nós do trabalhador privados no cluster.

E se eu quiser conectar meu cluster a um data center local?

Para conectar seus nós de trabalho e aplicativos a um data center local, você pode configurar um Virtual Router Appliance ou um Fortigate Security Appliance.

Segmentação de rede e privacidade para clusters VPC

Para proteger sua rede e limitar o intervalo de danos que um usuário pode fazer quando o acesso a uma rede é concedido, deve-se assegurar que suas cargas de trabalho estejam tão isoladas quanto possível e que você limite o número de apps e nós do trabalhador que são expostos publicamente.

Qual tráfego de rede é permitido por padrão para o meu cluster VPC?

Por padrão, os nós do trabalhador são conectados a sub-redes de VPC somente na rede privada e não têm uma interface de rede pública. Todo ingresso público aos nós do trabalhador está bloqueado. O egresso público dos nós do trabalhador é permitido somente se os trabalhadores estiverem conectados a uma sub-rede VPC que tenha um gateway público.

Se os nós do trabalhador devem acessar um terminal público fora do cluster, será possível anexar um gateway público à sub-rede VPC na qual os nós do trabalhador estão implementados. Por exemplo, seu cluster de VPC pode conectar-se automaticamente a outros serviços da IBM Cloud que suportam terminais em serviço de nuvem privada, como o IBM Cloud Container Registry. No entanto, se precisar acessar serviços da IBM Cloud que suportam somente terminais em serviço de nuvem pública, é possível conectar um gateway público à sub-rede para que seus pods possam enviar solicitações por meio da rede pública. Todos os egressos são permitidos para nós do trabalhador em uma sub-rede com um gateway público conectado, mas todo o ingresso ainda está bloqueado.

Se você implementar apps em seu cluster que devem receber solicitações de tráfego por meio da Internet, você poderá criar um balanceador de carga do VPC para expor seus apps. Para permitir o tráfego de rede de ingresso em seus apps, deve-se configurar seu balanceador de carga do VPC para o tráfego de rede de ingresso que você deseja receber.

Os grupos de segurança são aplicados à sua instância de VPC e aos ALBs e NLBs da VPC por padrão. Para obter mais informações, consulte Noções básicas sobre redes de VPC de cluster seguras por padrão e Criação e gerenciamento de grupos de segurança de VPC.

O que é segmentação de rede e como posso configurá-la para um cluster VPC?

A segmentação de rede descreve a abordagem para dividir uma rede em diversas sub-redes. É possível agrupar apps e dados relacionados para serem acessados por um grupo específico em sua organização. Os apps que são executados em uma sub-rede não podem ver ou acessar apps em outra sub-rede. A segmentação de rede também limita o acesso que é fornecido a um software de interno ou de terceiro e pode limitar o intervalo de atividades maliciosas.

O IBM Cloud Kubernetes Service fornece sub-redes de IBM Cloud VPC que garantem o desempenho de rede e o isolamento de rede de qualidade para nós do trabalhador. Uma sub-rede do VPC consiste em um intervalo de endereços IP privados especificados (bloco CIDR) e configura um grupo de nós do trabalhador e pods como se eles estivessem conectados à mesma ligação física. As sub-redes VPC são dedicadas à sua conta do IBM Cloud e não são compartilhadas entre os clientes da IBM.

As sub-redes VPC fornecem um canal para conectividade entre os nós do trabalhador dentro do cluster. Qualquer sistema que esteja conectado a qualquer uma das sub-redes privadas no mesmo VPC pode se comunicar com os trabalhadores. Por exemplo, todas as sub-redes em uma VPC podem se comunicar por meio do roteamento privado de camada 3 com um roteador integrado da VPC. Se os clusters não precisarem se comunicar, será possível conseguir a melhor segmentação de rede criando os clusters em VPCs separadas. Se tiver diversos clusters que devam se comunicar uns com os outros, será possível criá-los na mesma VPC. Embora as sub-redes dentro de uma VPC possam ser compartilhadas por diversos clusters nela, é possível obter uma melhor segmentação de rede usando sub-redes diferentes para eles.

Para obter segmentação de rede privada adicional entre as sub-redes VPC para a sua conta, é possível configurar políticas de rede customizadas com listas de controle de acesso (ACLs) de VPC. Ao criar uma VPC, uma ACL padrão é criada no formato allow-all-network-acl-<VPC_ID> para a VPC. Qualquer sub-rede que você criar na VPC é conectada a essa ACL por padrão. A ACL inclui uma regra de entrada e uma regra de saída que permitem todo o tráfego entre os nós do trabalhador em uma sub-rede e qualquer sistema nas sub-redes na mesma VPC. Para especificar qual tráfego de rede privada é permitido para os nós do trabalhador em suas sub-redes de VPC, é possível criar uma ACL customizada para cada sub-rede na VPC. Por exemplo, é possível criar um conjunto de regras de ACL para bloquear a maioria do tráfego de rede privada de entrada e de saída de um cluster, ao mesmo tempo em que permite a comunicação necessária para que o cluster funcione.

O que mais posso fazer para reduzir a superfície de exposição a ataques externos nos clusters de VPC?

Quanto mais apps ou nós do trabalhador você expõe publicamente, mais etapas devem ser executadas para evitar ataques maliciosos externos. Revise a tabela a seguir para localizar opções sobre como manter apps e nós do trabalhador privados.

Opções de segurança de rede VPC
Recurso de segurança Descrição
Limitar o número de apps expostos Por padrão, os seus apps e serviços que são executados dentro do cluster não são acessíveis na Internet pública. É possível escolher se você deseja expor seus apps ao público ou se deseja que seus apps e serviços sejam acessíveis somente na rede privada. Quando você mantém seus apps e serviços privados, é possível alavancar os recursos de segurança integrados para assegurar a comunicação protegida entre os nós do trabalhador e os pods. Para expor serviços e apps para a Internet pública, é possível aproveitar o balanceador de carga do VPC e o suporte de ALB do Ingress para tornar os seus serviços disponíveis publicamente de forma segura. Assegure-se de que apenas os serviços necessários sejam expostos e revisite a lista de apps expostos regularmente para assegurar que eles ainda sejam válidos.
Limitar o egresso da rede pública a uma sub-rede com um gateway público Se os pods em seus nós do trabalhador precisarem se conectar a um terminal externo público, será possível anexar um gateway público à sub-rede na qual esses nós do trabalhador estão. É possível isolar esse tráfego de rede em seu cluster conectando um gateway público a apenas uma sub-rede em seu cluster. Em seguida, é possível configurar as regras de afinidade para implementar pods de app que requerem acesso a terminais externos como somente a sub-rede com um gateway público conectado.

Dependendo da rede para a qual você deseja conectar seus nós do trabalhador, é possível escolher uma solução VPN.

Expor os apps de forma segura com os serviços LoadBalancer e Ingress

É possível usar os serviços de rede do balanceador de carga de rede (NLB) e do balanceador de carga do aplicativo (ALB) Ingress para conectar seus apps à Internet pública ou a redes privadas externas. Revise as configurações opcionais a seguir para NLBs e ALBs que podem ser usadas para atender aos requisitos de segurança do app de back-end ou criptografe o tráfego que se move por seu cluster.

Posso usar grupos de segurança para gerenciar o tráfego de rede do meu cluster?

Clusters clássicos: os grupos de segurança da IBM Cloud são aplicados à interface de rede de um único servidor virtual para filtrar o tráfego no nível do hypervisor. Se você desejar gerenciar o tráfego para cada nó do trabalhador, será possível usar grupos de segurança. Ao criar um grupo de segurança, deve-se permitir o protocolo VRRP, que o IBM Cloud Kubernetes Service usa para gerenciar endereços IP do NLB. Para gerenciar o tráfego do seu cluster de maneira uniforme em todos os seus nós de trabalho, utilize as políticas Calico e Kubernetes.

Clusters de VPC: os grupos de segurança da VPC são aplicados à interface de rede de um servidor virtual único para filtrar o tráfego no nível do hypervisor. É possível incluir regras de entrada e de saída no grupo de segurança padrão para o seu cluster gerenciar o tráfego de entrada e de saída para um cluster de VPC. Para obter mais informações, consulte Noções básicas sobre redes de VPC de cluster seguras por padrão e Criação e gerenciamento de grupos de segurança de VPC.

Como os nós do trabalhador do cluster de VPC existem em uma conta de serviço e não são listados no painel da infraestrutura VPC, não é possível criar um grupo de segurança e aplicá-lo em instâncias do nó do trabalhador. É possível modificar somente os grupos de segurança existentes que são criados para você.

Como posso proteger o endereço IP de origem dentro do cluster?

Em NLBs na versão 2.0, o endereço IP de origem da solicitação do cliente é preservado por padrão. No entanto, em NLBs na versão 1.0 e em todos os ALBs do Ingress, o endereço IP de origem da solicitação do cliente não é preservado. Quando uma solicitação do cliente para seu app é enviada ao seu cluster, ela é roteada para um pod para o NLB 1.0 ou o ALB. Se nenhum pod de app existir no mesmo nó do trabalhador que o pod do serviço do balanceador de carga, o NLB ou o ALB encaminhará a solicitação para um pod de app em um nó do trabalhador diferente. O endereço IP de origem do pacote é mudado para o endereço IP público do nó do trabalhador no qual o pod do app é executado.

Preservar o IP do cliente é útil, por exemplo, quando os servidores de app precisam aplicar as políticas de segurança e de controle de acesso. Para preservar o endereço IP de origem original da solicitação do cliente, é possível permitir a preservação do IP de origem para NLBs da versão 1.0 ou para ALBs do Ingress.

Como posso realizar a terminaçã TLS e com os serviços “ LoadBalancer ” e “Ingress”?

O serviço Ingresso oferece finalização de TLS em dois pontos no fluxo de tráfego:

  • Descriptografar o pacote na chegada: Por padrão, o Ingress ALB distribui o tráfego de rede d HTTP para os aplicativos em seu cluster. Para também balancear a carga de conexões HTTPS recebidas, será possível configurar o ALB para decriptografar o tráfego de rede e encaminhar a solicitação decriptografada para os apps expostos no cluster. Se você usar o subdomínio do Ingress fornecido pela IBM, será possível usar o certificado do TLS fornecido pela IBM. Se você usar um domínio customizado, será possível usar o seu próprio certificado do TLS para gerenciar a rescisão do TLS.
  • Criptografe novamente o pacote antes de encaminhá-lo para apps de envio de dados: o ALB decriptografa as solicitações de HTTPS antes de encaminhar o tráfego para seus apps. Se você tiver apps que requerem HTTPS e precisar que o tráfego seja criptografado antes de ser encaminhado para esses apps de envio de dados, será possível usar a anotação ssl-services. Se seus apps de envio de dados puderem manipular o TLS, será possível, opcionalmente, fornecer um certificado que está contido em um segredo de TLS de autenticação mútua ou unidirecional.

Para assegurar a comunicação de serviço para serviço, é possível usar a autenticação mútua TLS do Istio. Istio é um serviço de software livre que fornece aos desenvolvedores uma maneira de conectar, assegurar, gerenciar e monitorar uma rede de microsserviços, também conhecida como malha de serviço, em plataformas de orquestração de nuvem como o Kubernetes.

Armazenamento persistente

Revise as opções suportadas para criptografar e proteger seus dados no armazenamento persistente no IBM Cloud.

Por padrão, todas as soluções de armazenamento do IBM Cloud criptografam automaticamente seus dados em repouso com uma chave de criptografia gerenciada pela IBM sem nenhum custo adicional. Para obter mais informações, veja os links a seguir.

Dependendo do tipo de armazenamento que você escolher, será possível configurar a criptografia adicional com o IBM Key Protect para proteger seus dados em trânsito e em repouso com sua própria chave de criptografia.

Também é possível usar um serviço de banco de dados do IBM Cloud, como IBM Cloudant NoSQL DB , para persistir dados em um banco de dados gerenciado fora do cluster. Os dados que são armazenados com um serviço de banco de dados em nuvem podem ser acessados entre clusters, zonas e regiões. Para obter informações relacionadas à segurança, veja a documentação específica do serviço de banco de dados do IBM Cloud.

Monitorando e criando logs

A chave para detectar ataques maliciosos em seu cluster é o monitoramento e criação de log adequados de métricas e todos os eventos que ocorrem no cluster. O monitoramento e a criação de log também podem ajudar a entender a capacidade do cluster e a disponibilidade de recursos para seu app para que seja possível planejar adequadamente para proteger seus apps de um tempo de inatividade.

O IBM monitora meu cluster?
Cada cluster mestre é monitorado continuamente pela IBM para controlar e corrigir ataques de Negação de Serviço (DOS) em nível de processo. O IBM Cloud Kubernetes Service varre automaticamente cada nó em que o mestre é implementado para verificar as vulnerabilidades localizadas no Kubernetes e as correções de segurança específicas do SO. Se vulnerabilidades forem localizadas, o IBM Cloud Kubernetes Service aplicará automaticamente as correções e resolverá as vulnerabilidades em nome do usuário para assegurar proteção do nó principal.
Quais informações são registradas?
Por padrão, o IBM Cloud Kubernetes Service coleta automaticamente os logs para os componentes do cluster a seguir:
  • Contêineres: logs que são gravados em STDOUT ou STDERR.
  • Apps: logs que são gravados em um caminho específico dentro de seu app.
  • Trabalhadores: logs do sistema operacional Ubuntu que são enviados para /var/log/syslog e /var/log/auth.log.
  • Servidor de API do Kubernetes: cada ação relacionada ao cluster que é enviada para o servidor de API do Kubernetes é registrada por razões de auditoria, incluindo o horário, o usuário e o recurso afetado. Para obter mais informações, consulte Logs de auditoria do Kubernetes. É possível acessar esses logs usando o IBM Cloud Logs.
  • Ingress: logs para um balanceador de carga de aplicativo (ALB) do Ingress que gerencia o tráfego de rede de entrada.
  • Componentes do sistema do Kubernetes: logs do kubelet, do kube-proxy e de outros componentes que são executados no namespace kube-system.

Para acessar os logs do componente do cluster, é possível optar por encaminhar seus logs para o IBM Cloud Logs}}, um servidor externo ou uma solução de criação de log de terceiros. Para obter mais informações, consulte Escolhendo uma solução de criação de log.

Como posso monitorar o estado e o desempenho do meu cluster?
É possível verificar o funcionamento, a capacidade e o desempenho de seus apps, serviços e nós do trabalhador monitorando os componentes do cluster e os recursos de cálculo por meio do console ou da CLI do IBM Cloud Kubernetes Service, como o uso de CPU e memória. Para visualizar métricas mais detalhadas para um cluster padrão ou para seus apps, é possível configurar um agente de monitoramento em seu cluster para enviar métricas para o IBM Cloud Monitoring. Você também pode instalar soluções de monitoramento de terceiros, como o Prometheus, ou utilizar as métricas fornecidas no painel do Kubernetes. Para obter mais informações, consulte Escolhendo uma solução de monitoramento.

Para configurar um sistema de detecção de intrusão baseado em host (HIDS) e o monitoramento de logs de eventos de segurança (SELM), instale ferramentas de terceiros projetadas para monitorar seu cluster e seus aplicativos em contêineres, a fim de detectar invasões ou uso indevido, como o Twistlock ou o projeto “ Falco ” da Sysdig.

Como posso monitorar os eventos que ocorrem no meu cluster?
É possível configurar o IBM Cloud Logs no cluster do IBM Cloud Kubernetes Service. Para obter mais informações, consulte a documentação Saiba mais sobre IBM Cloud Logs.
Quais são as minhas opções para habilitar a confiança no meu cluster?
Por padrão, o IBM Cloud Kubernetes Service fornece muitos recursos para seus componentes do cluster para que seja possível implementar seus apps conteinerizados em um ambiente de segurança avançada. Amplie seu nível de confiança no cluster para melhor assegurar que o que acontece dentro de seu cluster é o que você pretende que aconteça. É possível implementar confiança no cluster de várias maneiras, conforme mostrado no diagrama a seguir.

Implantação de contêineres com conteúdo confiável.
Implantação de contêineres com conteúdo confiável

  1. Confiança de conteúdo para suas imagens: assegure-se a integridade de suas imagens, ativando a confiança de conteúdo em seu IBM Cloud Container Registry. Com o conteúdo confiável, é possível controlar quem pode assinar imagens como confiáveis. Depois que os assinantes confiáveis enviam uma imagem por push para seu registro, os usuários podem puxar o conteúdo assinado para que possam verificar a origem da imagem. Para obter mais informações, veja Assinando imagens para conteúdo confiável.

  2. Cumprimento de segurança da imagem de contêiner: use um controlador de admissão com políticas customizadas para poder verificar as imagens de contêiner antes de implementá-las. Com um projeto de aplicação de segurança de imagem de contêiner como o Portieris, você controla onde as imagens são implementadas e assegura que elas atendam aos requisitos de confiança de conteúdo. Se uma implementação não atender às políticas configuradas, a aplicação de segurança evitará modificações no cluster.

  3. Scanner de vulnerabilidade de imagem: por padrão, o Vulnerability Advisor varre imagens que são armazenadas no IBM Cloud Container Registry para localizar potenciais vulnerabilidades de segurança. Para obter mais informações, consulte Gerenciando a segurança de imagens com o Vulnerability Advisor.

  4. IBM Cloud Compliance Manager: ao ativar o IBM Cloud Compliance Manager, é possível visualizar relatórios sobre tráfego de rede de entrada e saída suspeitas. Para obter informações adicionais, consulte a documentação do IBM Cloud Compliance Manager.

  5. IBM Cloud® Secrets Manager: é possível armazenar os segredos do Ingress e do Kubernetes no IBM Cloud® Secrets Manager. Ao integrar o Secrets Manager ao cluster, você configura uma instância padrão do Secrets Manager na qual todos os segredos de subdomínio do Ingress são transferidos por upload. Para obter mais informações, consulte Configurando o Secrets Manager no seu cluster Kubernetes Service.

Imagem e registro

Cada implementação é baseada em uma imagem que contém as instruções sobre como acelerar o contêiner que executa seu app. Essas instruções incluem o sistema operacional dentro do contêiner e o software extra que você deseja instalar. Para proteger o seu app, deve-se proteger a imagem e estabelecer verificações para assegurar a integridade da imagem.

Devo usar um registro público ou privado para armazenar minhas imagens?
Os registros públicos, como o Docker Hub, podem ser usados para iniciar imagens do Docker e Kubernetes para criar seu primeiro app conteinerizado em um cluster. Mas quando se tratar de aplicativos corporativos, evite registros que você não conheça ou não confie para proteger o seu cluster de imagens maliciosas. Mantenha suas imagens em um registro privado, como aquele fornecido no IBM Cloud Container Registry e certifique-se de controlar o acesso ao registro e ao conteúdo da imagem que pode ser enviado por push.
Por que é importante verificar se as imagens apresentam vulnerabilidades?
Pesquisas mostram que os ataques mais maliciosos alavancam as vulnerabilidades conhecidas de software e as configurações fracas de sistema. Ao implementar um contêiner por meio de uma imagem, o contêiner acelera com o S.O e os binários adicionais que você descreveu na imagem. Assim como você protege sua máquina virtual ou física, deve-se eliminar as vulnerabilidades conhecidas no S.O. e os binários usados dentro do contêiner para proteger seu app de ser acessado por usuários não autorizados.

Para proteger seus apps, considere abordar as seguintes áreas:

  1. Automatizar o processo de construção e limitar permissões: automatize o processo para construir a imagem de contêiner por meio do código-fonte a fim de eliminar variações e defeitos de código-fonte. Ao integrar o processo de construção em seu pipeline CI/CD, é possível assegurar que sua imagem seja varrida e construída apenas se a imagem passar pelas verificações de segurança que você especificou. Para evitar que os desenvolvedores apliquem as hotfixes a imagens sensíveis, limite o número de pessoas em sua organização que têm acesso ao processo de construção.

  2. Varrer imagens antes de sua implementação na produção: Certifique-se de varrer cada imagem antes de implementar um contêiner por meio dela. Por exemplo, se você usar o IBM Cloud Container Registry, todas as imagens serão varridas automaticamente em busca de vulnerabilidades quando enviar por push a imagem para seu namespace. Se vulnerabilidades forem localizadas, considere eliminar as vulnerabilidades ou bloquear a implementação para essas imagens. Localize uma pessoa ou uma equipe em sua organização que seja responsável por monitorar e remover vulnerabilidades. Dependendo de sua estrutura organizacional, essa pessoa pode fazer parte de uma equipe de segurança, de operações ou de implementação. Ative a confiança de conteúdo para que as imagens sejam aprovadas por um assinante confiável antes que possam ser enviadas por push para o registro de contêiner. Em seguida, instale o controlador de admissão do projeto de software livre Portieris para bloquear implementações de contêiner por meio de imagens não assinadas.

  3. Varrer regularmente os contêineres em execução: Mesmo se você implementou um contêiner por meio de uma imagem que passa pela verificação de vulnerabilidade, o sistema operacional ou os binários que são executados no contêiner podem ficar vulneráveis ao longo do tempo. Para proteger seu app, deve-se assegurar que os contêineres em execução sejam varridos regularmente para que seja possível detectar e corrigir vulnerabilidades. Dependendo do aplicativo, para aumentar a segurança, você pode configurar uma tarefa que encerre os contêineres vulneráveis assim que forem detectados.

Segurança para imagens e implementações
Recurso de segurança Descrição
Repositório de imagem privada Docker assegurado em IBM Cloud Container Registry Configure seu próprio repositório de imagens Docker em um registro de imagem privada escalável altamente disponível de diversos locatários hospedado e gerenciado pela IBM. Ao usar o registro, é possível construir, armazenar de forma segura e compartilhar imagens Docker entre usuários de cluster. /n Saiba mais sobre como proteger informações pessoais ao trabalhar com imagens de contêiner.
Envie por push apenas imagens com conteúdo confiável Assegure a integridade das imagens ativando a confiança de conteúdo no repositório de imagens. Com o conteúdo confiável, é possível controlar quem pode assinar imagens como confiáveis e enviar por push imagens para um namespace de registro específico. Após os assinantes confiáveis enviarem uma imagem por push para um espaço de nomes de registro, os usuários poderão extrair o conteúdo assinado para poder verificar o publicador e a integridade da imagem.
Varreduras automáticas de vulnerabilidade Ao usar IBM Cloud Container Registry, é possível alavancar a varredura de segurança integrada fornecida pelo Orientador de vulnerabilidades. Cada imagem que é enviada por push para seu namespace de registro é varrida automaticamente em busca de vulnerabilidades com relação a um banco de dados de problemas conhecidos do CentOS, Debian, Red Hat e Ubuntu. Se forem localizadas vulnerabilidades, o Vulnerability Advisor fornecerá instruções de como resolvê-las para assegurar a integridade e a segurança da imagem.
Bloqueie as implementações por meio de imagens vulneráveis ou de usuários não confiáveis Crie um controlador de admissão com políticas customizadas para poder verificar as imagens de contêiner antes de implementá-las. Com o projeto de software livre Portieris, você controla onde as imagens são implementadas e assegura que elas atendam aos requisitos de confiança de conteúdo. Se uma implementação não atender às políticas configuradas, o controlador de admissão bloqueará a implementação no cluster.
Quais são as opções disponíveis para verificar se há vulnerabilidades em contêineres em execução?
É possível instalar soluções de terceiros no cluster, como Twistlock ou StackRox para varrer contêineres em execução e bloquear atividades maliciosas detectadas.

Isolamento e segurança do contêiner

Ao executar diversos apps em seu cluster, você deseja certificar-se de que suas cargas de trabalho sejam executadas isoladas umas das outras e que você restrinja as permissões de seus pods dentro do cluster para evitar vizinhos barulhentos ou ataques de negação de serviço.

O que é um namespace “ Kubernetes ” e por que eu deveria usá-lo?
Os namespaces do Kubernetes são uma maneira de particionar virtualmente um cluster e fornecer isolamento para suas implementações e os grupos de usuários que desejam mover sua carga de trabalho para o cluster. Com namespaces, é possível organizar recursos entre os nós do trabalhador e também entre as zonas em clusters de múltiplas zonas.
Cada cluster é configurado com um conjunto de namespaces padrão do Kubernetes que incluem as implementações e serviços que são necessários para que o IBM Cloud Kubernetes Service execute adequadamente e gerencie o cluster. Para obter mais informações, consulte a arquitetura de serviço.
Os administradores de cluster têm automaticamente acesso a esses namespaces e podem configurar namespaces adicionais no cluster.

Para cada namespace que você tiver no cluster, certifique-se de configurar Políticas do RBAC adequadas para limitar o acesso a esse namespace, controlar o que é implementado e configurar cotas de recursos e intervalos de limite adequados.

Devo configurar um cluster de locatário único ou um cluster multilocatário?

Em um cluster de locatário único, você cria um cluster para cada grupo de pessoas que devem executar cargas de trabalho em um cluster. Geralmente, essa equipe é responsável por gerenciar o cluster e configurar e protegê-lo adequadamente. Os clusters de diversos locatários usam múltiplos namespaces para isolar locatários e as suas cargas de trabalho.

Escolhendo entre um cluster de locatário único ou um cluster multilocatário.
Cluster de locatário único versus cluster multilocatário

A decisão entre clusters de único locatário e de vários locatários depende do número de equipes que devem executar cargas de trabalho em um cluster, de seus requisitos de serviço, do tamanho do serviço e do nível de isolamento que você deseja atingir para as suas cargas de trabalho.

Um cluster de locatário único pode ser sua opção se você tem muitas equipes com serviços complexos e cada uma delas precisa ter controle sobre o ciclo de vida do cluster. Isso inclui ter a liberdade de decidir quando um cluster é atualizado ou quais recursos podem ser implementados no cluster. Também é possível configurar um cluster de locatário único para permitir pods privilegiados sem colocar outros locatários em risco de serem comprometidos. Tenha em mente que o gerenciamento de um cluster requer conhecimento profundo do Kubernetes e da infraestrutura para assegurar a capacidade do cluster e a segurança para suas implementações.

Os clusters de diversos locatários usam namespaces do Kubernetes para isolar locatários e são geralmente gerenciados por uma equipe separada que não pertence a um dos locatários. Um cluster de vários locatários pode ser sua opção se você tem diversas equipes que devem executar cargas de trabalho pequenas em um cluster e em locais nos quais a criação de um cluster de locatário único que esteja altamente disponível em várias zonas não traz os benefícios de custo que você deseja. Embora os clusters de vários locatários geralmente requeiram menos pessoas para gerenciar e administrar o cluster, eles podem não fornecer o nível de isolamento necessário e incluir mais complexidade nas seguintes áreas:

  • Acesso: ao configurar múltiplos namespaces, deve-se configurar políticas de RBAC adequadas para cada namespace para assegurar o isolamento de recursos. As políticas de RBAC são complexas e requerem conhecimento profundo do Kubernetes.
  • Pods privilegiados: se um locatário em um cluster de vários locatários precisar executar pods privilegiados, esses pods poderão acessar outros namespaces no cluster ou danificar o host de cálculo compartilhado. Controlar pods privilegiados é uma tarefa complexa que requer esforço e conhecimento técnico profundo. Use as políticas de segurança de pod (PSPs) para controlar quais recursos seus locatários podem implantar no cluster.
  • Políticas de rede: como os nós do trabalhador estão conectados à mesma rede privada, deve-se assegurar que haja políticas de rede estritas em vigor a fim de evitar que pods acessem pods em outros namespaces.
  • Limitação de recursos de cálculo: para assegurar que toda a equipe tenha os recursos necessários para implementar serviços e executar apps no cluster, deve-se configurar cotas de recursos para cada namespace. As cotas de recursos determinam as restrições de implantação, como o número de recursos do Kubernetes que você pode implantar e a quantidade de CPU e memória que esses recursos podem consumir. Depois de configurar uma cota, os usuários devem incluir solicitações de recurso e limites em suas implementações.
  • Recursos de cluster compartilhados: se você executar diversos locatários em um cluster, alguns recursos de cluster, como o balanceador de carga do aplicativo (ALB) Ingress ou os endereços IP móveis disponíveis, serão compartilhados entre locatários. Os serviços menores podem ter dificuldade ao usar recursos compartilhados se eles devem competir com os serviços grandes no cluster.
  • Atualizações: é possível executar somente uma versão de API do Kubernetes por vez. Todos os apps que são executados em um cluster devem obedecer à versão de API do Kubernetes atual, independentemente da equipe que possuir o app. Quando desejar atualizar um cluster, assegure-se de que todas as equipes estejam prontas para alternar para uma nova versão da API do Kubernetes e que os apps sejam atualizados adequadamente. Isso também significa que as equipes individuais têm menos controle sobre a versão de API do Kubernetes que elas desejam executar.
  • Mudanças na configuração do cluster: se você desejar mudar a configuração do cluster ou reagendar as cargas de trabalho para os novos nós do trabalhador, essa mudança deverá ser apresentada entre os locatários. Essa apresentação requer mais reconciliação e teste do que em um cluster de locatário único.
  • Processo de comunicação: ao gerenciar diversos locatários, considere a configuração de um processo de comunicação para que os locatários saibam para onde ir quando um problema com o cluster existir ou quando eles precisarem de mais recursos para seus serviços. Esse processo de comunicação também inclui informar seus locatários sobre todas as mudanças na configuração do cluster ou nas atualizações planejadas.

Embora os clusters de locatário único e de vários locatários venham com aproximadamente os mesmos custos, os clusters de locatário único fornecem um nível mais alto de isolamento do que os namespaces em um cluster de vários locatários. Para melhor isolamento de carga de trabalho, use clusters de locatário único.

Políticas de rede do Kubernetes protegem os pods do tráfego interno de rede. Por exemplo, se a maioria ou todos os pods não requererem acesso a pods ou serviços específicos, e você quiser assegurar que os pods não possam acessar esses pods ou serviços por padrão, você poderá criar uma política de rede de Kubernetes para bloquear o tráfego de ingresso para esses pods ou serviços. As políticas de rede do Kubernetes também podem ajudar a aplicar o isolamento de carga de trabalho entre os namespaces, controlando como os pods e os serviços em diferentes namespaces podem se comunicar.

Como posso controlar as permissões dos pods?
Por padrão, todo cluster ativa o Controlador de admissão de política de segurança de pod do Kubernetes que você pode usar para definir quais requisitos um pod deve atender para ser implementado em um namespace. Com as políticas de segurança do pod, é possível controlar o uso de contêineres privilegiados, namespaces raiz, rede de host e portas, tipos de volume, sistemas de arquivos host e permissões do Linux, como IDs de leitura ou de grupo.
O que mais posso fazer para proteger meu contêiner?
Limite o número de contêineres com privilégios. Os contêineres são executados como um processo do Linux separado no host de cálculo que está isolado de outros processos. Embora os usuários tenham acesso raiz dentro do contêiner, as permissões desse usuário são limitadas fora do contêiner para proteger outros processos do Linux, o sistema de arquivos host e os dispositivos host. Alguns apps requerem acesso ao sistema de arquivos host ou permissões avançadas para executar adequadamente. É possível executar contêineres no modo privilegiado para permitir ao contêiner o mesmo acesso que os processos em execução no host de cálculo.
Tenha em mente que os contêineres privilegiados podem causar danos enormes ao cluster e ao host de cálculo subjacente se eles forem comprometidos. Tente limitar o número de contêineres que são executados em modo privilegiado e considere mudar a configuração para o seu app de modo que o app possa ser executado sem permissões avançadas.

Se você quiser impedir que contêineres com privilégios sejam executados no seu cluster, considere configurar políticas de segurança personalizadas para pods.

Aplicar configurações de segurança do S.O. aos pods
É possível incluir a seção securityContext nos pods para controlar o ID do usuário e ID do grupo que podem ser executados no contêiner, ou o ID do usuário e ID do grupo que possuem o caminho de montagem de volume. A configuração de um ID do usuário específico ajuda a facilitar um modelo menos privilegiado. Se o contexto de segurança não especificar um usuário, o Kubernetes usará automaticamente o usuário especificado na imagem de contêiner.
Se você deseja usar securityContext para configurar o ID do usuário runAsUser ou o ID do grupo fsGroup, considere usar o armazenamento de bloco ao criar o armazenamento persistente. O armazenamento NFS não suporta fsGroup e o runAsUser deve ser configurado no nível do contêiner, não no nível do pod.
Configurar limites de CPU e memória para contêineres
Cada contêiner requer uma quantia específica de CPU e memória para iniciar corretamente e continuar sendo executado. É possível definir solicitações e limites de recursos do Kubernetes para os contêineres ou pods para limitar a quantidade de CPU e memória que eles podem consumir. Se nenhum limite para CPU e memória estiver configurado e o contêiner estiver ocupado, o contêiner usará todos os recursos que estão disponíveis. Esse alto consumo de recursos pode afetar outros contêineres no nó do trabalhador que não têm recursos suficientes para iniciar ou executar devidamente, além de colocar o nó do trabalhador em risco de ataques Negação de Serviço.
Impr autenticação baseada em política
É possível incluir uma anotação do Ingress em suas implementações para controlar o acesso aos seus serviços e APIs. Usando o App ID e a segurança declarativa, é possível assegurar a autenticação do usuário e a validação do token.

Armazenando informações pessoais

Você é responsável por assegurar a segurança de suas informações pessoais em recursos do Kubernetes e imagens de contêiner. As informações pessoais incluem seu nome, endereço, número do telefone, endereço de e-mail ou outras informações que possam identificar, contatar ou localizar você, seus clientes ou qualquer outra pessoa.

Usar um segredo do Kubernetes para armazenar informações pessoais

Armazene informações pessoais somente em recursos do Kubernetes que são projetados para manter informações pessoais. Por exemplo, não use seu nome no nome de um mapa de configuração, serviço, implementação ou espaço de nomes do Kubernetes. Para proteção e criptografia adequadas, armazene informações pessoais em segredos.

Para gerenciamento centralizado de todos os seus segredos entre os clusters e injeção no tempo de execução do aplicativo, tente IBM Cloud Secrets Manager.

Use um imagePullSecret do Kubernetes para armazenar as credenciais de registro de imagem

Não armazene informações pessoais em imagens de contêiner ou namespaces de registro. Para proteção e criptografia adequadas, armazene credenciais de registro no Kubernetes imagePullSecrets e outras informações pessoais em segredos. Lembre-se de que se as informações pessoais são armazenadas em uma camada anterior de uma imagem, excluir uma imagem pode não ser suficiente para excluir essas informações pessoais.

Para configurar a criptografia para seus segredos, consulte Criptografando segredos de Kubernetes usando um provedor de serviço de gerenciamento de chaves (KMS).

Boletins de segurança do Kubernetes

Se as vulnerabilidades forem localizadas no Kubernetes, o Kubernetes liberará CVEs em boletins de segurança para informar aos usuários e para descrever as ações que os usuários devem tomar para corrigir a vulnerabilidade. Boletins de segurança do Kubernetes que afetam os usuários do IBM Cloud Kubernetes Service ou a plataforma do IBM Cloud são publicados no Boletim de segurança do IBM Cloud.

Alguns CVEs requerem a atualização de correção mais recente para uma versão do Kubernetes que pode ser instalada como parte do processo de atualização de cluster regular no IBM Cloud Kubernetes Service. Certifique-se de aplicar as correções de segurança no tempo para proteger seu cluster de ataques maliciosos. Para obter mais informações sobre o que está incluído em um patch de segurança, consulte o Kubernetes informações sobre a versão.