Usa le policy di rete con la modalità automatica di EKS - Amazon EKS
Panoramica di Nozioni di baseCome funziona?Considerazioni

Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Usa le policy di rete con la modalità automatica di EKS

Panoramica di

Man mano che i clienti scalano i propri ambienti applicativi utilizzando EKS, l'isolamento del traffico di rete diventa sempre più fondamentale per prevenire l'accesso non autorizzato alle risorse all'interno e all'esterno del cluster. Ciò è particolarmente importante in un ambiente multi-tenant con più carichi di lavoro non correlati che vengono eseguiti fianco a fianco nel cluster. Le policy di rete Kubernetes consentono di migliorare il livello di sicurezza della rete per i carichi di lavoro Kubernetes e le relative integrazioni con endpoint esterni al cluster. EKS Auto Mode supporta diversi tipi di politiche di rete.

Isolamento di livello 3 e 4

Le policy di rete Kubernetes standard operano ai livelli 3 e 4 del modello di rete OSI e consentono di controllare il flusso di traffico a livello di indirizzo IP o di porta all'interno del cluster Amazon EKS.

Casi d’uso

  • Segmenta il traffico di rete tra i carichi di lavoro per garantire che solo le applicazioni correlate possano comunicare tra loro.

  • Isola i tenant a livello di namespace utilizzando policy per imporre la separazione della rete.

Applicazione basata sul DNS

I clienti in genere implementano carichi di lavoro in EKS che fanno parte di un ambiente distribuito più ampio, alcuni dei quali devono comunicare con sistemi e servizi esterni al cluster (traffico in direzione nord). Questi sistemi e servizi possono essere nel AWS cloud o all'esterno. AWS Le policy basate sul Domain Name System (DNS) consentono di rafforzare il livello di sicurezza adottando un approccio più stabile e prevedibile per impedire l'accesso non autorizzato dai pod a risorse o endpoint esterni al cluster. Questo meccanismo elimina la necessità di tracciare e consentire manualmente l'elenco di indirizzi IP specifici. Proteggendo le risorse con un approccio basato sul DNS, si ha anche una maggiore flessibilità nell'aggiornare l'infrastruttura esterna senza dover allentare il livello di sicurezza o modificare le politiche di rete a causa delle modifiche apportate ai server e agli host upstream. È possibile filtrare il traffico in uscita verso endpoint esterni utilizzando un nome di dominio completo (FQDN) o uno schema corrispondente per un nome di dominio DNS. Ciò offre la maggiore flessibilità di estendere l'accesso a più sottodomini associati a un particolare endpoint esterno al cluster.

Casi d’uso

  • Standardizza un approccio basato su DNS per filtrare l'accesso da un ambiente Kubernetes agli endpoint esterni al cluster.

  • Accesso AWS sicuro ai servizi in un ambiente multi-tenant.

  • Gestisci l'accesso alla rete dai pod ai carichi di lavoro on-premise nei tuoi ambienti cloud ibridi.

Regole amministrative (o con ambito cluster)

In alcuni casi, come negli scenari multi-tenant, i clienti potrebbero avere l'esigenza di applicare uno standard di sicurezza di rete che si applichi all'intero cluster. Invece di definire e mantenere ripetutamente una policy distinta per ogni namespace, è possibile utilizzare un'unica policy per gestire centralmente i controlli di accesso alla rete per i diversi carichi di lavoro del cluster, indipendentemente dal relativo namespace. Questi tipi di policy consentono di estendere l'ambito di applicazione delle regole di filtraggio di rete applicate a livello 3, livello 4 e quando si utilizzano regole DNS.

Casi d’uso

  • Gestisci centralmente i controlli di accesso alla rete per tutti (o un sottoinsieme di) carichi di lavoro nel tuo cluster EKS.

  • Definisci una posizione di sicurezza di rete predefinita in tutto il cluster.

  • Estendi gli standard di sicurezza organizzativi all'ambito del cluster in un modo più efficiente dal punto di vista operativo.

Nozioni di base

Prerequisiti

  • Un cluster Amazon EKS con la modalità automatica di EKS abilitata

  • kubectl configurato per connettersi al cluster

Fase 1: abilitare il controller della policy di rete

Per utilizzare le politiche di rete con EKS Auto Mode, devi prima abilitare il Network Policy Controller applicando un ConfigMap al tuo cluster.

  1. Crea un file denominato enable-network-policy.yaml con i seguenti contenuti:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

  2. Applica il ConfigMap al tuo cluster:

    kubectl apply -f enable-network-policy.yaml

