Migração de uma lista de permissões de ponto de extremidade de serviço privado para restrições baseadas em contexto (CBR)

As listas de permissão de pontos de extremidade de serviços privados não são mais suportadas e, em vez disso, devem ser usadas restrições baseadas em contexto (CBR). Se seus clusters tiverem, atualmente, listas de permissão para endpoints de serviço privado mestre ativadas, você não poderá modificar a lista de permissão — só poderá desativá-la. Conclua as etapas a seguir para migrar para o uso de restrições baseadas em contexto (CBR).

As instruções a seguir abordam a proteção do endpoint de serviço privado de seu cluster usando regras de CBR. Se o seu cluster tiver um ponto de extremidade de serviço público e privado (PSE), você também poderá proteger o ponto de extremidade de serviço público do cluster com CBR.

Algumas vantagens do CBR incluem:

  • Direcione vários clusters em uma conta de uma só vez e não precise definir a lista para cada um deles.
  • Permitir o acesso de VPCs específicas, não apenas de IPs ou sub-redes.
  • Defina limites mais altos de até 200 IPs ou sub-redes privados e 500 públicos, em vez de um total máximo de 75 com o PSE.
  • Crie e gerencie regras de CBR a partir do console, da API ou da CLI.
  • Restringir o acesso público via CBR. A lista de permissões do ponto de extremidade de serviço privado restringe apenas o tráfego do ponto de extremidade de serviço privado.

Antes de Iniciar

Se você já estiver usando regras de CBR para proteger seus clusters, talvez essas instruções não sejam adequadas ao seu caso de uso. Em vez disso, use a documentação do CBR para entender como modificar suas regras de CBR existentes para incluir as sub-redes da lista de permissões do endpoint de serviço privado. Para obter mais informações sobre CBR, consulte Proteção de recursos de cluster com restrições baseadas em contexto e os exemplos de cenários de restrições baseadas em contexto.

Antes de começar a criar zonas e regras de CBR, verifique se a lista de permissões do ponto de extremidade do serviço privado está funcionando conforme o esperado. Depois de configurar o CBR, você pode executar novamente esses testes para confirmar o mesmo comportamento.

1 Acesse seu cluster Red Hat OpenShift. Direcione o endpoint de serviço privado de um sistema cliente que usa um IP privado que está em uma das sub-redes personalizadas em sua lista de permissões.

  1. Execute o seguinte comando para verificar se os IPs permitidos podem se conectar ao PSE.

    oc get nodes

1 Acesse seu cluster Red Hat OpenShift. Acesse o endpoint do serviço privado a partir de um endereço IP autorizado para verificar se você consegue se conectar.

1 Acesse seu cluster Red Hat OpenShift. Direcione o endpoint de serviço privado de um sistema cliente que usa um IP privado que não é permitido em sua lista de permissões.

  1. Execute novamente o comando anterior para verificar se os IPs que não estão na lista de permissões não podem se conectar ao PSE.

Agora que você verificou que sua lista de permissões está funcionando conforme o esperado, pode continuar com a migração.

Etapa 1: Analise os detalhes de sua lista de permissões

  1. Obtenha os detalhes de sua lista de permissões do PSE.

    Se uma lista de permissão PSE não estiver ativada em seu cluster, o comando falhará e o erro indicará que esse recurso está desativado. Nesse caso, seu cluster não requer nenhuma ação adicional.

    ibmcloud oc cluster master private-service-endpoint allowlist get -c CLUSTER

    Exemplo de saída

    Subnet             Type     Status
10.138.53.64/26    System   Active
10.30.50.0/24      Custom   Active
10.249.94.103/32   Custom   Active
OK
laptop

  2. Analise a saída e anote as sub-redes personalizadas. Essas sub-redes serão usadas posteriormente.

    • As entradas do sistema são migradas automaticamente e podem ser ignoradas. Essas entradas garantem que os trabalhadores do cluster tenham permissão para se conectar ao apiserver do cluster.
    • As entradas personalizadas são as sub-redes que você adicionou e que têm permissão para se conectar ao endpoint de serviço privado desse cluster. As sub-redes " 10.30.50.0/24 e " 10.249.94.103/32 no exemplo são adicionadas a uma zona de rede CBR na próxima etapa.

