Configurare i criteri di rete per il cluster

ClusterNetworkPolicy consente di definire le posture di sicurezza globali di GKE nell'intero cluster. Questo documento è destinato agli amministratori dei cluster che devono applicare misure di sicurezza obbligatorie o stabilire baseline zero-trust.

Questa risorsa si basa su una gerarchia di valutazione rigorosa che opera con una precedenza superiore rispetto alle risorse NetworkPolicy standard con ambito a livello di spazio dei nomi. Puoi utilizzare la risorsa ClusterNetworkPolicy per implementare azioni Nega, Accetta o Passa esplicite. Queste azioni ti consentono di configurare policy di autorizzazione o negazione globali, delegare il controllo del traffico a spazi dei nomi specifici e limitare il traffico in uscita a blocchi CIDR.

Prima di iniziare

Prima di configurare una policy di rete per il cluster, assicurati di soddisfare i seguenti requisiti:

  1. Assicurati che il cluster GKE esegua la versione 1.36.0-gke.4447000 o successive.
  2. Assicurati che il cluster utilizzi GKE Dataplane V2.

Protocolli e porte supportati

Le regole ClusterNetworkPolicy possono corrispondere al traffico in base ai protocolli TCP, UDP o SCTP. Puoi specificare le porte di destinazione nei seguenti modi:

  • Numero di porta specifico: utilizza l'impostazione destinationPort.number per scegliere come target una singola porta (ad esempio, 80).
  • Intervallo di porte: utilizza l'impostazione destinationPort.range per scegliere come target un intervallo di porte (ad esempio, da 8000 a 9000).
  • Porta denominata: utilizza l'impostazione destinationNamedPort per scegliere come target un nome simbolico definito in una specifica Pod.

Gerarchia di valutazione delle policy

A differenza delle NetworkPolicy standard e additive, una ClusterNetworkPolicy (CNP) si basa su una gerarchia di valutazione rigorosa in cui vince la prima regola corrispondente. Il traffico fluisce in sequenza attraverso una pipeline a tre livelli:

  • Il livello: le regole di amministrazione vengono eseguite per prime, a cascata fino a NetworkPolicy, poi Baseline.
  • Priorità CNP: all'interno di un livello, le policy vengono valutate in base alla loro priorità numerica esplicita.
  • Ordine delle regole CNP: all'interno di un singolo criterio, le regole vengono elaborate dall'alto verso il basso come un elenco di controllo dell'accesso (ACL).

Diagramma che mostra la gerarchia di valutazione delle policy di rete GKE

Il diagramma precedente illustra il flusso decisionale della gerarchia di valutazione CNP:

  1. Livello amministratore: il traffico viene prima valutato in base alle regole ClusterNetworkPolicy nel livello Admin. Se viene trovata una corrispondenza Consenti o Nega, la valutazione si interrompe. Se non esiste una corrispondenza o un'azione Pass, il traffico procede al livello NetworkPolicy.
  2. Livello NetworkPolicy: il traffico viene valutato in base alle norme standard dello spazio dei nomi. Se viene trovata una corrispondenza, il traffico è consentito. Se non viene trovata alcuna corrispondenza, il traffico passa al livello di base.
  3. Livello di base: il traffico viene valutato in base alle regole ClusterNetworkPolicy nel livello di base. Se viene trovata una corrispondenza Consenti o Nega, la valutazione si interrompe. Se non viene trovata alcuna corrispondenza, il traffico procede con il comportamento predefinito.
  4. Comportamento predefinito di GKE: se non viene trovata alcuna corrispondenza con i criteri in nessun livello, il traffico è soggetto a un comportamento di autorizzazione implicita.

Azioni del verdetto: Consenti, Nega e Passa

Una volta abbinato un pacchetto, ogni regola attiva una delle tre azioni rigide:

  • Nega: blocca immediatamente il traffico.
  • Accetta: consente il traffico. Entrambe le azioni interrompono immediatamente la pipeline, che ignora tutte le norme rimanenti.
  • Passa: trasferisce il controllo al livello successivo, consentendo agli ingegneri della piattaforma di delegare decisioni specifiche sul traffico a criteri standard a livello di spazio dei nomi senza rinunciare al controllo amministrativo generale.

Configura un criterio di negazione globale

Per isolare uno spazio dei nomi sensibile da tutto il resto del traffico interno del cluster, applica una regola di negazione non sostituibile. Questa policy di negazione predefinita contribuisce a garantire che qualsiasi traffico da o verso lo spazio dei nomi sensibile venga bloccato a livello amministrativo. Questo criterio funge da baseline protettiva che non può essere ignorata accidentalmente dalle regole a livello di spazio dei nomi.

  1. Salva il seguente manifest come global-deny.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: cluster-wide-deny-sensitive
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: sensitive-ns
  ingress:
  - action: Deny
    name: deny-all-ingress
    from:
    - namespaces:
        matchLabels: {}
  egress:
  - action: Deny
    name: deny-all-egress
    to:
    - namespaces:
        matchLabels: {}

  2. Applica il manifest al cluster:

    kubectl apply -f global-deny.yaml

Configura una policy di autorizzazione globale

