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

Gruppi di sicurezza per pod

Un gruppo AWS di sicurezza funge da firewall virtuale per consentire alle EC2 istanze di controllare il traffico in entrata e in uscita. Per impostazione predefinita, Amazon VPC CNI utilizzerà i gruppi di sicurezza associati al primario ENI sul nodo. Più specificamente, ogni ENI persona associata all'istanza avrà gli stessi gruppi EC2 di sicurezza. Pertanto, ogni Pod su un nodo condivide gli stessi gruppi di sicurezza del nodo su cui viene eseguito.

Come si vede nell'immagine seguente, tutti i Pod applicativi che operano sui nodi di lavoro avranno accesso al servizio di RDS database (considerando il gruppo di sicurezza dei nodi RDS Inbound Allows). I gruppi di sicurezza sono troppo generici perché si applicano a tutti i Pod in esecuzione su un nodo. I gruppi di sicurezza per Pods forniscono la segmentazione della rete per i carichi di lavoro, che è una parte essenziale di una buona strategia di difesa approfondita.

Con i gruppi di sicurezza per Pods, puoi migliorare l'efficienza di elaborazione eseguendo applicazioni con requisiti di sicurezza di rete diversi su risorse di elaborazione condivise. È possibile definire diversi tipi di regole di sicurezza, ad esempio Pod-to-Pod e Pod-to-External AWS servizi, in un'unica posizione con gruppi di EC2 sicurezza e applicati ai carichi di lavoro con Kubernetes native. APIs L'immagine seguente mostra i gruppi di sicurezza applicati a livello di Pod e come semplificano la distribuzione delle applicazioni e l'architettura dei nodi. Il Pod può ora accedere al RDS database Amazon.

È possibile abilitare i gruppi di sicurezza per i pod ENABLE_POD_ENI=true impostando per. VPC CNI Una volta abilitato, il VPCResource Controller in esecuzione sul piano di controllo (gestito daEKS) crea e collega al nodo un'interfaccia trunk chiamata «`aws-k8 s-trunk-eni «`. L'interfaccia trunk funge da interfaccia di rete standard collegata all'istanza. Per gestire le interfacce trunk, devi aggiungere la policy AmazonEKSVPCResourceController gestita al ruolo del cluster associato al tuo EKS cluster Amazon.

Il controller crea anche interfacce branch denominate «s-branch-eniaws-k8" e le associa all'interfaccia trunk. Ai pod viene assegnato un gruppo di sicurezza utilizzando la risorsa SecurityGroupPolicypersonalizzata e sono associati a un'interfaccia branch. Poiché i gruppi di sicurezza sono specificati con interfacce di rete, ora siamo in grado di pianificare i Pod che richiedono gruppi di sicurezza specifici su queste interfacce di rete aggiuntive. Consulta la sezione della Guida per EKS l'utente sui gruppi di sicurezza per i pod, inclusi i prerequisiti di distribuzione.

La capacità dell'interfaccia Branch si aggiunge ai limiti esistenti del tipo di istanza per gli indirizzi IP secondari. I pod che utilizzano gruppi di sicurezza non vengono presi in considerazione nella formula max-pods e quando si utilizza il gruppo di sicurezza per i pod è necessario considerare l'aumento del valore max-pods o accettare di utilizzare meno pod di quanti il nodo possa effettivamente supportare.

Un m5.large può avere fino a 9 interfacce di rete di filiali e fino a 27 indirizzi IP secondari assegnati alle sue interfacce di rete standard. Come mostrato nell'esempio seguente, il numero massimo di pod predefiniti per un m5.large è 29 e EKS conta i Pod che utilizzano gruppi di sicurezza per raggiungere il numero massimo di Pod. Consulta la guida per l'EKSutente per istruzioni su come modificare i max-pods per i nodi.

Quando i gruppi di sicurezza per Pods vengono utilizzati in combinazione con reti personalizzate, viene utilizzato il gruppo di sicurezza definito nei gruppi di sicurezza per Pods anziché il gruppo di sicurezza specificato in. ENIConfig Di conseguenza, quando la rete personalizzata è abilitata, valuta attentamente l'ordine dei gruppi di sicurezza mentre utilizzi i gruppi di sicurezza per Pod.

