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 di sicurezza AWS funge da firewall virtuale per le istanze EC2 per controllare il traffico in entrata e in uscita. Per impostazione predefinita, Amazon VPC CNI utilizzerà i gruppi di sicurezza associati all'ENI primario sul nodo. Più specificamente, ogni ENI associato all'istanza avrà gli stessi gruppi di sicurezza EC2. Pertanto, ogni Pod su un nodo condivide gli stessi gruppi di sicurezza del nodo su cui viene eseguito.

Come mostrato nell'immagine seguente, tutti i Pod applicativi che operano sui nodi di lavoro avranno accesso al servizio di database RDS (considerando che RDS in ingresso consente il gruppo di sicurezza del nodo). 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, una parte essenziale di una buona strategia di difesa approfondita.

Con i gruppi di sicurezza per Pods, è possibile migliorare l'efficienza di elaborazione eseguendo applicazioni con diversi requisiti di sicurezza di rete su risorse di elaborazione condivise. Diversi tipi di regole di sicurezza, come Pod-to-Pod i servizi Pod-to-External AWS, possono essere definiti in un unico posto con i gruppi di sicurezza EC2 e applicati ai carichi di lavoro con le API native di Kubernetes. 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 database Amazon RDS.

È possibile abilitare i gruppi di sicurezza per i pod ENABLE_POD_ENI=true impostando VPC CNI. Una volta abilitato, il VPC Resource Controller in esecuzione sul piano di controllo (gestito da EKS) crea e collega un'interfaccia trunk chiamata «`aws-k8s-trunk-eni"` al nodo. 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 cluster Amazon EKS.

Il controller crea anche interfacce di filiale denominate «aws-k8s-branch-eni» e le associa all'interfaccia trunk. Ai pod viene assegnato un gruppo di sicurezza utilizzando la risorsa personalizzata e sono associati a un'interfaccia di filiale SecurityGroupPolicy. 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 l'utente di EKS sui gruppi di sicurezza per pod, inclusi i prerequisiti di implementazione.

La capacità dell'interfaccia di filiale si aggiunge ai limiti di tipo di istanza esistenti per gli indirizzi IP secondari. I pod che utilizzano i gruppi di sicurezza non sono inclusi nella formula max-pods e quando si utilizza il gruppo di sicurezza per i pod è necessario considerare di aumentare il valore max-pods o accettare l'utilizzo di un numero di pod inferiore a quello effettivamente supportato dal nodo.

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 ed EKS conta i Pod che utilizzano i gruppi di sicurezza nel conteggio del numero massimo di Pod. Consulta la guida per l'utente di EKS per istruzioni su come modificare il numero massimo di pod 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 utilizzando i gruppi di sicurezza per Pod.

Raccomandazioni

Disattiva TCP Early Demux per Liveness Probe

Se utilizzi le sonde Liveness o Readiness, devi anche 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, modifica il valore DISABLE_TCP_EARLY_DEMUX per true.

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

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

Configura la modalità Pod Security Group Enforcing

La versione 1.11 del plugin Amazon VPC CNI ha aggiunto una nuova impostazione denominata POD_SECURITY_GROUP_ENFORCING_MODE («modalità di applicazione»). La modalità di applicazione controlla sia quali gruppi di sicurezza si applicano al pod sia se il NAT di origine è abilitato. È possibile specificare la modalità di applicazione come rigorosa o standard. L'impostazione predefinita è Strict, che riflette il comportamento precedente del VPC CNI impostato su. ENABLE_POD_ENI true

In modalità rigorosa, vengono applicati solo i gruppi di sicurezza ENI delle filiali. Anche il NAT di origine è disabilitato.

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

Modalità di applicazione: utilizza la modalità Strict 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, il NAT di origine è disattivato in modo da poter utilizzare i gruppi di sicurezza in uscita ENI della filiale.

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

IP di origine del client visibile ai contenitori nel Pod

Se hai bisogno di 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 supportano external TrafficPolicy =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 utilizzare destinazioni di istanza con un TrafficPolicy set esterno su Local in modalità standard. Localpreserva l'IP di origine del client ed evita un secondo hop for and type Services. LoadBalancer NodePort

Implementazione di DNSCache NodeLocal

Quando utilizzi i gruppi di sicurezza per i pod, configura la modalità standard per supportare i pod che utilizzano DNSCache. NodeLocal NodeLocal DNSCache migliora le prestazioni DNS del cluster eseguendo un agente di caching DNS sui nodi del cluster come. DaemonSet Questo aiuterà i pod con i requisiti DNS QPS più elevati a interrogare un kube locale, dotato di una cache locale, dns/CoreDNS migliorando così la latenza.

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

Supporto della politica di rete Kubernetes

Ti consigliamo di utilizzare la modalità di applicazione standard quando utilizzi la politica di rete con pod a cui sono associati gruppi di sicurezza.

Consigliamo vivamente di utilizzare i gruppi di sicurezza per i Pods per limitare l'accesso a livello di rete ai servizi AWS 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. East/West

Identifica le incompatibilità con i gruppi di sicurezza per pod

