Segurança para o Red Hat OpenShift on IBM Cloud

É possível usar recursos de segurança integrada no Red Hat® OpenShift® on IBM Cloud® 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.

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 de nuvem e executar softwares mal-intencionados.
Dados comprometidos ou perdidos
Armazenamento incorreto de dados confidenciais e falta de criptografia.
Insiders 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 o cluster contra essas ameaças de segurança, os recursos de segurança e as atualizações mais recentes do Red Hat OpenShift on IBM Cloud, do Red Hat OpenShift e do Kubernetes devem ser aplicados a todos os componentes do cluster.

Esses componentes incluem:

Servidor de API do Red Hat OpenShift e etcd

O servidor de API e o armazenamento de dados etcd do Red Hat OpenShift são os componentes mais sensíveis que são executados em seu mestre do Red Hat OpenShift. 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.

Red Hat OpenShift fornece controles de segurança e limita 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 modifica as solicitações antes de serem processadas pelo servidor de API do Red Hat OpenShift. Muitos recursos do site Kubernetes requerem controladores de admissão para funcionar adequadamente.

O que o Red Hat OpenShift on IBM Cloud faz para proteger meu servidor de API e o armazenamento de dados do 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 os estágios de segurança quando você acessa o servidor de API.
Estágios de segurança ao acessar o servidor de API

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

Mestre totalmente gerenciado e dedicado do Red Hat OpenShift