Raccomandazioni

Disattiva TCP Early Demux per Liveness Probe

Se si utilizzano sonde Liveness o Readiness, è inoltre necessario disabilitare TCP Early Demux, in modo che il kubelet possa connettersi ai Pods sulle interfacce di rete delle filiali tramite. TCP Questo è richiesto solo in modalità rigorosa. Per fare ciò esegui il seguente comando:

kubectl edit daemonset aws-node -n kube-system

Nella initContainer sezione, modificate il valore DISABLE_TCP_EARLY_DEMUX per true.

Usa Security Group For Pods per sfruttare gli investimenti di AWS configurazione esistenti.

I gruppi di sicurezza semplificano la limitazione dell'accesso di rete a VPC risorse, come RDS database o EC2 istanze. Un chiaro vantaggio dei gruppi di sicurezza per Pod è l'opportunità di riutilizzare le risorse dei gruppi AWS di sicurezza esistenti. Se utilizzi i gruppi di sicurezza come firewall di rete per limitare l'accesso ai tuoi AWS servizi, ti suggeriamo di applicare i gruppi di sicurezza ai Pod utilizzando branch. ENIs Prendi in considerazione l'utilizzo di gruppi di sicurezza per i Pods se trasferisci app da EC2 istanze a EKS e limiti l'accesso ad altri AWS servizi con gruppi di sicurezza.

Configura la modalità Pod Security Group Enforcement

La versione 1.11 del VPC CNI plugin Amazon ha aggiunto una nuova impostazione denominata POD_SECURITY_GROUP_ENFORCING_MODE («enforcing mode»). La modalità di applicazione controlla sia quali gruppi di sicurezza si applicano al pod sia se la fonte NAT è abilitata. È possibile specificare la modalità di applicazione come rigorosa o standard. Strict è l'impostazione predefinita e riflette il comportamento precedente di VPC CNI with ENABLE_POD_ENI set to. true

In modalità rigorosa, vengono applicati solo i gruppi ENI di sicurezza delle filiali. Anche la fonte NAT è disabilitata.

In modalità Standard, vengono applicati i gruppi di sicurezza associati sia al primario ENI che al branch ENI (associato al pod). Il traffico di rete deve essere conforme a entrambi i gruppi di sicurezza.

Modalità di applicazione: utilizza la modalità rigorosa per isolare il traffico di pod e nodi:

Per impostazione predefinita, i gruppi di sicurezza per Pods sono impostati sulla «modalità rigorosa». Usa questa impostazione se devi separare completamente il traffico Pod dal resto del traffico del nodo. In modalità rigorosa, la sorgente NAT viene disattivata in modo da poter utilizzare i gruppi di sicurezza ENI in uscita della filiale.

Modalità di applicazione: utilizza la modalità Standard nelle seguenti situazioni

IP di origine del client visibile ai contenitori nel Pod

Se devi mantenere l'IP di origine del client visibile ai contenitori nel Pod, valuta la possibilità di POD_SECURITY_GROUP_ENFORCING_MODE impostare sustandard. I servizi Kubernetes support externalTrafficPolicy =local per supportare la conservazione dell'IP di origine del client (cluster di tipo predefinito). Ora puoi eseguire servizi Kubernetes di tipo NodePort e LoadBalancer utilizzando destinazioni di istanza con un valore externalTrafficPolicy impostato su Local in modalità standard. Localpreserva l'IP di origine del client ed evita un secondo hop e type Services. LoadBalancer NodePort

Implementazione NodeLocal DNSCache

Quando utilizzi gruppi di sicurezza per i pod, configura la modalità standard per supportare i pod che utilizzano. NodeLocal DNSCache NodeLocal DNSCachemigliora DNS le prestazioni del cluster eseguendo un agente di DNS caching sui nodi del cluster come. DaemonSet Ciò aiuterà i pod che hanno i DNS QPS requisiti più elevati a interrogare Kube-DNS/Core locale DNS con una cache locale, il che migliorerà la latenza.