Fase 2: Creare e testare le politiche di rete

Il cluster della modalità automatica di EKS è ora configurato per supportare le policy di rete di Kubernetes. Puoi testarlo con la Demo delle policy di rete con Stars per Amazon EKS.

Fase 3: Modifica della configurazione di Network Policy Agent in Node Class (opzionale)

Facoltativamente, è possibile creare una nuova classe di nodi per modificare il comportamento predefinito del Network Policy Agent sui nodi o abilitare la registrazione degli eventi di Network Policy. A tale scopo, seguire queste fasi:

  1. Crea o modifica un file YAML di classe del nodo (ad esempio, nodeclass-network-policy.yaml) con i seguenti contenuti:

    apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-config
spec:
  # Optional: Changes default network policy behavior
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

  2. Applica la configurazione di classe del nodo al cluster:

    kubectl apply -f nodeclass-network-policy.yaml

  3. Verifica che la classe del nodo sia stata creata:

    kubectl get nodeclass network-policy-config

  4. Aggiorna il pool di nodi per utilizzare questa classe di nodi. Per ulteriori informazioni, consulta Crea un pool di nodi per EKS Auto Mode.

Come funziona?

Politica di rete basata su DNS

Illustrazione del flusso di lavoro quando viene applicata una politica basata su DNS in EKS Auto
Illustrazione del flusso di lavoro quando una politica basata su DNS viene applicata in EKS Auto

  1. Il team della piattaforma applica una politica basata su DNS al cluster EKS.

  2. Il Network Policy Controller è responsabile del monitoraggio della creazione di politiche all'interno del cluster e della successiva riconciliazione degli endpoint delle politiche. In questo caso d'uso, il network policy controller ordina all'agente del nodo di filtrare le richieste DNS in base ai domini consentiti elencati nella policy creata. I nomi di dominio vengono elencati nell'elenco consentito utilizzando l'FQDN o un nome di dominio che corrisponde a uno schema definito nella configurazione delle risorse Kubernetes.

  3. Workload A tenta di risolvere l'IP per un endpoint esterno al cluster. La richiesta DNS passa innanzitutto attraverso un proxy che filtra tali richieste in base all'elenco di autorizzazioni applicato tramite la politica di rete.

  4. Una volta che la richiesta DNS passa attraverso l'elenco dei filtri DNS consentiti, viene inoltrata tramite proxy a CoredNS,

  5. CoreDNS a sua volta invia la richiesta al Resolver DNS esterno (Amazon Route 53 Resolver) per ottenere l'elenco degli indirizzi IP dietro il nome di dominio.

  6. I dati risolti IPs con TTL vengono restituiti nella risposta alla richiesta DNS. Questi IPs vengono quindi scritti in una mappa eBPF che viene utilizzata nella fase successiva per l'applicazione del livello IP.

  7. Le sonde eBPF collegate all'interfaccia Pod veth filtreranno quindi il traffico in uscita dal carico di lavoro A all'endpoint esterno del cluster in base alle regole in vigore. Ciò garantisce che i pod possano inviare traffico esterno al cluster solo verso i domini consentiti elencati. IPs La validità di questi si IPs basa sul TTL recuperato dal Resolver DNS esterno (Amazon Route 53 Resolver).

Utilizzo della policy di rete dell'applicazione

ApplicationNetworkPolicyCombina le funzionalità delle politiche di rete Kubernetes standard con il filtraggio basato su DNS a livello di namespace utilizzando un'unica Custom Resource Definition (CRD). Pertanto, può essere utilizzato per: ApplicationNetworkPolicy

  1. Definizione delle restrizioni ai livelli 3 e 4 dello stack di rete utilizzando blocchi IP e numeri di porta.

  2. Definizione di regole che operano al livello 7 dello stack di rete e consentono di filtrare il traffico in base a. FQDNs

Nota importante: le regole basate sul DNS definite utilizzando il ApplicationNetworkPolicy sono applicabili solo ai carichi di lavoro in esecuzione su istanze lanciate in modalità automatica EKS. EC2

Esempio

Nel cluster EKS Auto Mode è presente un carico di lavoro che deve comunicare con un'applicazione locale basata su un sistema di bilanciamento del carico con un nome DNS. È possibile ottenere ciò utilizzando la seguente politica di rete:

apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

A livello di rete Kubernetes, ciò consentirebbe l'uscita da qualsiasi pod nello spazio dei nomi «galaxy» etichettato con role: backend per connettersi al nome di dominio myapp.mydomain.com sulla porta TCP 8080. Inoltre, è necessario configurare la connettività di rete per il traffico in uscita dal VPC al data center aziendale.