Windows-based e le istanze non nitro non supportano i gruppi di sicurezza per i pod. Per utilizzare i gruppi di sicurezza con Pods, le istanze devono essere contrassegnate con is. TrunkingEnabled Utilizza le policy di rete per gestire l'accesso tra Pods anziché tra gruppi di sicurezza se i Pods non dipendono da alcun servizio AWS all'interno o all'esterno del tuo 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 cluster EKS deve comunicare con un'altra risorsa all'interno del VPC, ad esempio un database RDS, valuta la possibilità di utilizzare SGs per i pod. Sebbene esistano motori di policy che consentono di specificare un CIDR o un nome DNS, rappresentano una scelta meno ottimale quando si comunica con servizi AWS con endpoint che risiedono all'interno di un VPC.

Al contrario, le policy di rete 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 Kubernetes devono essere prese in considerazione se l'applicazione ha dipendenze limitate da altri servizi AWS. È possibile configurare politiche di rete che specificano regole di uscita basate su intervalli CIDR per limitare l'accesso ai servizi AWS rispetto alla semantica nativa di AWS come gli SG. Puoi utilizzare le policy di rete Kubernetes per controllare il traffico di rete tra Pod (spesso definito traffico) e tra Pod e servizi esterni. East/West Le politiche di rete Kubernetes sono implementate ai livelli OSI 3 e 4.

Amazon EKS consente di utilizzare motori di policy di rete come https://projectcalico.docs.tigera.io/getting-started/kubernetes/managed-public-cloud/eks Calico e Cilium. https://docs.cilium.io/en/stable/intro/ 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 le best practice di EKS Security. La funzionalità DNS hostnames è disponibile nelle versioni aziendali dei motori di policy di rete, che potrebbero essere utili per controllare il traffico tra Kubernetes Services/Pods e le risorse che vengono eseguite all'esterno di AWS. Inoltre, puoi prendere in considerazione il supporto dei nomi host DNS per i servizi AWS che non supportano i gruppi di sicurezza per impostazione predefinita.

Contrassegna un singolo gruppo di sicurezza per utilizzare AWS Loadbalancer Controller

Quando molti gruppi di sicurezza sono allocati a un pod, Amazon EKS consiglia di contrassegnare un singolo gruppo di sicurezza con «condiviso» o «di proprietà». kubernetes.io/cluster/$name Il tag consente all'AWS Loadbalancer Controller di aggiornare le regole dei gruppi di sicurezza per indirizzare il traffico verso i Pod. Se viene assegnato un solo gruppo di sicurezza a un pod, l'assegnazione di un tag è facoltativa. Le autorizzazioni impostate in un gruppo di sicurezza sono aggiuntive, pertanto l'etichettatura di un singolo gruppo di sicurezza è sufficiente per consentire al controller del loadbalancer di individuare e riconciliare le regole. Inoltre, aiuta a rispettare le quote predefinite definite dai gruppi di sicurezza. https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-security-groups

Configura NAT per il traffico in uscita

Il NAT di origine è disabilitato per il traffico in uscita dai pod a cui sono assegnati gruppi di sicurezza. Per i Pod che utilizzano gruppi di sicurezza che richiedono l'accesso a Internet, avvia i nodi worker su sottoreti private configurate con un gateway o un'istanza NAT e abilita lo SNAT esterno nel CNI. https://docs.aws.amazon.com/eks/latest/userguide/external-snat.html

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 cessazione GracePeriodSeconds nel file delle specifiche del Pod

Assicurati che terminationGracePeriodSeconds sia diverso da zero nel file delle specifiche del tuo Pod (impostazione predefinita 30 secondi). Questo è essenziale affinché Amazon VPC CNI elimini la rete Pod dal nodo di lavoro. Se impostato su zero, il plug-in CNI non rimuove la rete Pod dall'host e la filiale ENI non viene ripulita efficacemente.

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 che funzionano sui nodi di lavoro EC2. Ad esempio, devi creare il gruppo di sicurezza prima di fare riferimento ad esso nel tuo Fargate Pod che associ al tuo SecurityGroupPolicy Fargate Pod. Per impostazione predefinita, il gruppo di sicurezza del cluster viene assegnato a tutti i Fargate Pod quando non si assegna esplicitamente a un Fargate Pod. SecurityGroupPolicy Per semplicità, potresti voler aggiungere il gruppo di sicurezza del cluster a un Fagate Pod, SecurityGroupPolicy altrimenti dovrai aggiungere le regole minime del gruppo di sicurezza al tuo gruppo di sicurezza. Puoi trovare il gruppo di sicurezza del cluster utilizzando l'API describe-cluster.

 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 minime del gruppo di sicurezza sono elencate qui. https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html Queste regole consentono a Fargate Pods di comunicare con servizi in-cluster come kube-apiserver, kubelet e CoreDNS. È 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 nel tuo VPC. Inoltre, devi includere regole per consentire a Fargate di estrarre le immagini dei container da Amazon ECR o da altri registri di container, ad esempio. DockerHub Per ulteriori informazioni, consulta gli intervalli di indirizzi IP di AWS nell'AWS General Reference.

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

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

Annota il comando eniID riportato sopra.

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 example-app. 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