Visão geral

Com o Secure by Default Networking, ao provisionar um novo cluster VPC do IBM Cloud Kubernetes Service na versão 1.30 ou mais recente, somente o tráfego necessário para o cluster funcionar é permitido e todos os outros acessos são bloqueados. Para implementar Secure by Default Networking, o IBM Cloud Kubernetes Service usa vários grupos de segurança e regras do grupo de segurança para proteger componentes do 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.

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 IBM Cloud Kubernetes Service 1.28+ é criado em um determinado VPC ou um cluster nesse VPC tem seu principal atualizado para 1.28+, então 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.

Grupos de segurança gerenciados

O IBM Cloud Kubernetes Service cria e atualiza automaticamente os grupos de segurança e as regras a seguir para clusters VPC.

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 1.30 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 do kernel no sistema operacional; no entanto, o RHCOS não tem cabeçalhos do 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 tendo 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

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 IBM Cloud Kubernetes Service 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 um determinado VPC, Para obter mais informações, consulte Cotas de 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 comunicar com o cluster mestre. Anteriormente, para os clusters VPC que tinham o terminal em serviço público ativado, se a rede privada estivesse 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.. Talvez você queira 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 para o principal sobre a rede privada, então, nesse momento, será possível incluir uma regra do grupo de segurança temporária no 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 o Portworx em um cluster sem acesso à rede pública e desejar usar o Hyper Protect Crypto Services ou o Key Protect para criptografia, deverá 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.