Etapa 2: Criação de uma zona de rede

Crie uma zona de rede CBR que contenha as mesmas sub-redes que sua lista de permissões de ponto de extremidade de serviço privado personalizado existente.

Criação de uma zona de rede no console

  1. Navegue até o console do CBR.

  2. Clique em Criar.

  3. Forneça os detalhes de sua zona de rede.

    • Nome: Dê um nome à sua zona de rede.
    • Endereços IP permitidos: Digite as sub-redes que você encontrou na etapa anterior.

  4. Clique em Next para revisar os detalhes de sua zona de rede.

  5. Clique em Create para concluir a criação de sua zona de rede.

Criação de uma zona de rede usando a CLI

  1. Crie uma zona de rede na CLI executando um comando semelhante a um dos exemplos a seguir.

    A sintaxe do comando ' cbr zone-create.

    ibmcloud cbr zone-create [--name NAME] [--description DESCRIPTION] [--addresses ADDRESSES] [--excluded EXCLUDED] [--vpc VPC] [--service-ref SERVICE-REF] [--file FILE]

    O parâmetro " --addresses deve ser uma lista separada por vírgulas de sub-redes que você encontrou na etapa acima em sua lista de permissões de ponto de extremidade de serviço privado.

    Exemplo de comando para criar uma zona de rede para um único cluster.

    ibmcloud cbr zone-create --name private-subnets-for-cluster-XXXXXX --description "Private subnets that are allowed to access the apisever of cluster XXXXXX" --addresses 10.30.50.0/24,10.249.94.103/32
    Exemplo de criação de zona CBR 1
    Parâmetro Descrição
    --name Dê um nome à sua zona de rede.
    --description Forneça uma descrição opcional da zona.
    --addresses Digite as sub-redes que você encontrou na lista de permissões do endpoint do serviço mestre na etapa anterior.

    Exemplo de comando para criar uma zona de rede para todos os clusters em sua conta.

    ibmcloud cbr zone-create --name private-subnets-for-all-clusters --description "Private subnets that are allowed to access my clusters" --addresses 10.30.50.0/24,10.249.94.103/32
    Exemplo de criação de zona CBR 1
    Parâmetro Descrição
    --name Dê um nome à sua zona de rede.
    --description Forneça uma descrição opcional da zona.
    --addresses Digite as sub-redes que você encontrou na lista de permissões do endpoint do serviço mestre na etapa anterior.

  2. Crie uma regra de CBR para proteger seu cluster com CBR. Essa regra faz referência ao seu cluster, ou a todos os clusters dessa conta, e também faz referência à zona de rede que você criou.

Etapa 3: Criação de uma regra CBR

Crie uma regra CBR que faça referência à zona de rede que você criou. É possível criar regras CBR no console, na CLI ou na API.

Criação de uma regra CBR no console

  1. Navegue até suas zonas de rede no console CBR.

  2. Clique em List of actions on your e clique em Edit.

  3. Adicione ou remova sub-redes, VPCs ou serviços à sua zona de rede para controlar quais recursos podem acessar um ou mais dos seus clusters.

Criação de uma regra CBR usando a CLI