Una policy di autorizzazione globale può contribuire a garantire che tutti i pod possano raggiungere il servizio DNS del cluster, indipendentemente dalle policy di rete create dagli sviluppatori.

  1. Salva il seguente manifest come global-allow-dns.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-kube-dns-admin
spec:
  tier: Admin
  priority: 20
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-dns-egress
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
    protocols:
    - udp:
        destinationPort:
          number: 53
    - tcp:
        destinationPort:
          number: 53

  2. Applica il manifest al cluster:

    kubectl apply -f global-allow-dns.yaml

Delega il traffico alle policy dello spazio dei nomi

Delega pattern di traffico specifici a oggetti NetworkPolicy standard con ambito di spazio dei nomi.

  1. Salva il seguente manifest come delegate-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: delegate-to-netpol
spec:
  tier: Admin
  priority: 30
  subject:
    namespaces: {}
  egress:
  - action: Pass
    name: delegate-web-traffic
    to:
    - namespaces:
        matchLabels:
          app: web-backend
    protocols:
    - tcp:
        destinationPort:
          number: 8080

  2. Applica il manifest al cluster:

    kubectl apply -f delegate-policy.yaml

  3. Per consentire il traffico delegato all'interno dello spazio dei nomi di destinazione, salva il seguente manifest standard NetworkPolicy come allow-web-backend.yaml :

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-backend
  namespace: backend-ns
spec:
  podSelector:
    matchLabels:
      app: web-backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app: web-frontend
    ports:
    - protocol: TCP
      port: 8080

  4. Applica il manifest standard NetworkPolicy al tuo cluster:

    kubectl apply -f allow-web-backend.yaml

Configura i sistemi di protezione di base

Stabilisci una postura di sicurezza GKE predefinita che gli amministratori dello spazio dei nomi possono ignorare utilizzando le policy di rete standard.

  1. Salva il seguente manifest di base come baseline-deny.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: default-deny-baseline
spec:
  tier: Baseline
  priority: 100
  subject:
    namespaces: {}
  ingress:
  - action: Deny
    name: baseline-deny-all
    from:
    - namespaces: {}

  2. Applica il manifest di base al tuo cluster:

    kubectl apply -f baseline-deny.yaml

  3. Salva il seguente manifest di override dello sviluppatore come developer-allow.yaml:

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-access
  namespace: my-app-ns
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx

  4. Applica il manifest di override al cluster:

    kubectl apply -f developer-allow.yaml

Configurare i criteri utilizzando le porte denominate

Per astrarre i numeri di porta dalle tue policy di sicurezza, fai riferimento alle porte denominate definite nelle specifiche del pod.

  1. Salva il seguente manifest di deployment come app-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
spec:
  template:
    spec:
      containers:
      - name: web-container
        image: nginx
        ports:
        - name: http-web
          containerPort: 8080

  2. Applica il manifest di deployment al cluster:

    kubectl apply -f app-deployment.yaml

  3. Salva il seguente manifest della policy come named-port-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-web-named-port
spec:
  tier: Admin
  priority: 40
  subject:
    namespaces: {}
  egress:
  - action: Accept
    to:
    - namespaces:
        matchLabels:
          app: my-webapp
    protocols:
    - tcp:
        destinationNamedPort: http-web

  4. Applica il manifest della policy al tuo cluster:

    kubectl apply -f named-port-policy.yaml

Limitare il traffico in uscita ai blocchi CIDR

Controlla l'accesso a risorse esterne o intranet aziendali specificando blocchi CIDR.

  1. Salva il seguente manifest come cidr-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-egress-to-intranet
spec:
  tier: Admin
  priority: 60
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-intranet
    to:
    - networks:
      - 10.0.0.0/8
      - 192.168.0.0/16

  2. Applica il manifest al cluster:

    kubectl apply -f cidr-policy.yaml

Configura la precedenza della priorità

Per controllare l'ordine di valutazione quando più policy si applicano agli stessi pod, specifica una priorità. Le priorità vanno da 0 a 1000, dove i numeri più bassi indicano una precedenza più elevata. Un singolo oggetto ClusterNetworkPolicy può contenere un massimo di 100 regole in entrata e 100 regole in uscita.

  1. Salva il seguente manifest come priority-policies.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: deny-beta
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-beta-monitoring
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            team: beta
        podSelector:
          matchLabels:
            app: monitoring
  - action: Deny
    name: deny-all-other-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta
---
apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-beta
spec:
  tier: Admin
  priority: 50
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-all-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta

  2. Applica il manifest al cluster:

    kubectl apply -f priority-policies.yaml

Risoluzione dei problemi

Per trovare metodi per diagnosticare e risolvere gli errori delle policy, utilizza i seguenti comandi.

Elenca tutte le policy di rete per il cluster nel tuo cluster:

kubectl get clusternetworkpolicies

Descrivi una norma specifica per esaminarne lo stato e il livello di valutazione:

kubectl describe clusternetworkpolicy/<policy-name>

Il campo status.conditions nell'output fornisce informazioni sul fatto che i criteri siano stati riconciliati correttamente dall'implementazione di rete del cluster.

Per monitorare i flussi di traffico e le decisioni relative alle norme, utilizza l'osservabilità di GKE Dataplane V2.

Passaggi successivi