Entendendo a rede VPC de cluster segura por padrão

Nuvem privada virtual 4.15 e posteriormente

A partir dos novos clusters de VPC criados na versão 4.15, o site Red Hat OpenShift on IBM Cloud introduziu um novo recurso de segurança chamado Secure by Default Cluster VPC Networking. Com o Secure by Default, há novas configurações de VPC, como grupos de segurança gerenciados, regras de grupo de segurança e gateways de terminal privado virtual (VPEs) que são criados automaticamente quando você cria um cluster de VPC. Analise os detalhes a seguir sobre os componentes da VPC que são criados e gerenciados para você ao criar um cluster da versão 4.15 e posterior.

Visão geral

Com o Secure by Default Networking, ao provisionar um novo cluster VPC Red Hat OpenShift on IBM Cloud na versão 4.15 ou mais recente, somente o tráfego necessário para o cluster funcionar é permitido e todos os outros acessos são bloqueados. Para implementar o Secure by Default Networking, o Red Hat OpenShift on IBM Cloud usa vários grupos de segurança e regras do grupo de segurança para proteger componentes de cluster. Esses grupos e regras de segurança são criados automaticamente e anexados aos seus nós de trabalho, balanceadores de carga e gateways VPE relacionados ao cluster.

Grupos de segurança de — imagem mostra os grupos de segurança de VPC aplicados à sua VPC e aos clusters

Os grupos de segurança do Virtual Private Cloud filtram o tráfego no nível do hypervisor. As regras de grupo de segurança não são aplicadas em uma ordem específica. No entanto, as solicitações para os nós do trabalhador serão permitidas somente se a solicitação corresponder a uma das regras especificadas. Ao permitir o tráfego em uma direção criando uma regra de entrada ou de saída, as respostas também são permitidas na direção oposta. Os grupos de segurança são aditivos, o que significa que se seus nós do trabalhador estiverem conectados a mais de um grupo de segurança, todas as regras incluídas nos grupos de segurança serão aplicadas aos nós do trabalhador. Versões de cluster mais recentes podem ter mais regras no grupo de segurança do kube-<clusterID> do que versões de cluster mais antigas. As regras do grupo de segurança são incluídas para melhorar a segurança do serviço e não quebram a funcionalidade

Gateways de ponto de extremidade privado virtual (VPE)

Quando o primeiro cluster VPC no Red Hat OpenShift on IBM Cloud 4.14+ é criado em um determinado VPC ou um cluster nesse VPC tem seu principal atualizado para 4.14+, vários Gateways VPE compartilhados são criados para vários serviços do IBM Cloud. Apenas um desses tipos de Gateways VPE compartilhados é criado por VPC. Todos os clusters no VPC compartilham o mesmo VPE Gateway para esses serviços.. Esses Gateways VPE compartilhados são designados a um único IP reservado de cada zona na qual os trabalhadores do cluster estão.

Gateways de VPE compartilhados

Os gateways VPE a seguir são criados automaticamente quando você cria um cluster VPC.

Gateways de VPE compartilhados
A tabela mostra os gateways VPE criados para clusters VPC. A primeira coluna inclui o nome do gateway A segunda coluna inclui uma breve descrição. A terceira coluna inclui os nomes DNS.
Gateway VPE	Descrição	nomes do DNS
IBM Cloud Container Registry	Extraia imagens de contêineres de IBM Cloud Container Registry para aplicativos em execução no seu cluster.	`icr.io`, `*.icr.io`
Gateway do IBM Cloud Object Storage s3	Acesse as APIs do site IBM Cloud Object Storage.	`s3.direct.<region>.cloud-object-storage.appdomain.cloud`, `*.s3.direct.<region>.cloud-object-storage.appdomain.cloud`
Gateway de configuração do IBM Cloud Object Storage	Faça backup das imagens do contêiner para IBM Cloud Object Storage	`config.direct.cloud-object-storage.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (ca-mon, in-che, in-mum)	Acesse as APIs Red Hat OpenShift on IBM Cloud para criar clusters, adicionar pools de trabalho e muito mais.	`private.<region>.containers.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (outras regiões)	Acesse as APIs Red Hat OpenShift on IBM Cloud para criar clusters, adicionar pools de trabalho e muito mais.	`api.<region>.containers.cloud.ibm.com`
IBM Cloud VPC	Acesse as APIs da VPC para provisionar e gerenciar recursos que fazem parte da infraestrutura como serviço da VPC ( IaaS ).	`<region>.private.iaas.cloud.ibm.com`