Cada cluster no Red Hat OpenShift on IBM Cloud é controlado por um mestre do Red Hat OpenShift dedicado que é gerenciado pela IBM em uma conta da IBM Cloud de propriedade da IBM. O mestre do Red Hat OpenShift é 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 no etcd são armazenados no disco local do mestre do Red Hat OpenShift e são submetidos a backup para o IBM Cloud Object Storage. Os dados são criptografados durante o trânsito para o IBM Cloud Object Storage e em repouso. Escolha ativar a criptografia para seus dados etcd no disco local do Red Hat OpenShift mestre, ativando a criptografia do IBM Key Protect do 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.
  • openshift-api: serve como o principal ponto de entrada para todas as solicitações de gerenciamento de cluster do nó do trabalhador para o mestre do Red Hat OpenShift. 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.
  • openshift-controller: busca pods recém-criados e decide onde implementá-los com base na capacidade, necessidades de desempenho, restrições de política, especificações de antiafinidade e 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. O controlador também observa o estado de recursos de cluster, como conjuntos de réplicas. Quando o estado de um recurso for alterado, por exemplo, se um pod em um conjunto de réplicas ficar inativo, o gerenciador do controlador iniciará as ações de correção para atingir o estado necessário.
  • cloud-controller-manager: o gerenciador do controlador de nuvem gerencia componentes específicos do provedor em nuvem IBM Cloud como o balanceador de carga.
  • Konnectivity: componente específico do Red Hat OpenShift on IBM Cloud para fornecer conectividade de rede segura para todas as comunicações entre os nós mestre e de trabalho do Red Hat OpenShift. O servidor Konnectivity trabalha com o agente Konnectivity para conectar com segurança o mestre ao nó de trabalho. Esta conexão suporta solicitações apiserver proxy para os pods e serviços, bem como solicitações oc 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 Red Hat OpenShift, incluindo todos os componentes do mestre, cálculo, rede e recursos de armazenamento são continuamente monitorados pelos Engenheiros de confiabilidade de site da IBM (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 Red Hat OpenShift on IBM Cloud.

Referência principal do CIS Kubernetes

Para configurar Red Hat OpenShift on IBM Cloud, os engenheiros da IBM seguem práticas relevantes de cibersegurança da referência principal do Kubernetes publicada pelo Center of Internet Security (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 Red Hat OpenShift on IBM Cloud, deve-se autenticar com o serviço usando suas credenciais. Ao ser autenticado, o Red Hat OpenShift on IBM Cloud gera certificados TLS que criptografam a comunicação para e do servidor de API e armazenamento de dados etcd do Red Hat OpenShift para assegurar uma comunicação segura de ponta a ponta entre os nós do trabalhador e o mestre do Red Hat OpenShift. Esses certificados nunca são compartilhados entre clusters ou entre os componentes do mestre do Red Hat OpenShift.

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 proteger essa comunicação, o Red Hat OpenShift on IBM Cloud configura automaticamente uma conexão Konnectivity entre o Red Hat OpenShift master e o nó de trabalho quando o cluster é criado.

Controle de acesso de baixa granularidade

Como o administrador da conta, é possível conceder acesso a outros usuários para Red Hat OpenShift on IBM Cloud usando o IBM Cloud Identity and Access Management (IAM). O IBM Cloud IAM fornece autenticação segura com a plataforma IBM Cloud, Red Hat OpenShift on IBM Cloud, 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 Red Hat OpenShift on IBM Cloud. As funções de acesso à plataforma também atribuem aos usuários as funções RBAC basic-users e self-provisioners. Com essas funções RBAC, é possível criar um projeto Red Hat OpenShift no cluster, no qual você pode implementar aplicativos e outros recursos Kubernetes. Como criador do projeto, você é designado automaticamente à função RBAC admin do projeto para que seja possível controlar totalmente o que você deseja implementar e executar em seu projeto. No entanto, essas funções da RBAC não concedem acesso a outros projetos Red Hat OpenShift. Para visualizar e acessar outros projetos do Red Hat OpenShift, deve-se ter a função de acesso de serviço apropriada designada no IAM.
  • Funções de acesso ao serviço: Determine a função Kubernetes RBAC atribuída ao usuário e as ações que um usuário pode executar no servidor de API Red Hat OpenShift. Enquanto a função basic-users e self-provisioners RBAC que é designada com uma função de acesso à plataforma permite criar e gerenciar seus próprios projetos Red Hat OpenShift, não é possível visualizar, acessar ou trabalhar com outros projetos Red Hat OpenShift até que seja designado uma função de acesso ao serviço. Para obter mais informações sobre as funções RBAC correspondentes que são 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 de 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.

Controladores de admissão

Os controladores de admissões são implementados para recursos específicos no Kubernetes e Red Hat OpenShift on IBM Cloud. 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 o seu cluster antes que uma solicitação de API seja processada pelo servidor de API Red Hat OpenShift.

Quando você cria um cluster, o Red Hat OpenShift on IBM Cloud instala automaticamente o Kubernetes controladores de admissão padrão em uma ordem específica no Red Hat OpenShift master, que não pode ser alterada pelo usuário. Revise a ordem dos controladores de admissão padrão por versão do cluster nas informações de referência do componente.

É 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 de 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ços 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 sou responsável por protegê-lo?

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 em sua conta 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 de VPC: Os nós de trabalho são provisionados em uma conta IBM Cloud de propriedade da IBM para permitir o monitoramento de atividades mal-intencionadas e aplicar 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 Red Hat OpenShift on IBM Cloud.

Use o comando ibmcloud oc worker update regularmente (por exemplo, mensalmente) para implantar atualizações e patches de segurança no sistema operacional e para atualizar a versão do Red Hat OpenShift que os nós de trabalho executam. 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 oc clusters ls ou ibmcloud oc 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 Red Hat OpenShift on IBM Cloud, excluindo a segurança da rede.
Configuração do nó de trabalho em Red Hat OpenShift on IBM Cloud excluindo a segurança da rede

CIS-imagem compatível
Cada nó de trabalho é configurado com um sistema operacional que implementa os benchmarks 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 oc 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 Red Hat OpenShift on IBM Cloud e devem ser instaladas pelo usuário para manter o nó do trabalhador seguro.

Red Hat OpenShift on IBM Cloud usa um Linux kernel para nós de trabalho. É possível executar contêineres com base em qualquer distribuição do Linux no Red Hat OpenShift on IBM Cloud. Consulte o fornecedor da imagem do contêiner para verificar se as imagens do contêiner podem ser executadas no 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 esses patches quando estiverem disponíveis para garantir um ambiente seguro para seus nós de trabalho e os aplicativos que você executa neles.
Referência de nó do trabalhador do CIS Kubernetes
Para configurar o Red Hat OpenShift on IBM Cloud, os engenheiros do IBM seguem as práticas de segurança cibernética relevantes do benchmark do nó de trabalho Kubernetes publicado pelo Center of Internet Security(CIS ). Revise a conformidade dos nós do trabalhador em relação aos padrões de referência e padrões do benchmark do Kubernetes do CIS e do benchmark do Red Hat OpenShift.
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, você pode optar por provisionar os nós de trabalho como máquinas físicas (bare metal) ou como máquinas virtuais executadas em hardware físico compartilhado ou dedicado. Os nós de trabalho em um cluster de VPC podem ser provisionados como máquinas virtuais somente na 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 Red Hat OpenShift on IBM Cloud. 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.
SELinux
Cada nó de trabalho é configurado com políticas de segurança e acesso que são aplicadas pelos perfis do Security-Enhanced Linux(SELinux) que são carregados no nó de trabalho durante a inicialização. Os perfis SELinux não podem ser mudados 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 é desativado, o acesso ao cluster é forçado por meio do servidor de API do Red Hat OpenShift. O servidor de API do Red Hat OpenShift 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ê tiver um cluster padrão e quiser instalar mais recursos no nó de trabalho, poderá escolher entre os complementos fornecidos por Red Hat OpenShift on IBM Cloud ou usar os conjuntos de daemon Kubernetes para tudo o que deseja executar em cada nó de trabalho. 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.

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

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 Red Hat OpenShift master ao kubelet do nó de trabalho é protegido por um túnel Konnectivity. Para obter mais informações, consulte a Arquitetura do Red Hat OpenShift on IBM Cloud.

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 Red Hat OpenShift on IBM Cloud 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 executar essa ação, você precisa da permissão de infraestrutura Rede > Gerenciar spanning de VLAN de rede ou pode solicitar ao proprietário da conta que a habilite. Para verificar se o spanning de VLAN já está ativado, use o comando ibmcloud oc vlan spanning get --region <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 Red Hat OpenShift on IBM Cloud é compatível com todos IBM Cloud ofertas de firewall. 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 ataques externos para 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 para a Internet pública, é possível usar rotas do Red Hat OpenShift ou o suporte ao NLB e ao ALB do Ingress para disponibilizar de forma segura seus serviços publicamente. 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 a conectividade de Internet pública com nós de borda Cada nó do trabalhador é configurado para aceitar pods do app e pods do balanceador de carga associado ou do Ingress. É possível rotular nós do trabalhador como nós de borda para forçar os pods do balanceador de carga a serem implementados somente para esses 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 no 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 para meu cluster de VPC por padrão?

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.

Para acessar os componentes padrão do Red Hat OpenShift, como o console da web ou o OperatorHub sem estar conectado à rede privada do seu VPC, deve-se anexar um gateway público às sub-redes de VPC às quais os nós do trabalhador são implementados. 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.

Por padrão, os grupos de segurança são aplicados à instância da VPC e aos ALBs e NLBs da 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.

O que é segmentação de rede e como posso configurá-la para um cluster de 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 Red Hat OpenShift on IBM Cloud 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 ataques externos para 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.

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

Exponha os apps com rotas de forma segura

Se quiser permitir o tráfego de rede de entrada da Internet, você poderá expor seus aplicativos usando rotas.

Cada cluster Red Hat OpenShift é configurado automaticamente com um roteador Red Hat OpenShift que recebe um nome de domínio exclusivo e é protegido por um certificado TLS. Ao expor seu app usando uma rota, uma URL é designada ao seu app por meio do roteador do Red Hat OpenShift.

Ao criar uma rota para seu app, é possível decidir criar uma rota segura (HTTPS) ou não segura (HTTP). Para rotas asseguradas, é possível decidir onde você deseja implementar a rescisão de TLS, como no roteador ou no pod. Para obter mais informações, consulte Expondo apps com rotas.

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 Red Hat OpenShift on IBM Cloud usa para gerenciar endereços IP do NLB. Para gerenciar uniformemente o tráfego do seu cluster em todos os nós de trabalho, use 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 fazer a terminação TLS 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 ALB Ingress equilibra a carga do tráfego de rede 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.

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 site IBM monitora meu cluster?
Cada mestre de cluster é monitorado continuamente pelo site IBM para controlar e corrigir ataques de negação de serviço (DOS) no nível do processo. O site Red Hat OpenShift on IBM Cloud verifica automaticamente cada nó em que o mestre está implantado em busca de vulnerabilidades encontradas em Kubernetes, Red Hat OpenShift e correções de segurança específicas do sistema operacional. Se vulnerabilidades forem localizadas, o Red Hat OpenShift on IBM Cloud 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 Red Hat OpenShift on IBM Cloud 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 por meio do sistema operacional Red Hat Enterprise Linux que são enviados para /var/log/syslog e /var/log/auth.log.
  • Servidor de API do Red Hat OpenShift: toda ação relacionada ao cluster que é enviada para o servidor de API do Red Hat OpenShift é registrada por motivos 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.
  • Roteadores: registre o tráfego de rede de entrada em rotas.
  • 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 registros dos componentes do cluster, configure o site IBM Cloud Logs. IBM Cloud Logs fornece acesso a todos os seus logs e você pode agregar logs e criar suas próprias exibições personalizadas em vários clusters.

Como posso monitorar a integridade 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 Red Hat OpenShift on IBM Cloud, como o uso de CPU e memória. Para visualizar métricas mais detalhadas do seu cluster, você pode usar os recursos de monitoramento integrados que são baseados em tecnologias de código aberto, como o Prometheus. O Prometheus é instalado automaticamente quando você cria o cluster e é possível usar a ferramenta para acessar o cluster em tempo real e as métricas do app. As métricas Prometheus não são armazenadas de forma persistente. Para acessar métricas históricas e comparar métricas entre de vários clusters, use IBM Cloud Monitoring em vez disso.

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

Como posso auditar os eventos que ocorrem em meu cluster?
É possível configurar o IBM Cloud Logs no cluster do Red Hat OpenShift on IBM Cloud. Para obter mais informações, consulte a documentação Saiba mais sobre IBM Cloud Logs.
Quais são minhas opções para habilitar a confiança em meu cluster?
Por padrão, o Red Hat OpenShift on IBM Cloud 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.

Implementando 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.

Tempo de execução do contêiner

Seus nós de trabalho são instalados com CRI-O como a interface de tempo de execução do contêiner, que é protegida pelo sistema de rotulagem Security-Enhanced Linux(SELinux).

Ao usar o Kubernetes para interagir com uma imagem de contêiner, como criar um pod, o kubelet se comunica com o CRI-O por meio de um soquete UNIX, crio.sock. O soquete UNIX usa os rótulos SELinux na tabela a seguir para cumprir as políticas de acesso de sistema apropriadas. Esses rótulos impedem os contêineres do usuário de poderem acessar o soquete de tempo de execução do contêiner.

Rótulos do SELinux que são usados para proteger processos de tempo de execução do contêiner.
Processo Rótulo do SELinux
CRI-O system_u:system_r:container_runtime_t:s0
kubelet system_u:system_r:unconfined_service_t:s0
crio.sock system_u:object_r:container_var_run_t:s0
Um processo de contêiner, como c14 system_u:system_r:container_t:s0:c14

Exemplo de fluxo de solicitação

O diagrama a seguir apresenta um fluxo de solicitação de exemplo entre o kubelet e o CRI-O.

Exemplo de fluxo de solicitação entre o kubelet e CRI-O.
Exemplo de fluxo de solicitação entre o kubelet e o CRI-O

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 o fornecido em IBM Cloud Container Registry ou o registro interno que é configurado automaticamente no cluster Red Hat OpenShift, e certifique-se de controlar o acesso ao registro e ao conteúdo da imagem que pode ser enviado.
Por que é importante verificar as imagens em relação às 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 adicionar segurança extra, você pode estabelecer um trabalho que remova os contêineres vulneráveis depois que eles forem detectados.

É possível usar o registro de contêiner integrado para automatizar o processo de construção de imagem de contêiner por meio de seu código-fonte em um repositório de origem externa para seu registro interno. No entanto, as imagens não são varridas automaticamente em busca de vulnerabilidades quando elas são enviadas por push para o registro interno. Para configurar a varredura de imagem, configure um namespace de registro e envie por push suas imagens para o IBM Cloud Container Registry gerenciado em vez disso.

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.
Que opções tenho para verificar se há vulnerabilidades nos 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 projeto Red Hat OpenShift e por que devo usá-lo?
Projetos do Red Hat OpenShift são uma maneira de virtualmente particionar 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 projetos, é possível organizar recursos entre os nós do trabalhador e também entre as zonas em clusters multizona.
Cada cluster é configurado com um conjunto de projetos padrão do Red Hat OpenShift que incluem as implementações e serviços que são necessários para que o Red Hat OpenShift on IBM Cloud seja executado adequadamente e gerencie o cluster. Para obter mais informações, consulte a arquitetura de serviço.
Os administradores de cluster têm acesso automaticamente a esses projetos e podem configurar projetos adicionais no cluster. Além disso, os usuários do cluster que possuem acesso concedido ao cluster podem criar seu próprio projeto e, como os criadores do projeto, podem gerenciar o projeto com permissões de administrador. No entanto, os usuários de cluster não têm acesso a outros projetos por padrão, a menos que recebam acesso de um administrador de cluster.

Para cada projeto que você tem no cluster, certifique-se de configurar políticas RBAC adequadas para limitar o acesso a esse projeto, controlar o que é implantado e definir cotas de recursos e intervalos de limites adequados.

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

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 diversos projetos para isolar locatários e suas cargas de trabalho.

Decidindo entre um único locatário ou um cluster de diversos locatários.
Cluster de um único locatário versus cluster de vários locatários

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 gerenciar um cluster requer conhecimento detalhado de Kubernetes, de Red Hat OpenShift e de infraestrutura para garantir capacidade de cluster e segurança para suas implementações.

Os clusters com diversos locatários usam os projetos do Red Hat OpenShift para isolar locatários e geralmente são 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: quando você configura diversos projetos, deve-se configurar políticas RBAC adequadas para cada projeto a fim de 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 diversos locatários requerer a execução de pods privilegiados, esse pod poderá acessar outros projetos 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 restrições de contexto de segurança (SCCs) para controlar quais recursos seus locatários podem implementar 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 implementação, como o número de recursos Kubernetes que você pode implementar e a quantidade de CPU e memória que pode ser consumida por esses recursos. Depois de configurar uma cota, os usuários devem incluir solicitações de recurso e limites em suas implementações.
  • Recursos de cluster compartilhados: ao executar diversos locatários em um cluster, alguns recursos do cluster, como o roteador do Red Hat OpenShift, o balanceador de carga do aplicativo (ALB) do Ingress ou os endereços IP móveis disponíveis, serão compartilhados entre eles. Os serviços menores podem ter dificuldade ao usar recursos compartilhados se eles devem competir com os serviços grandes no cluster.
  • Atualizações: somente é possível executar uma versão da API do Red Hat OpenShift por vez. Todos os apps que são executados em um cluster devem estar em conformidade com a versão atual da API do Red Hat OpenShift independentemente da equipe que possui o app. Para atualizar um cluster, deve-se assegurar que todas as equipes estejam prontas para alternar para uma nova versão da API do Red Hat OpenShift e que os apps sejam atualizados adequadamente. Isso também significa que as equipes individuais têm menos controle sobre a versão da API do Red Hat OpenShift que eles querem 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 diversos 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 projetos em um cluster de diversos 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 do pod?
Para controlar as permissões de pod dentro ou entre os projetos, o Red Hat OpenShift on IBM Cloud usa restrições de contexto de segurança (SCCs). Por padrão, cada cluster é configurado com Red Hat OpenShift SCCs e um conjunto de SCCs fornecidos pela IBM que é possível designar para contas de serviço, pods, implementações ou projetos para limitar as permissões dentro do cluster. Se você não atribuir explicitamente um SCC, seus pods usarão o restricted SCC. Os Red Hat OpenShift SCCs são mais rígidos do que as políticas de segurança de pod padrão em clusters Kubernetes da comunidade. Pode ser necessário modificar um app executado em um cluster Kubernetes da comunidade para que ele possa ser executado no Red Hat OpenShift. Para obter mais informações, consulte Configurando restrições de contexto de segurança.
O que mais posso fazer para proteger meu contêiner?
Limite o número de contêineres privilegiados. 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ê desejar bloquear contêineres privilegiados de executarem em seu cluster, considere configurar as restrições de contexto de segurança customizadas.

Aplicar configurações de segurança do S.O. aos pods
É possível personalizar as restrições de contexto de segurança padrão para controlar o ID do usuário e o ID do grupo que podem ser executados dentro do contêiner ou o ID do usuário e o ID do grupo que possuem o caminho de montagem do 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. Para obter mais informações, consulte Configurando restrições de contexto de segurança.
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. Você pode definir intervalos de limite para seus 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.

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 projeto, implantação, serviço ou mapa de configuração do Red Hat OpenShift. 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.

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. Os boletins de segurança do Kubernetes que afetam os usuários do Red Hat OpenShift on IBM Cloud ou a plataforma da IBM Cloud são publicados no boletim de segurança da IBM Cloud.

Alguns CVEs requerem a atualização de correção mais recente para uma versão do Red Hat OpenShift que pode ser instalada como parte do processo de atualização de cluster regular no Red Hat OpenShift on IBM Cloud. 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 as informações da versão Red Hat OpenShift on IBM Cloud.