As instruções a seguir descrevem como usar a CLI para criar uma zona de rede.

  1. Liste suas zonas de rede e anote o ID da zona de rede que você criou na etapa anterior.

    ibmcloud cbr zones

  2. Criar uma regra CBR. Você pode criar uma regra para proteger um único cluster ou todos os clusters da sua conta.

    A sintaxe do comando ' cbr rule-create.

    ibmcloud cbr rule-create [--description DESCRIPTION] [--context-attributes CONTEXT-ATTRIBUTES] [--resource-attributes RESOURCE-ATTRIBUTES] [--region REGION] [--resource RESOURCE] [--resource-group-id RESOURCE-GROUP-ID] [--resource-type RESOURCE-TYPE] [--service-instance SERVICE-INSTANCE-GUID] [--service-name SERVICE-NAME] [--zone-id ZONE-ID] [--tags TAGS] [--enforcement-mode ENFORCEMENT-MODE] [--file FILE]

    Se o seu cluster tiver um endpoint de serviço público, você deverá incluir o parâmetro " --context-attributes endpointType=public para que o tráfego seja permitido para o endpoint de serviço público. Se você não incluir essa opção, todo o tráfego público será bloqueado.

    Exemplo de comando que usa o " CLUSTER-ID do cluster e o " NETWORK-ZONE-ID da zona de rede da etapa anterior para criar uma regra CBR para proteger somente esse cluster.

    ibmcloud cbr rule-create --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --description "Protect private endpoint for cluster CLUSTER" --service-name containers-kubernetes --service-instance CLUSTER-ID --context-attributes endpointType=private,networkZoneId=NETWORK-ZONE-ID --context-attributes endpointType=public
    Exemplo de criação de regra CBR 1
    Parâmetro Descrição
    --api-types O valor " crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster indica as APIs principais do plano de controle do cluster. Para obter mais informações sobre os tipos de API para Red Hat OpenShift on IBM Cloud, consulte Proteção de APIs específicas.
    --description Uma descrição opcional da regra.
    --service-name containers-kubernetes O valor " containers-kubernetes indica Red Hat OpenShift on IBM Cloud como o serviço de destino da regra.
    --service-instance CLUSTER-ID Especifique o " CLUSTER-ID do cluster que você deseja proteger.
    --context-attributes endpointType=private,networkZoneId=NETWORK-ZONE-ID A opção permite que apenas os recursos na zona " NETWORK-ZONE-ID acessem o endpoint privado do cluster.
    --context-attributes endpointType=public Essa opção permite que todos os recursos acessem o endpoint público do cluster.
    networkZoneId Especifique o " NETWORK-ZONE-ID da zona que você criou anteriormente.

    Exemplo de comando que usa o " NETWORK-ZONE-ID da zona de rede da etapa anterior para criar uma regra CBR que protege todos os clusters dessa conta.

    ibmcloud cbr rule-create --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --description "Protect private endpoint for all clusters" --service-name containers-kubernetes --context-attributes endpointType=private,networkZoneId=NETWORK-ZONE-ID --context-attributes endpointType=public
    Exemplo de criação de regra CBR 2
    Parâmetro Descrição
    --api-types O valor " crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster indica as APIs principais do plano de controle do cluster. Para obter mais informações sobre os tipos de API para Red Hat OpenShift on IBM Cloud, consulte Proteção de APIs específicas.
    --description Uma descrição opcional da regra.
    --service-name O valor " containers-kubernetes indica Red Hat OpenShift on IBM Cloud como o serviço de destino da regra.
    --context-attributes endpointType=private,networkZoneId=NETWORK-ZONE-ID A opção permite que apenas os recursos na zona " NETWORK-ZONE-ID acessem o endpoint privado do cluster.
    --context-attributes endpointType=public Essa opção permite que todos os recursos acessem o endpoint público do cluster.
    networkZoneId Especifique o " NETWORK-ZONE-ID da zona que você criou anteriormente.

Ao criar uma regra, se você vir uma mensagem de erro que diz ' A rule with the same resource attributes already exists, então você já tem uma regra CBR protegendo seu cluster. Nesse caso, você deve atualizar a regra existente para adicionar a zona de rede. Para obter mais informações, consulte a documentação de atualização de regras do CBR.

Etapa 4: Desativar a lista de permissões do ponto de extremidade do serviço privado

Agora que o ponto de extremidade de serviço privado do cluster está protegido por uma regra CBR, você pode desativar a lista de permissões do ponto de extremidade de serviço privado.

