Migrazione da un elenco di permessi di un endpoint di servizio privato a restrizioni basate sul contesto (CBR)

Gli elenchi di permessi degli endpoint dei servizi privati non sono più supportati e al loro posto devono essere utilizzate le restrizioni basate sul contesto (CBR). Se nei tuoi cluster sono attualmente attive le liste di autorizzazione per gli endpoint dei servizi privati master, non puoi modificare tali liste: puoi solo disattivarle. Completare i seguenti passaggi per migrare all'uso delle restrizioni basate sul contesto (CBR).

Le istruzioni che seguono riguardano la protezione dell'endpoint del servizio privato del cluster utilizzando le regole CBR. Se il cluster ha un endpoint di servizio pubblico e privato (PSE), è possibile proteggere anche l'endpoint di servizio pubblico del cluster con CBR.

Alcuni vantaggi del CBR sono:

  • È possibile indirizzare contemporaneamente più cluster in un account, senza dover impostare l'elenco per ciascuno di essi.
  • Consentire l'accesso da VPC specifiche, non solo da IP o sottoreti.
  • Impostare limiti più elevati, fino a 200 IP o sottoreti private e 500 pubbliche, anziché un totale massimo di 75 con PSE.
  • Creare e gestire le regole CBR da console, API o CLI.
  • Limitare l'accesso al pubblico tramite CBR. La allowlist dell'endpoint del servizio privato limita solo il traffico dell'endpoint del servizio privato.

Prima di iniziare

Se si utilizzano già le regole CBR per proteggere i cluster, queste istruzioni potrebbero non essere adatte al caso d'uso. Utilizzare invece la documentazione CBR per capire come modificare le regole CBR esistenti per includere le sottoreti allowlist degli endpoint dei servizi privati. Per ulteriori informazioni su CBR, vedere Protezione delle risorse del cluster con restrizioni basate sul contesto e gli scenari di esempio di restrizioni basate sul contesto.

Prima di iniziare a creare zone e regole CBR, verificare che l'elenco di permessi dell'endpoint del servizio privato funzioni come previsto. Dopo aver impostato CBR, è possibile eseguire nuovamente questi test per confermare lo stesso comportamento.

1 Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Impostare il contesto per il cluster.. Puntare all'endpoint del servizio privato da un sistema client che utilizza un IP privato che si trova in una delle sottoreti personalizzate dell'elenco di permessi.

  1. Eseguite il seguente comando per verificare che gli IP consentiti possano connettersi al PSE.

    kubectl get nodes

1 Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Impostare il contesto per il cluster.. Accedi all'endpoint del servizio privato da un indirizzo IP autorizzato per verificare che sia possibile connettersi.

1 Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Impostare il contesto per il cluster.. Puntare all'endpoint del servizio privato da un sistema client che utilizza un IP privato non consentito dall'elenco dei permessi.

  1. Eseguire nuovamente il comando precedente per verificare che gli IP non presenti nell'elenco dei permessi non possano connettersi al PSE.

Ora che avete verificato che la vostra allowlist funziona come previsto, potete continuare con la migrazione.

Fase 1: Esaminare i dettagli della vostra lista di permessi

  1. Ottenete i dettagli del vostro PSE allowlist.

    Se nel cluster non è abilitato un elenco di permessi PSE, il comando fallisce e l'errore indica che questa funzione è disabilitata. In questo caso, il cluster non richiede ulteriori interventi.

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

    Output di esempio

    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. Esaminare l'output e annotare le sottoreti personalizzate. Queste sottoreti verranno utilizzate in seguito.

    • Le voci di sistema vengono migrate automaticamente e possono essere ignorate. Queste voci assicurano che i lavoratori del cluster siano autorizzati a connettersi all'apiserver del cluster.
    • Le voci personalizzate sono le sottoreti aggiunte che possono connettersi all'endpoint del servizio privato di questo cluster. Le sottoreti " 10.30.50.0/24 e " 10.249.94.103/32 dell'esempio vengono aggiunte a una zona di rete CBR nel passaggio successivo.

Passo 2: creazione di una zona di rete

Creare una zona di rete CBR che contenga le stesse sottoreti dell'elenco dei punti finali del servizio privato personalizzato esistente.

Creazione di una zona di rete nella console

  1. Accedere alla console CBR.

  2. Fai clic su Crea.

  3. Fornire i dettagli della zona di rete.

    • Nome: Assegnare un nome alla zona di rete.
    • Indirizzi IP consentiti: Inserire le sottoreti individuate nel passaggio precedente.

  4. Fare clic su Avanti per rivedere i dettagli della zona di rete.

  5. Fare clic su Crea per terminare la creazione della zona di rete.