Gateways VPE não compartilhados

Todos os clusters de VPC compatíveis têm um Gateway VPE para o mestre do cluster que é criado em sua conta quando o cluster é criado.

Gateways VPE não compartilhados
A tabela mostra os gateways VPE criados para clusters VPC. A primeira coluna inclui o nome do gateway A segunda coluna inclui uma breve descrição.
Gateway VPE	Descrição
Red Hat OpenShift on IBM Cloud mestre do cluster	Esse VPE Gateway é usado pelos trabalhadores do cluster e pode ser usado por outras coisas no VPC para se conectar ao servidor de API principal do cluster Esse gateway VPE recebe um único IP reservado de cada zona em que estão os trabalhadores do cluster, e esse IP é criado em uma das sub-redes VPC da zona que tem trabalhadores do cluster. †

por exemplo, se o cluster tiver trabalhadores em apenas uma região de zona única (us-east-1) e uma única sub-rede VPC, um único IP será criado nessa sub-rede e atribuído ao gateway VPE. Se um cluster tiver trabalhadores em todas as três zonas, como us-east-1, us-east-2 e us-east-3 e esses trabalhadores forem distribuídos entre 4 sub-redes de VPC em cada zona, então 12 sub-redes de VPC juntas, três IPs serão criados, um em cada zona, em uma das quatro sub-redes de VPC nessa zona. Observe que a sub-rede é escolhida aleatoriamente..

Grupos de segurança gerenciados

O Red Hat OpenShift on IBM Cloud cria e atualiza automaticamente os grupos de segurança e as regras a seguir para clusters VPC.

Grupos de segurança gerenciados
A tabela mostra os grupos de segurança gerenciados criados para clusters de VPC. A primeira coluna inclui o nome do grupo de segurança. A segunda coluna inclui a convenção de nomenclatura.
Grupo de segurança	Convenção de nomenclatura
Grupo de segurança do trabalhador	`kube-<clusterID>`
Grupo de segurança de gateway VPE mestre	`kube-vpegw-<clusterID>`
Grupo de segurança de gateway VPE compartilhado	`kube-vpegw-<vpcID>`
Grupo de segurança de serviços de balanceamento de carga	`kube-lbaas-<clusterID>`

Grupo de segurança do trabalhador

Quando você cria um cluster VPC Red Hat OpenShift on IBM Cloud, um grupo de segurança é criado para todos os trabalhadores, ou nós, do cluster em questão.

O nome do grupo de segurança é kube-<clusterID> em que <clusterID> é o ID do cluster.
Se novos nós forem incluídos no cluster posteriormente, esses nós serão incluídos no grupo de segurança do cluster automaticamente..
As regras são adicionadas ou removidas dinamicamente conforme a necessidade dos balanceadores de carga.
As regras adicionadas no intervalo de portas do nó são removidas automaticamente se não forem necessárias. Se os clientes quiserem permitir o tráfego de entrada em um serviço de porta de nó, você deverá adicionar a regra para permitir o tráfego depois de criar o serviço de porta de nó.
Não modifique as regras no grupo de segurança kube-<clusterID> porque isso pode causar interrupções na conectividade de rede entre os trabalhadores do cluster e o cluster de controle.