NodeLocal DNSCachenon è supportato in modalità rigorosa poiché tutto il traffico di rete, anche verso il nodo, entra in. VPC

Supporto della politica di rete Kubernetes

Consigliamo di utilizzare la modalità di applicazione standard quando si utilizzano criteri di rete con Pod a cui sono associati gruppi di sicurezza.

Consigliamo vivamente di utilizzare gruppi di sicurezza per i Pod per limitare l'accesso a livello di rete ai AWS servizi che non fanno parte di un cluster. Prendi in considerazione le politiche di rete per limitare il traffico di rete tra i Pod all'interno di un cluster, spesso noto come traffico est/ovest.

Identifica le incompatibilità con i gruppi di sicurezza per Pod

Le istanze basate su Windows e non nitro non supportano i gruppi di sicurezza per i pod. Per utilizzare i gruppi di sicurezza con i pod, le istanze devono essere contrassegnate con. isTrunkingEnabled Utilizzate le policy di rete per gestire l'accesso tra i Pod anziché i gruppi di sicurezza se i Pod non dipendono da alcun AWS servizio interno o esterno al vostro. VPC

Usa i gruppi di sicurezza per Pod per controllare in modo efficiente il traffico verso i Servizi AWS

Se un'applicazione in esecuzione all'interno del EKS cluster deve comunicare con un'altra risorsa all'internoVPC, ad esempio, di un RDS database, prendi in considerazione l'utilizzo di SGs for pods. Sebbene esistano motori di policy che consentono di specificare uno CIDR o un DNS nome, sono una scelta meno ottimale quando si comunica con AWS servizi che dispongono di endpoint che si trovano all'interno di un. VPC

Al contrario, le policy di rete di Kubernetes forniscono un meccanismo per controllare il traffico in ingresso e in uscita sia all'interno che all'esterno del cluster. Le politiche di rete di Kubernetes devono essere prese in considerazione se l'applicazione ha dipendenze limitate da altri servizi. AWS Puoi configurare politiche di rete che specificano le regole di uscita in base a CIDR intervalli per limitare l'accesso ai AWS servizi anziché alla semantica nativa come. AWS SGs Puoi utilizzare le policy di rete di Kubernetes per controllare il traffico di rete tra i Pod (spesso denominato traffico Est/Ovest) e tra i Pod e i servizi esterni. Le politiche di rete Kubernetes sono implementate ai livelli 3 e 4. OSI

Amazon ti EKS consente di utilizzare motori di policy di rete come Calico e Cilium. Per impostazione predefinita, i motori delle politiche di rete non sono installati. Consulta le rispettive guide all'installazione per istruzioni su come eseguire la configurazione. Per ulteriori informazioni su come utilizzare la politica di rete, consulta Best practice in materia EKS di sicurezza. La funzionalità DNS dei nomi host è disponibile nelle versioni aziendali dei motori di policy di rete e potrebbe essere utile per controllare il traffico tra i Services/Pods di Kubernetes e le risorse che vengono eseguite all'esterno di. AWS Inoltre, puoi prendere in considerazione il supporto dei DNS nomi host per i AWS servizi che per impostazione predefinita non supportano i gruppi di sicurezza.

Tagga un singolo gruppo di sicurezza per utilizzare AWS Loadbalancer Controller

Quando molti gruppi di sicurezza sono assegnati a un Pod, Amazon EKS consiglia di contrassegnare un singolo gruppo di sicurezza come kubernetes.io/cluster/$namecondiviso o di proprietà. Il tag consente al AWS Loadbalancer Controller di aggiornare le regole dei gruppi di sicurezza per indirizzare il traffico verso i Pod. Se a un Pod viene assegnato un solo gruppo di sicurezza, l'assegnazione di un tag è facoltativa. Le autorizzazioni impostate in un gruppo di sicurezza si sommano, pertanto è sufficiente etichettare un singolo gruppo di sicurezza per consentire al controller del loadbalancer di individuare e riconciliare le regole. Inoltre aiuta a rispettare le quote predefinite definite dai gruppi di sicurezza.