Creazione di una zona di rete tramite l'interfaccia CLI

  1. Creare una zona di rete dalla CLI eseguendo un comando simile a uno degli esempi seguenti.

    La sintassi del comando " cbr zone-create.

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

    Il parametro " --addresses deve essere un elenco separato da virgole di sottoreti trovate nel passaggio precedente nella allowlist dell'endpoint del servizio privato.

    Esempio di comando per creare una zona di rete per un singolo 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
    Esempio di creazione di una zona CBR 1
    Parametro Descrizione
    --name Assegnare un nome alla zona di rete.
    --description Fornire una descrizione facoltativa della zona.
    --addresses Inserire le sottoreti trovate nella allowlist dell'endpoint del servizio master nel passaggio precedente.

    Comando di esempio per creare una zona di rete per tutti i cluster dell'account.

    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
    Esempio di creazione di una zona CBR 1
    Parametro Descrizione
    --name Assegnare un nome alla zona di rete.
    --description Fornire una descrizione facoltativa della zona.
    --addresses Inserire le sottoreti trovate nella allowlist dell'endpoint del servizio master nel passaggio precedente.

  2. Creare una regola CBR per proteggere il cluster con CBR. Questa regola fa riferimento al proprio cluster, o a tutti i cluster di questo account, e fa anche riferimento alla zona di rete creata.

Passo 3: creazione di una regola CBR

Creare una regola CBR che faccia riferimento alla zona di rete creata. È possibile creare regole CBR nella console, nella CLI o nell'API.

Creazione di una regola CBR nella console

  1. Passare alle zone della rete nella console CBR.

  2. Fare clic sull'Elenco delle azioni e fare clic su Modifica.

  3. Aggiungete o rimuovete sottoreti, VPC o servizi alla vostra zona di rete per controllare quali risorse possono accedere a uno o più cluster.

Creazione di una regola CBR tramite l'interfaccia CLI

Le seguenti istruzioni descrivono come utilizzare la CLI per creare una zona di rete.

  1. Elencare le zone di rete e annotare l'ID della zona di rete creata nel passaggio precedente.

    ibmcloud cbr zones

  2. Creare una regola CBR. È possibile creare una regola per proteggere un singolo cluster o tutti i cluster dell'account.

    La sintassi del 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 il cluster ha un endpoint di servizio pubblico, è necessario includere il parametro '--context-attributes endpointType=public, in modo che il traffico sia consentito all'endpoint di servizio pubblico. Se non si include questa opzione, tutto il traffico pubblico viene bloccato.

    Comando di esempio che utilizza il 'CLUSTER-ID del cluster e il 'NETWORK-ZONE-ID della zona di rete del passo precedente per creare una regola CBR per proteggere solo questo 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
    Esempio di creazione della regola CBR 1
    Parametro Descrizione
    --api-types Il valore 'crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster indica le API master del piano di controllo del cluster. Per ulteriori informazioni sui tipi di API per IBM Cloud Kubernetes Service, vedere Protezione di API specifiche.
    --description Una descrizione facoltativa della regola.
    --service-name containers-kubernetes Il valore 'containers-kubernetes indica IBM Cloud Kubernetes Service come servizio di destinazione per la regola.
    --service-instance CLUSTER-ID Specificare il 'CLUSTER-ID del cluster che si desidera proteggere.
    --context-attributes endpointType=private,networkZoneId=NETWORK-ZONE-ID L'opzione consente solo alle risorse della zona 'NETWORK-ZONE-ID di accedere all'endpoint privato del cluster.
    --context-attributes endpointType=public Questa opzione consente a tutte le risorse di accedere all'endpoint pubblico del cluster.
    networkZoneId Specificare il " NETWORK-ZONE-ID della zona creata in precedenza.

    Esempio di comando che utilizza il 'NETWORK-ZONE-ID della zona di rete del passo precedente per creare una regola CBR che protegge tutti i cluster di questo account.

    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
    Esempio di creazione della regola CBR 2
    Parametro Descrizione
    --api-types Il valore 'crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster indica le API master del piano di controllo del cluster. Per ulteriori informazioni sui tipi di API per IBM Cloud Kubernetes Service, vedere Protezione di API specifiche.
    --description Una descrizione facoltativa della regola.
    --service-name Il valore 'containers-kubernetes indica IBM Cloud Kubernetes Service come servizio di destinazione per la regola.
    --context-attributes endpointType=private,networkZoneId=NETWORK-ZONE-ID L'opzione consente solo alle risorse della zona 'NETWORK-ZONE-ID di accedere all'endpoint privato del cluster.
    --context-attributes endpointType=public Questa opzione consente a tutte le risorse di accedere all'endpoint pubblico del cluster.
    networkZoneId Specificare il " NETWORK-ZONE-ID della zona creata in precedenza.