Regras no grupo de segurança kube-clusterID
A tabela mostra as regras aplicadas ao grupo de segurança do trabalhador do cluster. A primeira coluna inclui o protocolo da regra A segunda coluna inclui portas e tipos. A terceira coluna inclui o destino remoto da regra A quarta coluna inclui uma breve descrição da regra.
Descrição	Direção	Protocolo	Portas ou valores	Origem ou destino
Permite o tráfego de entrada para a sub-rede do pod	Entrada	ICMP/ TCP / UDP	Todos	172.17.0.0/18 (o intervalo de sub-rede padrão) ou um intervalo de sub-rede customizado que você especifica ao criar seu cluster.
Permite o acesso de entrada a si mesmo, o que permite a comunicação entre trabalhadores.	Entrada	ICMP/ TCP / UDP	Todos	`kube-<clusterID>`
Permite o acesso ICMP (ping) de entrada	Entrada	ICMP	type=8	0.0.0.0/0
Permite o tráfego de entrada de nodeports abertos por seus balanceadores de carga (ALBs/NLBs). Conforme os balanceadores de carga são incluídos ou as regras removidas são incluídas ou removidas dinamicamente.	Entrada	TCP	Portas do nó do balanceador de carga	`kube-lbaas-<clusterID>`
Permite o tráfego de saída para a sub-rede do pod	Saída	ICMP/ TCP / UDP	Todos	172.17.0.0/18 (o intervalo de sub-rede padrão) ou um intervalo de sub-rede customizado que você especifica ao criar seu cluster.
Permite o tráfego de saída para o plano de controle principal que permite que trabalhadores sejam provisionados.	Saída	ICMP/ TCP / UDP	Todos	161.26.0.0/16
Permite o acesso de saída para si mesmo, o que permite a comunicação entre trabalhadores.	Saída	ICMP/ TCP / UDP	Todos	`kube-<clusterID>`
Permite tráfego de saída para o grupo de segurança do gateway VPE principal.	Saída	ICMP/ TCP / UDP	Todos	`kube-vpegw-<clusterID>`
Permite tráfego de saída para o grupo de segurança do gateway VPE compartilhado.	Saída	ICMP/ TCP / UDP	Todos	`kube-vpegw-<vpcID>`
Permite o tráfego para o terminal público por meio da porta oauth para todas as zonas do MZR no qual o cluster está localizado.`*`	Saída	TCP	Porta Oauth	Os IPs do terminal público para todas as zonas do MZR
Permite que o tráfego TCP passe pelo ALB de entrada	Saída	TCP	Ports:Min=443,Max=443	Endereço IP público do ALB `n`.
Permite o tráfego TCP e UDP por meio do resolvedor de DNS personalizado para a zona `n`.`**`	Saída	TCP/UDP	Min=53,Max=53	endereço IP do resolvedor DNS na zona `n`.
Permite o tráfego para todo o intervalo de serviço do CSE	Saída	ICMP/ TCP / UDP	Todos	166.8.0.0/14
Permite tráfego para o terminal privado do IAM para todas as zonas. Os IPs podem variar por região. Uma regra é incluída por zona na qual o cluster está..	Saída	ICMP/ TCP / UDP	Todos	endereço IP do terminal privado do IAM para todas as zonas.
Permite o tráfego de saída para a API de metadados da instância.	Saída	ICMP/ TCP / UDP	Todos	169.254.169.254
4.18 e posteriores Permite o tráfego de saída para a API de metadados da instância.	Saída	ICMP/ TCP / UDP	Todos	169.254.169.254

* Essas regras são adicionadas somente a clusters com pontos de extremidade de serviço público ativados para permitir o acesso ao console da Web OpenShift e ao ponto de extremidade público por meio da porta OAuth. Uma regra é incluída para cada zona da região multizona (MZR) na qual o cluster está localizado.. Se seu cluster estiver em uma MZR com 3 zonas, então 3 regras serão criadas.

** As VPCs do hub e do Spoke usam resolvedores DNS customizados na VPC. O tráfego deve fluir através dos endereços IP de cada resolvedor DNS. Há duas regras por zona ( TCP e UDP ) por meio da porta 53.

Grupo de segurança do gateway VPE principal

Ao criar um cluster VPC, um gateway Virtual Private Endpoint (VPE) é criado no mesmo VPC que o cluster. O nome da segurança é kube-vpegw-<clusterID>, em que <clusterID> é a ID do cluster. A finalidade desse gateway VPE é servir como um gateway para o mestre do cluster, que é gerenciado pelo IBM Cloud. O gateway VPE é designado a um único endereço IP em cada zona no VPC no qual o cluster tem trabalhadores

Para permitir o acesso ao principal de um cluster somente por meio de seus nós do trabalhador, um grupo de segurança é criado para cada gateway do VPE principal do cluster Em seguida, é criada uma regra remota que permite a conectividade do Ingress do grupo de segurança do trabalhador do cluster para as portas necessárias no gateway do VPE do cluster principal. Para que as conexões privadas, inclusive as conexões provenientes de uma VPN VPC, se conectem ao gateway VPE de endpoint de serviço privado do cluster, o tráfego TCP é permitido a partir dos CIDRs de sub-rede para cada pool de trabalho ativo do cluster.

