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 su che si trova 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 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 gli endpoint esterni del cluster. EKS Auto Mode supporta diversi tipi di policy 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 porta all'interno del cluster Amazon EKS.

Casi d’uso

DNS-based applicazione

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 completamente 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 prevenire l'accesso non autorizzato dai pod alle risorse o agli endpoint esterni del cluster. Questo meccanismo elimina la necessità di tracciare e consentire manualmente un elenco di indirizzi IP specifici. Proteggendo le risorse con un DNS-based approccio, si ha anche una maggiore flessibilità per aggiornare l'infrastruttura esterna senza dover allentare il livello di sicurezza o modificare le politiche di rete a causa delle modifiche ai server e agli host a monte. È 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 del cluster.

Casi d’uso

Regole amministrative (o con ambito di cluster)

In alcuni casi, come negli scenari multi-tenant, i clienti potrebbero dover applicare uno standard di sicurezza di rete applicabile 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 nel cluster, indipendentemente dal rispettivo namespace. Questi tipi di policy consentono di estendere l'ambito di applicazione delle regole di filtro di rete applicate a livello 3, livello 4 e quando si utilizzano le regole DNS.

Casi d’uso

Nozioni di base

Prerequisiti

Fase 1: abilitare il controller della policy di rete

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

Passaggio 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.

Passaggio 3: modifica della configurazione del Network Policy Agent nella classe Node (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:

Come funziona?

DNS-based politica di rete

Utilizzo dell'Application Network Policy

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

Esempio

Nel cluster EKS Auto Mode è presente un carico di lavoro che deve comunicare con un'applicazione locale che si trova dietro un load balancer 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:
    - ipBlock: { cidr: 10.100.0.10/32 }
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

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

Determinazione dell'indirizzo IP CoreDNS

Affinché l'applicazione risolva il DNS, deve essere autorizzata a comunicare con CoreDNS, che viene eseguito localmente su ogni istanza di EKS Auto Mode. L'indirizzo IP CoreDNS è derivato dall'intervallo Service CIDR configurato per il cluster e rimane fisso per tutta la durata del cluster. È quindi possibile determinarlo una volta e farvi riferimento direttamente nelle politiche di rete.

Politica di rete dell'amministratore (o del cluster)

Utilizzo della Cluster Network Policy

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

Esempio

Nel cluster è presente un'applicazione che si desidera isolare dai carichi di lavoro degli altri tenant. È possibile bloccare esplicitamente il traffico del cluster proveniente da altri namespace per impedire l'accesso di rete al namespace sensibile 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 policy

Le funzionalità delle 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 un sistema di sicurezza di rete efficace per il proprio ambiente.

Applicazione del principio del privilegio minimo

Utilizzo delle policy in EKS DNS-based

Convalida delle politiche DNS

Interazione con il firewall DNS di Amazon Route 53

Le policy di amministrazione e rete di EKS vengono valutate per prime a livello di pod quando viene avviato il traffico. Se una policy di rete EKS consente l'accesso a 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 di Route 53. Se il firewall DNS blocca la query sul dominio, la risoluzione DNS fallisce e la connessione non può essere stabilita, anche se la politica di rete EKS lo consente. Ciò crea livelli di sicurezza complementari: le policy di DNS-based rete EKS forniscono un controllo in uscita a livello di pod per i requisiti di accesso specifici delle applicazioni e i limiti di sicurezza multi-tenant, mentre il firewall DNS fornisce protezione contro i domini dannosi noti e applica le blocklist a livello di organizzazione. VPC-wide