Dela via


Ta med din egen nätverkssäkerhetsgrupp (NSG) till ett Azure Red Hat OpenShift-kluster (ARO)

När du konfigurerar ett ARO-kluster måste du vanligtvis ange en resursgrupp för att distribuera ARO-klusterobjektet (kallas för basresursgruppen i följande diagram). I sådana scenarier kan du använda antingen samma resursgrupp för både det virtuella nätverket (VNET) och klustret, eller så kan du välja en separat resursgrupp enbart för det virtuella nätverket. Ingen av dessa resursgrupper motsvarar direkt ett enda ARO-kluster, vilket ger dig fullständig kontroll över dem. Det innebär att du fritt kan skapa, ändra eller ta bort resurser i dessa resursgrupper.

Under klusterskapandeprocessen upprättar ARO-resursprovidern (RP) en dedikerad resursgrupp som är specifik för klustrets behov. Den här gruppen innehåller olika klusterspecifika resurser som virtuella noddatorer, lastbalanserare och nätverkssäkerhetsgrupper (NSG:er), som visas av den hanterade resursgruppen i följande diagram. Den hanterade resursgruppen är väl skyddad, vilket förbjuder ändringar av innehållet, inklusive den NSG som är länkad till de VNET-undernät som angavs när klustret skapades. I vissa situationer kanske den NSG som genereras av ARO-RP inte följer säkerhetsprinciperna för vissa organisationer.

Diagram som visar en översikt över hur nätverkssäkerhetsgrupper fungerar i ett typiskt ARO-kluster.

Den här artikeln visar hur du använder funktionen "Bring Your Own" Network Security Group (NSG) för att koppla din egen förkonfigurerade NSG som finns i resursgruppen Base/VNET (RG) (visas i följande diagram som BYO-NSG) till ARO-klusterundernäten. Eftersom du äger den här förkonfigurerade NSG:n kan du lägga till/ta bort regler under ARO-klustrets livslängd.

Diagram som visar en översikt över hur du tar med din egen nätverkssäkerhetsgrupp fungerar i Azure Red Hat OpenShift.

Allmänna funktioner och begränsningar

  • Du måste koppla dina förkonfigurerade NSG:er till både huvud- och arbetsundernät innan du skapar klustret. Det gick inte att koppla dina förkonfigurerade NSG:er till båda undernäten, vilket resulterar i ett fel.

  • Du kan välja att använda samma eller olika förkonfigurerade NSG:er för huvud- och arbetsundernät.

  • När du använder din egen NSG skapar ARO RP fortfarande en NSG i den hanterade resursgruppen (standard-NSG), men den NSG:n är inte kopplad till arbets- eller huvudundernäten.

  • Du kan inte aktivera den förkonfigurerade NSG-funktionen i ett befintligt ARO-kluster. För närvarande kan den här funktionen endast aktiveras när klustret skapas.

  • Det förkonfigurerade NSG-alternativet kan inte konfigureras från Azure-portalen.

  • Om du använde den här funktionen under förhandsversionen stöds nu dina befintliga förkonfigurerade kluster fullt ut.

Kommentar

Om du använder NSG-funktionen "Bring Your Own" och vill använda NSG-flödesloggar läser du Flow-loggning för nätverkssäkerhetsgrupper i Azure Network Watcher-dokumentationen i stället för dokumentationen för ARO-specifika flödesloggar (som inte fungerar med bring your own NSG-funktionen).

Använda regler

Varning