Regras de entrada no grupo de segurança do gateway do VPE mestre
A tabela mostra as regras de entrada aplicadas ao grupo de segurança do trabalhador do cluster. A primeira coluna inclui o propósito da regra A segunda coluna inclui a direção da regra.. A terceira coluna inclui o protocolo. A quarta coluna inclui as portas ou os valores. A quinta coluna inclui o destino remoto da regra.
Descrição	Direção	Protocolo	Portas ou valores	Origem ou Destino
Permite o tráfego de entrada do grupo de segurança do trabalhador do cluster para a porta do nó do servidor	Entrada	TCP	Servidor URL porta do nó	`kube-<clusterID>`
Permite tráfego de entrada do grupo de segurança do trabalhador do cluster para a porta openVPN ou Konnectivity.	Entrada	TCP	Porto de Konnectivity	`kube-<clusterID>`
Permite o tráfego de entrada do grupo de segurança do trabalhador do cluster para a porta do Oauth	Entrada	TCP	Porta Oauth	`kube-<clusterID>`
CoreOS-enabled. Permite tráfego de entrada do grupo de segurança do trabalhador do cluster para a porta do servidor de ignição	Entrada	TCP	Porta do servidor do Ignition	`kube-<clusterID>`
Permite o tráfego de entrada da sub-rede de cada pool de trabalho ativo em seu cluster.`*`	Entrada	TCP	Servidor URL porta do nó	CIDR da sub-rede
Permite o tráfego de entrada da sub-rede de cada pool de trabalho ativo em seu cluster.`*`	Entrada	TCP	OAuth porto	CIDR da sub-rede

* Uma regra é adicionada para a sub-rede de cada pool de trabalho ativo. Se você tiver trabalhadores em três zonas, serão adicionadas três regras (uma para cada sub-rede nessa zona).

Grupo de segurança do gateway VPE compartilhado

Os gateways VPE compartilhados são criados quando o primeiro cluster em uma VPC é provisioned.The grupo de segurança de gateway VPE compartilhado é criado quando você cria um cluster (se ainda não existir em clusters anteriores). O nome do grupo de segurança é kube-vpegw-<vpcID>, em que <vpcID> é o ID de sua VPC. Em seguida, é criada uma regra remota que permite a conectividade do Ingress do grupo de segurança do trabalhador do cluster para o cluster especificado. O grupo de segurança do gateway VPE compartilhado contém os gateways VPE que são compartilhados por todos os clusters nesse VPC. Gateways VPE compartilhados podem ser adicionados em versões posteriores para permitir conexões com outros IBM Cloud Services.

Se esse grupo de segurança do gateway VPE compartilhado já existir quando um cluster for fornecido, ele será reconhecido pelo processo de fornecimento e não será recriado. No entanto, uma regra remota ainda é incluída entre o grupo de segurança do gateway do VPE compartilhado existente e o novo grupo de segurança do trabalhador Isso é feito para que a conectividade seja permitida de todos os clusters no VPC especificado. Uma regra é criada para cada cluster no VPCs

Há um máximo de 15 regras que podem atingir outros grupos de segurança como sua origem ou destino. Por padrão, o site Red Hat OpenShift on IBM Cloud aplica uma regra que tem como alvo o grupo de segurança kube-<clusterID> para cada cluster na VPC. Devido a essa cota, apenas 15 clusters podem ser criados em uma determinada VPC, Para obter mais informações, consulte Cotas de VPC

Regras de entrada no grupo de segurança do gateway VPE compartilhado
A tabela mostra as regras de entrada aplicadas ao grupo de segurança do gateway VPE compartilhado. A primeira coluna inclui o objetivo da regra. A segunda coluna inclui a direção da regra.. A terceira coluna inclui o protocolo. A quarta coluna inclui o destino remoto da regra.
Descrição	Direção	Protocolo	Origem ou destino
Permite o tráfego de entrada do cluster especificado.	Entrada	TCP	`kube-<clusterID>`

Grupo de segurança de serviços do balanceador de carga

O grupo de segurança padrão que está conectado a todos os balanceadores de carga (ALBs e NLBs).

Cada cluster obtém seu próprio grupo de segurança exclusivo que é compartilhado por todos os balanceadores de carga no cluster..
O nome do grupo de segurança é kube-lbaas-<clusterID>, em que <clusterID> é o ID do seu cluster.
As regras nesse grupo de segurança são incluídas ou excluídas dinamicamente conforme os balanceadores de carga são incluídos, removidos ou atualizados. Observe que SDNLBs não suportam a conexão de grupos de segurança.
Você pode adicionar regras a esse grupo de segurança. No entanto, algumas regras podem ser removidas se forem incompatíveis com as outras regras ou se quebrarem a funcionalidade.