Quando si crea una regola, se viene visualizzato un messaggio di errore che dice 'A rule with the same resource attributes already exists, allora esiste già una regola CBR che protegge il cluster. In questo caso, è necessario aggiornare la regola esistente per aggiungere la zona di rete. Per ulteriori informazioni, consultare la documentazione sull'aggiornamento delle regole CBR.

Passo 4: Disabilitazione dell'elenco di permessi dell'endpoint del servizio privato

Ora che l'endpoint del servizio privato del cluster è protetto da una regola CBR, è possibile disattivare la allowlist dell'endpoint del servizio privato.

Immetti il seguente comando.

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

Fase 5: Verifica della regola CBR

Ora che la regola CBR protegge l'endpoint del servizio privato del cluster, verificare che funzioni come previsto. Eseguire gli stessi test completati in precedenza.

  1. {[Entrambi i] bersagli.}

  2. Eseguire il seguente comando su questo cluster utilizzando un 'kubeconfig che punta all'endpoint del servizio privato.

    kubectl get nodes

  3. Testate questo comando sia da un sistema client che utilizza un IP privato che si trova in una delle sottoreti della zona di rete creata (per verificare che funzioni), sia da un sistema client che utilizza un IP privato che non si trova in nessuna delle sottoreti della zona di rete (per verificare che fallisca e vada in timeout).

Se il comportamento non è quello previsto, verificare se ci sono altre regole CBR per il servizio 'containers-kubernetes che potrebbero essere applicate al cluster, in quanto potrebbero influenzare anche l'accesso al cluster.

Passo 6: Aggiunta o rimozione di sottoreti che possono accedere al cluster

Ora che si utilizza una regola CBR per proteggere il cluster, è possibile modificare la zona di rete per specificare quali sottoreti possono accedere al cluster.

Modifica della zona di rete dalla console

  1. Passare alla propria zona di rete nella console CBR.

  2. Selezionare la zona, quindi fare clic su Elenco di azioni e su Modifica.

  3. Aggiungere o rimuovere sottoreti, VPC o servizi alla zona di rete per controllare quali risorse possono accedere ai cluster scelti.

Modificare la zona di rete dalla CLI

Per aggiungere le sottoreti che possono accedere al cluster, si può usare il comando 'cbr zone-update.

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

Guardando l'esempio della zona di rete creata in precedenza per tutti i cluster dell'account con le due sottoreti '10.30.50.0/24 e '10.249.94.103/32. Un esempio di comando per aggiungere una terza sottorete, " 10.10.10.0/24, è il seguente.

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

È necessario includere tutte le voci esistenti in quella zona di rete e quelle che si desidera aggiungere. Il valore specificato per '--addresses sostituisce l'indirizzo o l'elenco di sottoreti corrente in quella zona di rete.

Per rimuovere le sottoreti dalla zona, si può usare lo stesso comando e omettere le sottoreti che si desidera rimuovere dal valore '--addresses. In questo caso, includere solo le sottoreti a cui si vuole ancora consentire l'accesso ai cluster.

Rimozione delle restrizioni basate sul contesto dall'endpoint del servizio privato

Eliminazione di una regola dalla console

  1. Passare alle regole nella console CBR.

  2. Selezionare la regola, quindi fare clic su Elenco di azioni e su Rimuovi.

  3. Aggiungete o rimuovete sottoreti, VPC o servizi alla vostra zona di rete per controllare quali risorse possono accedere ai cluster scelti.

Eliminazione di una regola dalla CLI

È possibile eliminare le regole CBR con il comando 'ibmcloud cbr rule-delete <RULE-ID> o 'ibmcloud cbr rule-update <RULE-ID>.

Per rimuovere completamente la protezione CBR da un cluster o da tutti i cluster, è necessario eliminare o disattivare tutte le regole CBR che riguardano il cluster.

Se si usa il comando 'ibmcloud cbr rule-update per disabilitare o abilitare una regola esistente, è necessario specificare tutti gli attributi della regola corrente oltre al parametro '--enforcement-mode disabled, altrimenti gli attributi omessi vengono rimossi dalla regola.

Passi successivi

Per ulteriori informazioni su CBR, consultare i seguenti link.