Förkonfigurerade NSG:er uppdateras inte automatiskt med regler när du skapar Kubernetes LoadBalancer-typtjänster eller OpenShift-vägar i ARO-klustret. Därför måste du uppdatera dessa regler manuellt efter behov. Det här beteendet skiljer sig från det ursprungliga ARO-beteendet där standard-NSG:n uppdateras programmatiskt i sådana situationer.

  • Standard-NSG för ARO-kluster (inte kopplat till något undernät när du använder den här funktionen) uppdateras fortfarande med regler när du skapar Kubernetes LoadBalancer-typtjänster eller OpenShift-vägar i ARO-klustret.

  • Du kan koppla från förkonfigurerade NSG:er från undernäten i klustret som skapats med den här funktionen. Det resulterar i ett kluster med undernät som inte har några NSG:er. Du kan sedan koppla en annan uppsättning förkonfigurerade NSG:er till klustret. Du kan också koppla ARO-standard-NSG:n till klusterundernäten (då blir klustret som alla andra kluster som inte använder den här funktionen).

  • Dina förkonfigurerade NSG:er bör inte ha regler för INKOMMANDE/UTGÅENDE NEKAnde av följande typer, eftersom dessa kan störa klustrets drift och/eller hindra ARO-support-/SRE-teamen från att tillhandahålla support/hantering. (Här anger undernätet alla eller alla IP-adresser i undernätet och alla portar som motsvarar det undernätet):

    • Huvudundernät ←→ huvudundernät

    • Arbetsundernät ←→ Worker-undernät

    • Huvudundernät ←→ Worker-undernät

    • Felkonfigurerade regler resulterar i en signal som används av Azure Monitor för att felsöka förkonfigurerade NSG:er.

  • Om du vill tillåta inkommande trafik till ditt offentliga ARO-kluster anger du följande REGLER FÖR INKOMMANDE TILLÅT (eller motsvarande) i din NSG. Se standard-NSG för klustret för specifik information och i exemplet med NSG som visas i Distribution. Du kan skapa ett kluster även utan sådana regler i NSG.

    • För API-serveråtkomst → Från Internet (eller dina önskade käll-IP-adresser) till port 6443 i huvudundernätet.
    • För åtkomst till OpenShift-routern (och därmed till OpenShift-konsolen och OpenShift-vägar) → från Internet (eller dina önskade käll-IP-adresser) till portarna 80 och 443 på den offentliga IP-adressen default-v4 på klustrets offentliga lastbalanserare.
    • För åtkomst till alla Kubernetes-tjänster av typen Lastbalanserare → Från Internet (eller dina önskade käll-IP-adresser) till tjänstportar på en offentlig IP-adress som motsvarar tjänsten i klustrets offentliga lastbalanserare.

Distribution

Skapa VNET och skapa och konfigurera förkonfigurerad NSG

  1. Skapa ett virtuellt nätverk och skapa sedan huvud- och arbetsundernät i det.

  2. Skapa förkonfigurerade NSG:er med standardregler (eller inga regler alls) och koppla dem till huvud- och arbetsundernäten.

Skapa ett ARO-kluster och uppdatera förkonfigurerade NSG:er

  1. Skapa klustret.

    az aro create \
    --resource-group BASE_RESOURCE_GROUP_NAME \
    --name CLUSTER_NAME \
    --vnet VNET_NAME \
    --master-subnet MASTER_SUBNET_NAME \
    --worker-subnet WORKER_SUBNET_NAME \
    --client-id CLUSTER_SERVICE_PRINCIPAL_ID \
    --client-secret CLUSTER_SERVICE_PRINCIPAL_SECRET \
    --enable-preconfigured-nsg
    
  2. Uppdatera de förkonfigurerade NSG:erna med regler enligt dina krav samtidigt som du överväger de punkter som nämns i Funktioner och begränsningar.

    I följande exempel finns den offentliga klusterlastbalanseraren enligt skärmbilden/CLI-utdata:

    Skärmbild av klustrets offentliga lastbalanserare som visas med utdata från kommandot.

    $ oc get svc | grep tools
    tools LoadBalancer 172.30.182.7 20.141.176.3 80:30520/TCP 143m
    $ $ oc get svc -n openshift-ingress | grep Load
    router-default LoadBalancer 172.30.105.218 20.159.139.208 80:31157/TCP,443:31177/TCP 
    5d20
    

    Skärmbild som visar regler för inkommande och utgående säkerhet.