Illustrazione del carico di lavoro in EKS Auto: comunicazione con le applicazioni in locale

Politica di rete di amministrazione (o cluster)

Illustrazione dell'ordine di valutazione delle politiche di rete in EKS

Utilizzo della politica di rete del cluster

Quando si utilizza aClusterNetworkPolicy, le politiche del livello di amministrazione vengono valutate per prime e non possono essere sostituite. Una volta valutate le politiche di livello amministratore, le politiche standard con ambito dei namespace vengono utilizzate per eseguire le regole di segmentazione della rete applicate. Questa operazione può essere eseguita utilizzando uno dei due o. ApplicationNetworkPolicy NetworkPolicy Infine, verranno applicate le regole del livello di base che definiscono le restrizioni di rete predefinite per i carichi di lavoro dei cluster. Queste regole del livello di base possono essere sostituite dalle policy con ambito dei namespace, se necessario.

Esempio

Nel cluster è presente un'applicazione che si desidera isolare dagli altri carichi di lavoro dei tenant. È possibile bloccare in modo esplicito il traffico del cluster proveniente da altri namespace per impedire l'accesso di rete allo spazio dei nomi riservato del carico di lavoro.

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

Considerazioni

Comprendi l'ordine di valutazione delle politiche

Le funzionalità relative alle politiche di rete supportate in EKS vengono valutate in un ordine specifico per garantire una gestione del traffico prevedibile e sicura. Pertanto, è importante comprendere il flusso di valutazione per progettare una posizione di sicurezza di rete efficace per il proprio ambiente.

  1. Politiche del livello di amministrazione (valutate per prime): tutte le politiche di livello amministratore ClusterNetworkPolicies vengono valutate prima di qualsiasi altra politica. All'interno del livello di amministrazione, le politiche vengono elaborate in ordine di priorità (prima il numero di priorità più basso). Il tipo di azione determina cosa succede dopo.

    • Nega azione (priorità massima): quando una politica di amministrazione con un'azione Rifiuta corrisponde al traffico, tale traffico viene immediatamente bloccato indipendentemente da qualsiasi altra politica. Non vengono elaborate ClusterNetworkPolicy ulteriori NetworkPolicy regole. Ciò garantisce che i controlli di sicurezza a livello di organizzazione non possano essere sostituiti da politiche a livello di namespace.

    • Consenti azioni: dopo la valutazione delle regole Deny, le politiche di amministrazione con le azioni Consenti vengono elaborate in ordine di priorità (inizia con il numero di priorità più basso). Quando un'azione Consenti corrisponde, il traffico viene accettato e non viene effettuata alcuna ulteriore valutazione delle politiche. Queste politiche possono concedere l'accesso su più namespace in base a selettori di etichette, fornendo un controllo centralizzato su quali carichi di lavoro possono accedere a risorse specifiche.

    • Pass action: le azioni Pass Action nelle policy del livello di amministrazione delegano il processo decisionale ai livelli inferiori. Quando il traffico corrisponde a una regola Pass, la valutazione salta tutte le regole rimanenti del livello di amministratore per quel traffico e passa direttamente al livello. NetworkPolicy Ciò consente agli amministratori di delegare in modo esplicito il controllo di determinati modelli di traffico ai team applicativi. Ad esempio, è possibile utilizzare le regole Pass per delegare la gestione del traffico all'interno del namespace agli amministratori del namespace, mantenendo al contempo controlli rigorosi sull'accesso esterno.

  2. Livello di policy di rete: se nessuna politica del livello di amministratore corrisponde a Deny o Allow, o se è stata soddisfatta un'azione Pass, vengono successivamente valutate le risorse tradizionali e con ambito namespace. ApplicationNetworkPolicy NetworkPolicy Queste policy forniscono un controllo granulare all'interno dei singoli namespace e sono gestite dai team applicativi. Le politiche con ambito namespace possono essere solo più restrittive delle politiche di amministrazione. Non possono ignorare la decisione di rifiuto di una politica di amministrazione, ma possono limitare ulteriormente il traffico consentito o approvato dalle politiche di amministrazione.

  3. Politiche di amministrazione di livello base: se nessuna politica di amministrazione o con ambito del namespace corrisponde al traffico, viene valutato il livello di base. ClusterNetworkPolicies Queste forniscono posizioni di sicurezza predefinite che possono essere sostituite da policy con ambito namespace, consentendo agli amministratori di impostare impostazioni predefinite a livello di organizzazione e offrendo al contempo ai team la flessibilità necessaria per personalizzarle in base alle esigenze. Le politiche di base vengono valutate in ordine di priorità (per primo il numero di priorità più basso).

  4. Negazione predefinita (se nessuna policy corrisponde): questo deny-by-default comportamento garantisce che siano consentite solo le connessioni esplicitamente consentite, mantenendo un solido livello di sicurezza.