Execute o seguinte comando.

ibmcloud oc cluster master private-service-endpoint allowlist disable -c CLUSTER

Etapa 5: Testar a regra CBR

Agora que a regra CBR está protegendo o endpoint de serviço privado do seu cluster, verifique se está funcionando conforme o esperado. Execute os mesmos testes que você concluiu anteriormente.

  1. {target_[both}].

  2. Execute o seguinte comando nesse cluster usando um ' kubeconfig que tem como alvo o endpoint de serviço privado.

    oc get nodes

  3. Teste esse comando em um sistema cliente que usa um IP privado que está em uma das sub-redes da zona de rede que você criou (para verificar se funciona) e, em seguida, em um sistema cliente que usa um IP privado que não está em nenhuma das sub-redes da zona de rede (para verificar se ele falha e atinge o tempo limite).

Se achar que o comportamento não é o esperado, verifique se há outras regras de CBR para o serviço ' containers-kubernetes que possam se aplicar ao seu cluster, pois elas também podem estar afetando o acesso ao cluster.

Etapa 6: Adicionar ou remover sub-redes que podem acessar o cluster

Agora que você está usando uma regra CBR para proteger o cluster, pode modificar a zona de rede para especificar quais sub-redes podem acessar o cluster.

Modificação da sua zona de rede a partir do console

  1. Navegue até a sua zona de rede no console do CBR.

  2. Selecione sua zona, clique na Lista de ações e clique em Editar.

  3. Adicione ou remova sub-redes, VPCs ou serviços à sua zona de rede para controlar quais recursos podem acessar os clusters escolhidos.

Modificar sua zona de rede a partir da CLI

Para adicionar sub-redes que possam acessar seu cluster, use o comando " cbr zone-update.

ibmcloud cbr zone-update <NETWORK-ZONE-ID> --name <NETWORK-ZONE-NAME> --addresses <EXISTING-SUBNETS>,<NEW-SUBNETS>

Observando o exemplo da zona de rede que foi criada anteriormente para todos os clusters da conta com as duas sub-redes " 10.30.50.0/24 e " 10.249.94.103/32. Um exemplo de comando para adicionar uma terceira sub-rede, " 10.10.10.0/24, seria o seguinte.

ibmcloud cbr zone-update <NETWORK-ZONE-ID> --name private-subnets-for-all-clusters --description "Private subnets that are allowed to access my clusters" --addresses 10.30.50.0/24,10.249.94.103/32,10.10.10.0/24

Você deve incluir todas as entradas existentes nessa zona de rede, bem como as que deseja adicionar. O valor que você especificar para ' --addresses substitui o endereço atual ou a lista de sub-redes nessa zona de rede.

Para remover sub-redes da zona, você pode usar o mesmo comando e omitir as sub-redes que deseja remover do valor " --addresses. Nesse caso, inclua apenas as sub-redes que você ainda deseja permitir que acessem seus clusters.

Remoção de restrições baseadas em contexto do ponto de extremidade do serviço privado

Excluindo uma regra do console

  1. Navegue até suas regras no console do CBR.

  2. Selecione sua regra, clique na Lista de ações e clique em Remover.

  3. Adicione ou remova sub-redes, VPCs ou serviços à sua zona de rede para controlar quais recursos podem acessar os clusters escolhidos.

Exclusão de uma regra da CLI

Você pode excluir regras CBR com o comando " ibmcloud cbr rule-delete <RULE-ID> ou " ibmcloud cbr rule-update <RULE-ID>.

Para remover completamente a proteção CBR de um cluster ou de todos os clusters, você deve excluir ou desativar todas as regras CBR que afetam o cluster.

Se você usar o comando " ibmcloud cbr rule-update para desativar ou ativar uma regra existente, deverá especificar todos os atributos da regra atual, além do parâmetro " --enforcement-mode disabled; caso contrário, os atributos omitidos serão removidos da regra.

Próximas etapas

Para obter mais informações sobre o CBR, consulte os links a seguir.