Configurazione NAT per il traffico in uscita

NATLa fonte è disattivata per il traffico in uscita proveniente dai Pod a cui sono assegnati gruppi di sicurezza. Per i Pod che utilizzano gruppi di sicurezza che richiedono l'accesso ai nodi Internet, Launch Worker Nodes su sottoreti private configurate con un NAT gateway o un'istanza e abilitabili esternamente in. SNAT CNI

kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true

Distribuisci pod con gruppi di sicurezza su sottoreti private

I pod a cui sono assegnati gruppi di sicurezza devono essere eseguiti su nodi distribuiti su sottoreti private. Tieni presente che i pod con gruppi di sicurezza assegnati distribuiti su sottoreti pubbliche non saranno in grado di accedere a Internet.

Verifica i terminationGracePeriodsecondi nel file delle specifiche del pod

Assicurati che terminationGracePeriodSeconds sia diverso da zero nel file delle specifiche del Pod (impostazione predefinita: 30 secondi). Questo è essenziale per consentire VPC CNI ad Amazon di eliminare la rete Pod dal nodo di lavoro. Se impostato su zero, il CNI plug-in non rimuove la rete Pod dall'host e il ramo non ENI viene ripulito in modo efficace.

Utilizzo dei gruppi di sicurezza per i pod con Fargate

I gruppi di sicurezza per i Pod eseguiti su Fargate funzionano in modo molto simile ai Pod eseguiti EC2 sui nodi di lavoro. Ad esempio, è necessario creare il gruppo di sicurezza prima di SecurityGroupPolicy farvi riferimento nel file associato al Pod Fargate. Per impostazione predefinita, il gruppo di sicurezza del cluster viene assegnato a tutti i Fargate Pod quando non si assegna esplicitamente un Fargate Pod a un Pod Fargate. SecurityGroupPolicy Per semplicità, potresti voler aggiungere il gruppo di sicurezza del cluster a un Fagate Pod, SecurityGroupPolicy altrimenti dovrai aggiungere le regole minime di sicurezza del gruppo al tuo gruppo di sicurezza. È possibile trovare il gruppo di sicurezza del cluster utilizzando describe-cluster. API

 aws eks describe-cluster --name CLUSTER_NAME --query 'cluster.resourcesVpcConfig.clusterSecurityGroupId'

cat >my-fargate-sg-policy.yaml <<EOF
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: my-fargate-sg-policy
  namespace: my-fargate-namespace
spec:
  podSelector:
    matchLabels:
      role: my-fargate-role
  securityGroups:
    groupIds:
      - cluster_security_group_id
      - my_fargate_pod_security_group_id
EOF

Le regole del gruppo di sicurezza minimo sono elencate qui. Queste regole consentono ai Fargate Pod di comunicare con servizi interni al cluster come kube-apiserver, kubelet e Core. DNS È inoltre necessario aggiungere regole per consentire le connessioni in entrata e in uscita da e verso il Fargate Pod. Ciò consentirà al tuo Pod di comunicare con altri Pod o risorse del tuo. VPC Inoltre, è necessario includere regole che consentano a Fargate di recuperare le immagini dei container da Amazon ECR o da altri registri di container come. DockerHub Per ulteriori informazioni, consulta Intervalli di indirizzi AWS IP nel AWS Riferimento generale.

È possibile utilizzare i comandi seguenti per trovare i gruppi di sicurezza applicati a un Pod Fargate.

kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.vpc\.amazonaws\.com/pod-eni}{"\n"}'

Annota il eniId comando precedente.

aws ec2 describe-network-interfaces --network-interface-ids ENI_ID --query 'NetworkInterfaces[*].Groups[*]'

I pod Fargate esistenti devono essere eliminati e ricreati per poter applicare nuovi gruppi di sicurezza. Ad esempio, il comando seguente avvia la distribuzione dell'app di esempio. Per aggiornare pod specifici, puoi modificare lo spazio dei nomi e il nome della distribuzione nel comando seguente.

kubectl rollout restart -n example-ns deployment example-pod

📝 Modifica questa pagina su GitHub