Applicazione del principio del privilegio minimo

  • Inizia con politiche restrittive e aggiungi gradualmente le autorizzazioni secondo necessità. Inizia implementando le deny-by-default politiche a livello di cluster, quindi aggiungi in modo incrementale le regole di autorizzazione man mano che convalidi i requisiti di connettività legittimi. Questo approccio obbliga i team a giustificare esplicitamente ogni connessione esterna, creando un ambiente più sicuro e verificabile.

  • Verifica e rimuovi regolarmente le regole di policy non utilizzate: le policy di rete possono accumularsi nel tempo man mano che le applicazioni si evolvono, lasciando dietro di sé regole obsolete che ampliano inutilmente la superficie di attacco. Implementate un processo di revisione regolare per identificare e rimuovere le regole di policy che non sono più necessarie, assicurando che il vostro livello di sicurezza rimanga rigoroso e gestibile.

  • Se possibile, utilizza nomi di dominio specifici anziché schemi generici. Se da un lato i modelli wildcard *.amazonaws.com offrono maggiore praticità, dall'altro garantiscono l'accesso a un'ampia gamma di servizi. Ove possibile, specifica nomi di dominio esatti, s3.us-west-2.amazonaws.com ad esempio per limitare l'accesso solo ai servizi specifici richiesti dalle applicazioni, riducendo il rischio di spostamenti laterali se un carico di lavoro è compromesso.

Utilizzo di policy basate su DNS in EKS

  • Le regole basate su DNS definite utilizzando ApplicationNetworkPolicy sono applicabili solo ai carichi di lavoro in esecuzione su istanze lanciate in modalità automatica EKS. EC2 Se si utilizza un cluster in modalità mista (composto da nodi di lavoro EKS Auto e non EKS Auto), le regole basate sul DNS sono efficaci solo nei nodi di lavoro in modalità EKS Auto (istanze gestite). EC2

Convalida delle politiche DNS

  • Utilizzate cluster di staging che rispecchiano la topologia della rete di produzione per i test: l'ambiente di staging deve replicare l'architettura di rete, le dipendenze esterne e i modelli di connettività di produzione per garantire un test accurato delle politiche. Ciò include configurazioni VPC corrispondenti, comportamento di risoluzione DNS e accesso agli stessi servizi esterni richiesti dai carichi di lavoro di produzione.

  • Implementa test automatizzati per percorsi di rete critici: crea test automatizzati che convalidano la connettività ai servizi esterni essenziali come parte della tua pipeline. CI/CD Questi test devono verificare che i flussi di traffico legittimi siano consentiti mentre le connessioni non autorizzate vengono bloccate, in modo da confermare continuamente che le politiche di rete mantengano il corretto livello di sicurezza man mano che l'infrastruttura si evolve.

  • Monitora il comportamento delle applicazioni dopo le modifiche alle policy: dopo aver implementato policy di rete nuove o modificate nella produzione, monitorate attentamente i log delle applicazioni, i tassi di errore e le metriche prestazionali per identificare rapidamente eventuali problemi di connettività. Stabilisci procedure di rollback chiare in modo da poter ripristinare rapidamente le modifiche alle policy se causano comportamenti imprevisti delle applicazioni o interruzioni del servizio.

Interazione con il firewall DNS di Amazon Route 53

Le politiche di amministrazione e di rete di EKS vengono valutate prima a livello di pod quando viene avviato il traffico. Se una policy di rete EKS consente l'uscita verso un dominio specifico, il pod esegue quindi una query DNS che raggiunge il Route 53 Resolver. A questo punto, vengono valutate le regole del firewall DNS Route 53. Se DNS Firewall blocca la query del dominio, la risoluzione DNS fallisce e la connessione non può essere stabilita, anche se la politica di rete EKS lo ha consentito. Ciò crea livelli di sicurezza complementari: le policy di rete basate su EKS DNS forniscono il controllo dell'uscita a livello di pod per i requisiti di accesso specifici delle applicazioni e i limiti di sicurezza multi-tenant, mentre DNS Firewall offre una protezione a livello di VPC contro domini dannosi noti e applica le blocklist a livello di organizzazione.