Regras de grupo de segurança do balanceador de carga
A tabela mostra as regras aplicadas ao grupo de segurança do balanceador de carga. A primeira coluna inclui o propósito da regra A segunda coluna inclui a direção da regra.. A terceira coluna inclui o protocolo. A quarta coluna inclui as portas ou os valores. A quinta coluna inclui o destino remoto da regra.
Descrição	Direção	Protocolo	Porta ou valor	Origem ou destino
Permite o acesso de saída para a porta de nó aberta pelo balanceador de carga Dependendo do balanceador de carga, você pode ter várias regras.	Saída	TCP	Node porta (s) aberta (s) pelo balanceador de carga.	`kube-<clusterID>`
O balanceador de carga atende na porta 80 permitindo acesso de entrada a partir dessa porta.	Entrada	TCP	Porta pública do LB Exemplo `80`	0.0.0.0/0
O balanceador de carga atende na porta 443 permitindo acesso de entrada a partir dessa porta.	Entrada	TCP	Porta pública do LB Exemplo `443`	0.0.0.0/0

Fornecido pelo usuário Security Groups

Ao criar um cluster de VPC, você pode fornecer até quatro grupos de segurança adicionais de sua propriedade.

Para obter mais informações, consulte Criação e gerenciamento de grupos de segurança VPC.

Limitações

Grupos de segurança do nó do trabalhador

Como os nós de trabalho em seu cluster de VPC existem em uma conta de serviço e não estão listados no painel de infraestrutura da VPC, não é possível criar um grupo de segurança e aplicá-lo às instâncias do nó de trabalho. Você só pode modificar o grupo de segurança existente kube-<clusterID>.

Criação de logs e monitoramento

Ao configurar a criação de log e o monitoramento em um cluster 4.15 ou posterior, deve-se usar o terminal em serviço privado ao instalar o agente de criação de log em seu cluster. Os dados do log não serão salvos se o terminal público for usado

Monitorando clusters com nós do trabalhador RHCOS

O agente de monitoramento depende de cabeçalhos de kernel no sistema operacional; no entanto, o RHCOS não tem cabeçalhos de kernel Neste cenário, o agente retorna ao sysdig.com para usar o agente pré-compilado. Em clusters sem acesso à rede pública, esse processo falha. O eBPF agora está ativado por padrão para novas implementações do Sysdig. No entanto, se estiver enfrentando problemas em um cluster existente, verifique se o eBPF está ativado e ative-o, se necessário. Como alternativa, você pode permitir o tráfego de saída ou consultar a documentação da Sysdig para instalar o agente em ambientes com air-gap.

Cotas do cluster VPC

Criptografia em trânsito para VPC File Storage.

Para usar o EIT com clusters Secure by Default, você deve adicionar a seguinte regra de saída ao grupo de segurança kube-<clusterID>.

Protocolo: Qualquer
Tipo de fonte: Qualquer
Fonte: 0.0.0.0/0
Destino 169.254.169.254.

Comunicação de backup sobre a rede pública

Os trabalhadores do cluster VPC usam a rede privada para se comunicarem com o cluster mestre Anteriormente, para clusters de VPC que tinham o terminal de serviço público ativado, se a rede privada estava bloqueada ou indisponível, os trabalhadores do cluster poderiam voltar a usar a rede pública para se comunicar com o cluster mestre Em clusters Secure by Default, o fallback para a rede pública não é uma opção porque o tráfego de saída público dos trabalhadores do cluster está bloqueado.. Você pode desejar desativar a proteção de tráfego de saída para permitir essa opção de backup de rede pública, no entanto há uma alternativa melhor... Em vez disso, se houver um problema temporário com a conexão do trabalhador com o principal sobre a rede privada, então, nesse momento, será possível incluir uma regra do grupo de segurança temporária para o grupo de segurança kube-clusterID para permitir o tráfego de saída para a porta do cluster principal apiserver Mais tarde, quando o problema for resolvido, será possível remover a regra temporária

Criptografia do OpenShift Data Foundation e Portworx

Se você planeja usar o OpenShift Data Foundation ou Portworx em um cluster sem acesso à rede pública e deseja usar o Hyper Protect Crypto Services ou o Key Protect para criptografia, deve-se criar um gateway de terminal privado virtual (VPE) que permita o acesso à sua instância do KMS. Certifique-se de ligar pelo menos um endereço IP de cada sub-rede em seu VPC ao VPE.