Considerazioni Prerequisiti Configurazione delle policy di rete Demo policy Stars Risoluzione dei problemi Policy di rete Kubernetes

Configurazione del cluster per le policy di rete Kubernetes

Per impostazione predefinita, in Kubernetes non ci sono restrizioni per indirizzi IP, porte o connessioni tra qualsiasi Pods nel cluster o tra i tuoi Pods e le risorse in qualsiasi altra rete. È possibile utilizzare le policy di rete Kubernetes per limitare il traffico di rete da e verso i Pods. Per ulteriori informazioni, consulta la pagina Network Policies nella documentazione di Kubernetes.

Se hai una versione 1.13 o precedente del Amazon VPC CNI plugin for Kubernetes sul cluster, è necessario implementare una soluzione di terze parti per applicare le policy di rete Kubernetes al cluster. Una versione 1.14 o successiva del plugin è in grado di implementare le policy di rete, quindi non è necessario utilizzare una soluzione di terze parti. In questo argomento, imparerai a configurare il cluster per l'utilizzo delle policy di rete Kubernetes sul cluster senza utilizzare componenti aggiuntivi di terze parti.

Le policy di rete nel Amazon VPC CNI plugin for Kubernetes sono supportate nelle seguenti configurazioni.

Cluster Amazon EKS versione 1.25 e successive.
Versione 1.14 o successiva del Amazon VPC CNI plugin for Kubernetes sul cluster.
Cluster configurato per indirizzi IPv4 o IPv6.
È possibile utilizzare le policy di rete con i gruppi di sicurezza per Pods. Con le policy di rete, è possibile controllare tutte le comunicazioni all'interno del cluster. Con i gruppi di sicurezza perPods, puoi controllare l'accesso Servizi AWS alle applicazioni all'interno di unPod.
È possibile utilizzare le policy di rete con le reti personalizzate e la delega del prefisso.

Considerazioni

Quando si applicano le policy di rete Amazon VPC CNI plugin for Kubernetes per il cluster con il Amazon VPC CNI plugin for Kubernetes, è possibile applicare le policy solo ai nodi Amazon EC2 Linux. Non è possibile applicare le policy ai nodi Fargate o Windows.
Se il cluster utilizza attualmente una soluzione di terze parti per la gestione delle policy di rete Kubernetes, è possibile utilizzare le stesse policy con il Amazon VPC CNI plugin for Kubernetes. Tuttavia, è necessario rimuovere la soluzione esistente in modo che non gestisca le stesse policy.
È possibile applicare più policy di rete allo stesso Pod. Quando sono configurate due o più policy che selezionano lo stesso Pod, al Pod vengono applicate tutte le policy.
Il numero massimo di combinazioni univoche di porte per ogni protocollo in ogni ingress: egress: selettore in una politica di rete è 24.
Per ognuno dei servizi Kubernetes, la porta del servizio deve essere uguale a quella del container. Se si utilizzano porte con un nome assegnato, è necessario utilizzare lo stesso nome anche nelle specifiche del servizio.
Applicazione delle policy all'avvio Pod

Il Amazon VPC CNI plugin for Kubernetes configura le policy di rete per i pod parallelamente al provisioning dei pod. Fino a quando tutte le policy non saranno configurate per il nuovo pod, i contenitori nel nuovo pod inizieranno con una policy di autorizzazione predefinita. Questa è chiamata modalità standard. Una politica di autorizzazione predefinita significa che tutto il traffico in entrata e in uscita è consentito da e verso i nuovi pod.

È possibile modificare questa politica di rete predefinita impostando la variabile NETWORK_POLICY_ENFORCING_MODE di ambiente su strict nel aws-node contenitore del CNI VPC. DaemonSet
```
env:
  - name: NETWORK_POLICY_ENFORCING_MODE
    value: "strict"
```
Con la NETWORK_POLICY_ENFORCING_MODE variabile impostata sustrict, i pod che utilizzano il CNI VPC iniziano con una politica di negazione predefinita, quindi vengono configurate le politiche. Questa è chiamata modalità rigorosa. In modalità rigorosa, è necessario disporre di una politica di rete per ogni endpoint a cui i pod devono accedere nel cluster. Tieni presente che questo requisito si applica ai pod. CoreDNS La politica di negazione predefinita non è configurata per i pod con rete host.
La funzionalità di policy di rete crea e richiede una PolicyEndpoint Custom Resource Definition (CRD) denominata policyendpoints.networking.k8s.aws. Gli oggetti PolicyEndpoint della Custom Resource sono gestiti da Amazon EKS. È sconsigliabile modificare o eliminare queste risorse.
Se si eseguono pod che utilizzano le credenziali IAM del ruolo di istanza o si connettono all'IMDS EC2, occorre accertarsi che non siano presenti policy di rete che bloccherebbero l'accesso all'IMDS EC2. Potrebbe essere necessario aggiungere una policy di rete per consentire l'accesso all'IMDS EC2. Per ulteriori informazioni, consulta la pagina Metadati dell'istanza e dati utente nella Guida per l'utente di Amazon EC2 per le istanze Linux.

I pod che utilizzano i ruoli IAM per gli account di servizio non accedono all'IMDS EC2.
L'Amazon VPC CNI plugin for Kubernetes non applica le policy di rete alle interfacce di rete aggiuntive per ogni pod, ma solo all'interfaccia principale per ogni pod (eth0). Ciò influisce sulle seguenti architetture:
- Pod IPv6 con la variabile ENABLE_V4_EGRESS impostata su true. Questa variabile abilita la funzionalità di uscita IPv4 per connettere i pod IPv6 a endpoint IPv4 come quelli esterni al cluster. La funzionalità di uscita IPv4 opera creando un'interfaccia di rete supplementare con un indirizzo IPv4 di loopback locale.
- Quando si utilizzano plugin di rete concatenati come. Multus Poiché questi plugin aggiungono interfacce di rete a ciascun pod, le policy di rete non vengono applicate ai plug-in di rete concatenati.
Per impostazione predefinita, per i parametri la funzionalità di policy di rete utilizza la porta 8162 sul nodo. Inoltre, la funzionalità utilizzava la porta 8163 per le sonde dell'integrità. Se esegui un'altra applicazione sui nodi o all'interno dei pod che deve utilizzare queste porte, l'app non viene eseguita. Nella versione VPC CNI v1.14.1 o successiva, puoi modificare la porta di queste porte nelle seguenti posizioni:
AWS Management Console
Apri la console Amazon EKS all'indirizzo https://console.aws.amazon.com/eks/home#/clusters.

Nel riquadro di navigazione a sinistra, seleziona Cluster, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC.

Seleziona la scheda Componenti aggiuntivi.

Seleziona la casella nella parte superiore destra della casella del componente aggiuntivo e scegli Edit (Modifica).

Nella pagina Configure name of addon (Configura il nome del componente aggiuntivo):

Seleziona una v1.14.0-eksbuild.3 o versione successiva nell'elenco a discesa Versione.

Scegli Impostazioni di configurazione facoltative.

Inserisci la chiave JSON "enableNetworkPolicy": e il valore "true" nei Valori di configurazione. Il testo risultante deve essere un oggetto JSON valido. Se questa chiave e questo valore sono gli unici dati nella casella di testo, racchiudi la chiave e il valore tra parentesi graffe {}.

L'esempio seguente ha la funzionalità delle politiche di rete abilitate, i log delle politiche di rete abilitati, i log delle politiche di rete inviati ad Amazon CloudWatch Logs e le metriche e i probe di salute sono impostati sui numeri di porta predefiniti:

{ "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true", "healthProbeBindAddr": "8163", "metricsBindAddr": "8162" } }
Helm
Se il Amazon VPC CNI plugin for Kubernetes è stato installato attraverso helm, è possibile aggiornare la configurazione per abilitare le porte.

Esegui il seguente comando per modificare le porte. Imposta il numero di porta nel valore, rispettivamente, della chiave nodeAgent.metricsBindAddr o nodeAgent.healthProbeBindAddr.

helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
kubectl
Apri la DaemonSet del aws-node nell'editor.

kubectl edit daemonset -n kube-system aws-node

Sostituisci i numeri di porta negli argomenti del comando seguente nel args: del container aws-network-policy-agent nel manifesto del daemonset aws-node della CNI del VPC.

- args: - --metrics-bind-addr=:8162 - --health-probe-bind-addr=:8163

Prerequisiti

Versione minima del cluster

Un cluster Amazon EKS esistente. Per implementarne uno, consulta Guida introduttiva ad Amazon EKS. Il cluster deve essere Kubernetes versione 1.25 o successiva. Il cluster deve eseguire una delle versioni Kubernetes e della piattaforma elencate nella tabella seguente. Sono supportate anche tutte le versioni di Kubernetes e della piattaforma successive a quelle elencate. È possibile verificare la versione corrente di Kubernetes sostituendo my-cluster nel seguente comando con il nome del cluster e quindi eseguendo il comando modificato:


aws eks describe-cluster
              --name my-cluster --query cluster.version --output
              text

Versione Kubernetes	Versione della piattaforma
`1.27.4`	`eks.5`
`1.26.7`	`eks.6`
`1.25.12`	`eks.7`

Versione minima VPC CNI

Versione 1.14 o successiva del Amazon VPC CNI plugin for Kubernetes sul cluster. È possibile verificare la versione attuale con il seguente comando.
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Se la versione è precedente alla 1.14, consulta la pagina Aggiornamento del componente aggiuntivo di Amazon EKS per eseguire l'aggiornamento alla versione 1.14 o successiva.
Versione minima del kernel Linux

I nodi devono avere una versione del kernel Linux 5.10 o successiva. È possibile verificare la versione del kernel con uname -r. Se utilizzi le versioni più recenti delle AMI Amazon Linux ottimizzate per Amazon EKS, Amazon Linux accelerate ottimizzate per Amazon EKS e Bottlerocket, queste dispongono già della versione del kernel richiesta.

La versione v20231116 o successive delle AMI Amazon Linux accelerate ottimizzate per Amazon EKS dispone della versione del kernel 5.10.

Per configurare il cluster per l'utilizzo delle policy di rete Kubernetes

Installazione del file system BPF

Nota
Se il cluster è una versione 1.27 o successiva, è possibile saltare questo passaggio poiché tutte le AMI Amazon Linux e Bottlerocket ottimizzate per Amazon EKS per 1.27 o versioni successive dispongono già di questa funzionalità.
Per tutte le altre versioni del cluster, se si esegue l'upgrade di Amazon Linux ottimizzato per Amazon EKS alla versione v20230703 o successiva oppure si aggiorna l'AMI Bottlerocket alla versione v1.0.2 o successiva, è possibile saltare questo passaggio.
1. Installa il file system Berkeley Packet Filter (BPF) su ciascuno dei nodi.
```
sudo mount -t bpf bpffs /sys/fs/bpf
```
2. Quindi, aggiungi lo stesso comando ai dati utente nel modello di avvio per i gruppi con dimensionamento automatico Amazon EC2.
Abilitazione della policy di rete nella CNI di VPC
1. Scopri qual è il tipo di componente aggiuntivo attualmente installato sul cluster. A seconda dello strumento con cui hai creato il cluster, al momento potresti non avere il componente aggiuntivo del tipo Amazon EKS installato sul cluster. Sostituisci my-cluster con il nome del cluster.
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query addon.addonVersion --output text
```
  Se viene restituito il numero di versione, sul cluster è installato il componente aggiuntivo del tipo Amazon EKS e non è necessario completare i passaggi rimanenti di questa procedura. Se viene restituito un errore, sul cluster non è installato il componente aggiuntivo del tipo Amazon EKS.
2. - Componenti aggiuntivi di Amazon EKS
    AWS Management Console
    
    Apri la console Amazon EKS all'indirizzo https://console.aws.amazon.com/eks/home#/clusters.
    
    Nel riquadro di navigazione a sinistra, seleziona Cluster, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC.
    
    Seleziona la scheda Componenti aggiuntivi.
    
    Seleziona la casella nella parte superiore destra della casella del componente aggiuntivo e scegli Edit (Modifica).
    
    Nella pagina Configure name of addon (Configura il nome del componente aggiuntivo):
    
    Seleziona una v1.14.0-eksbuild.3 o versione successiva nell'elenco a discesa Versione.
    
    Scegli Impostazioni di configurazione facoltative.
    
    Inserisci la chiave JSON "enableNetworkPolicy": e il valore "true" nei Valori di configurazione. Il testo risultante deve essere un oggetto JSON valido. Se questa chiave e questo valore sono gli unici dati nella casella di testo, racchiudi la chiave e il valore tra parentesi graffe {}. L'esempio seguente mostra che la policy di rete è abilitata:
    
    { "enableNetworkPolicy": "true" }
    
    Lo screenshot seguente mostra un esempio di tale scenario.
    
    AWS CLI
    
    Esegui il comando seguente. AWS CLI Sostituisci my-cluster con il nome del cluster e l'ARN del ruolo IAM con il ruolo che stai utilizzando.
    
    aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \ --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \ --resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
  - Componenti aggiuntivi autogestiti
    Helm
    
    Se il Amazon VPC CNI plugin for Kubernetes è stato installato attraverso helm, è possibile aggiornare la configurazione per abilitare la policy di rete.
    
    Esegui il comando seguente per abilitare la policy di rete.
    
    helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
    
    kubectl
    
    Apri la ConfigMap del amazon-vpc-cni nell'editor.
    
    kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
    
    Aggiungi la seguente riga ai data nella ConfigMap.
    
    enable-network-policy-controller: "true"
    
    Dopo aver aggiunto la riga, la ConfigMap dovrebbe essere simile al seguente esempio.
    
    apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-network-policy-controller: "true"
    
    Apri la DaemonSet del aws-node nell'editor.
    
    kubectl edit daemonset -n kube-system aws-node
    
    Sostituisci il valore false con true nell'argomento del comando --enable-network-policy=false in args: nel container aws-network-policy-agent nel manifesto del daemonset aws-node della CNI di VPC.
    
    - args: - --enable-network-policy=true
Verifica che i pod aws-node siano in esecuzione sul cluster.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
Di seguito viene riportato un output di esempio:
```
aws-node-gmqp7                                          2/2     Running   1 (24h ago)   24h
aws-node-prnsh                                          2/2     Running   1 (24h ago)   24h
```
Se la policy di rete è abilitata, nei pod aws-node sono presenti due container. Nelle versioni precedenti e se le policy di rete sono disabilitate, nei pod aws-node è presente un solo container.

Ora è possibile implementare le policy di rete Kubernetes per il cluster. Per ulteriori informazioni, consulta Policy di rete Kubernetes.

Demo delle policy di rete con Stars

La demo consente di creare un servizio di front-end, di back-end e client sul cluster Amazon EKS. Inoltre, la demo consente di creare un'interfaccia utente grafica di gestione che mostra i percorsi di ingresso e uscita disponibili tra ogni servizio. Ti consigliamo di completare la demo su un cluster su cui non esegui carichi di lavoro di produzione.

Prima di creare eventuali policy di rete, tutti i servizi sono in grado di comunicare in modo bidirezionale. Dopo l'applicazione delle policy di rete, puoi vedere che il client può comunicare solo con il servizio di front-end, mentre il back-end accetta traffico solo dal front-end.

Per eseguire la demo policy Stars

Applica i servizi di front-end, back-end, client e dell'interfaccia utente di gestione:


kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml

Visualizza tutti i Pods nel cluster.


kubectl get pods -A

Di seguito viene riportato un output di esempio:

Nell'output, dovresti vedere i pod negli spazi dei nomi mostrati nel seguente output. I NOMI dei pod e il numero di pod nella colonna READY sono diversi da quelli del seguente output. Non continuare finché non vedi pod con nomi simili e tutti hanno il valore Running nella colonna STATUS.


NAMESPACE         NAME                                       READY   STATUS    RESTARTS   AGE
[...]
client            client-xlffc                               1/1     Running   0          5m19s
[...]
management-ui     management-ui-qrb2g                        1/1     Running   0          5m24s
stars             backend-sz87q                              1/1     Running   0          5m23s
stars             frontend-cscnf                             1/1     Running   0          5m21s
[...]

Per connetterti all'interfaccia utente di gestione, connettiti all'EXTERNAL-IP del servizio in esecuzione sul cluster:
```
kubectl get service/management-ui -n management-ui
```
Apri un browser nella posizione del passaggio precedente. Dovresti visualizzare l'interfaccia utente di gestione seguente. Il nodo C è il servizio client, il nodo F è il servizio front-end e il nodo B è il servizio di back-end. Ogni nodo dispone di accesso di comunicazione completo a tutti gli altri nodi, come indicato dalle righe colorate in grassetto.

Applica la seguente policy di rete nei due spazi dei nomi stars e client per isolare tra loro i servizi:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels: {}

È possibile utilizzare i seguenti comandi per applicare la policy a entrambi gli spazi dei nomi:


kubectl apply -n stars -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml

Aggiorna il tuo browser. Poiché l'interfaccia utente di gestione non può più raggiungere i nodi, essi non vengono visualizzati nell'interfaccia utente.

Applica le seguenti policy di rete per consentire all'interfaccia utente di gestione di accedere ai servizi. Applica questa policy per consentire all'interfaccia utente di:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: allow-ui 
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: management-ui

Applica questa policy per consentire al client di:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: client 
  name: allow-ui 
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: management-ui

È possibile utilizzare i seguenti comandi per applicare la policy a entrambe le policy:


kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml

Aggiorna il tuo browser. L'interfaccia utente di gestione può raggiungere nuovamente i nodi, ma i nodi non sono in grado di comunicare tra loro.

Applicare le seguenti policy di rete per consentire il traffico dal servizio front-end al servizio back-end:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 6379

Aggiorna il tuo browser. Puoi vedere che il front-end può comunicare con il back-end.

Applica la seguente policy di rete per consentire il traffico dal client al servizio di front-end:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      role: frontend 
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: client
      ports:
        - protocol: TCP
          port: 80

Aggiorna il tuo browser. Puoi vedere che il client può comunicare con il servizio di front-end. Il servizio di front-end può ancora comunicare con il servizio di back-end.

(Facoltativo) Al termine della demo, puoi eliminare le relative risorse.


kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml

Anche dopo l'eliminazione delle risorse, sui nodi possono essere presenti endpoint di policy di rete che potrebbero interferire in modo imprevisto con la rete nel cluster. L'unico modo sicuro per rimuovere queste regole è riavviare i nodi o terminare tutti i nodi e riciclarli. Per terminare tutti i nodi, impostare il conteggio desiderato del Gruppo Auto Scaling su 0, quindi eseguire il backup al numero desiderato oppure terminare semplicemente i nodi.

Risoluzione dei problemi relativi alle policy di rete

È possibile risolvere i problemi e analizzare le connessioni di rete che utilizzano le policy di rete leggendo i Log delle policy di rete ed eseguendo gli strumenti dell'SDK eBPF.

Log delle policy di rete

I log di flusso registrano se le connessioni sono consentite o negate da una policy di rete. I log delle policy di rete su ogni nodo includono i log di flusso per ogni pod che dispone di una policy di rete. I log delle policy di rete sono archiviati in /var/log/aws-routed-eni/network-policy-agent.log. Di seguito è riportato un esempio del file network-policy-agent.log:

{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}

I registri delle politiche di rete sono disabilitati per impostazione predefinita. Per abilitare i registri delle politiche di rete, procedi nel seguente modo:

Nota

I log delle policy di rete richiedono 1 vCPU aggiuntiva per aws-network-policy-agent il contenitore nel manifesto del daemonset aws-node VPC CNI.

Componenti aggiuntivi di Amazon EKS

AWS Management Console

Apri la console Amazon EKS all'indirizzo https://console.aws.amazon.com/eks/home#/clusters.
Nel riquadro di navigazione a sinistra, seleziona Cluster, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC.
Seleziona la scheda Componenti aggiuntivi.
Seleziona la casella nella parte superiore destra della casella del componente aggiuntivo e scegli Edit (Modifica).
Nella pagina Configure name of addon (Configura il nome del componente aggiuntivo):
1. Seleziona una v1.14.0-eksbuild.3 o versione successiva nell'elenco a discesa Versione.
2. Scegli Impostazioni di configurazione facoltative.
3. Inserisci la chiave JSON di primo livello "nodeAgent": e il valore, che è un oggetto con una chiave"enablePolicyEventLogs": e un valore di "true" nei Valori di configurazione. Il testo risultante deve essere un oggetto JSON valido. L'esempio seguente mostra i criteri di rete e i registri dei criteri di rete sono abilitati e i registri dei criteri di rete vengono inviati a Logs: CloudWatch
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true"
    }
}
```

Lo screenshot seguente mostra un esempio di tale scenario.

AWS Management Console mostrando il componente aggiuntivo VPC CNI con policy di rete e CloudWatch log nella configurazione opzionale.

AWS CLI

Esegui il comando seguente. AWS CLI Sostituisci my-cluster con il nome del cluster e l'ARN del ruolo IAM con il ruolo che stai utilizzando.


aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
    --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'

Componenti aggiuntivi autogestiti

Invia i log delle policy di rete ad Amazon CloudWatch Logs

Puoi monitorare i log delle politiche di rete utilizzando servizi come Amazon CloudWatch Logs. Puoi utilizzare i seguenti metodi per inviare i log delle politiche di rete a Logs. CloudWatch

Per i cluster EKS, i log delle policy si troveranno in /aws/eks/cluster-name/cluster/, mentre per i cluster K8S autogestiti i log verranno collocati in /aws/k8s-cluster/cluster/.

Invio dei log delle policy di rete con il Amazon VPC CNI plugin for Kubernetes

Se si abilitano le policy di rete, ai pod viene aggiunto un secondo container aws-node per un agente del nodo. Questo agente del nodo può inviare i registri delle politiche di rete a Logs. CloudWatch

Nota

Solo i log delle policy di rete vengono inviati dall'agente del nodo. Gli altri log creati dalla CNI di VPC non sono inclusi.

Prerequisiti

Aggiungi le seguenti autorizzazioni come strofa o policy separata al ruolo IAM che stai utilizzando per la CNI di VPC.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Componenti aggiuntivi di Amazon EKS

AWS Management Console

Apri la console Amazon EKS all'indirizzo https://console.aws.amazon.com/eks/home#/clusters.
Nel riquadro di navigazione a sinistra, seleziona Cluster, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC.
Seleziona la scheda Componenti aggiuntivi.
Seleziona la casella nella parte superiore destra della casella del componente aggiuntivo e scegli Edit (Modifica).
Nella pagina Configure name of addon (Configura il nome del componente aggiuntivo):
1. Seleziona una v1.14.0-eksbuild.3 o versione successiva nell'elenco a discesa Versione.
2. Scegli Impostazioni di configurazione facoltative.
3. Inserisci la chiave JSON di primo livello "nodeAgent": e il valore, che è un oggetto con una chiave"enableCloudWatchLogs": e un valore di "true" nei Valori di configurazione. Il testo risultante deve essere un oggetto JSON valido. L'esempio seguente mostra i criteri di rete e i registri dei criteri di rete sono abilitati e i log vengono inviati a Logs: CloudWatch
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true",
        "enableCloudWatchLogs": "true",
    }
}
```

Lo screenshot seguente mostra un esempio di tale scenario.

AWS CLI

Esegui il comando seguente. AWS CLI Sostituisci my-cluster con il nome del cluster e l'ARN del ruolo IAM con il ruolo che stai utilizzando.


aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
    --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'

Componenti aggiuntivi autogestiti

Invio dei log delle policy di rete con un daemonset Fluent Bit

Se stai utilizzando Fluent Bit in un daemonset per inviare i log dai nodi, è possibile aggiungere una configurazione che includa i log delle policy di rete provenienti dalle policy di rete. È possibile utilizzare la configurazione di esempio seguente:


    [INPUT]
        Name              tail
        Tag               eksnp.*
        Path              /var/log/aws-routed-eni/network-policy-agent*.log
        Parser            json
        DB                /var/log/aws-routed-eni/flb_npagent.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Refresh_Interval  10

SDK eBPF incluso

Il Amazon VPC CNI plugin for Kubernetes installa la raccolta di strumenti dell'SDK eBPF sui nodi. È possibile utilizzare gli strumenti dell'SDK eBPF per identificare i problemi relativi alle policy di rete. Ad esempio, il comando seguente elenca i programmi in esecuzione sul nodo.


sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Per eseguire questo comando, è possibile utilizzare qualsiasi metodo di connessione al nodo.

Policy di rete Kubernetes

Per implementare le policy di rete Kubernetes, è necessario creare oggetti NetworkPolicy di Kubernetes e implementarli nel cluster. Gli oggetti NetworkPolicy sono riconducibili a uno spazio dei nomi. Le policy vengono implementate per consentire o negare il traffico tra Pods in base a selettori di etichette, spazi dei nomi e intervalli di indirizzi IP. Per ulteriori informazioni sulla creazione di oggetti NetworkPolicy, consulta la pagina Network Policies nella documentazione di Kubernetes.

L'applicazione di oggetti Kubernetes NetworkPolicy viene implementata con l'Extended Berkeley Packet Filter (eBPF). Relativo alle implementazioni basate su iptables, offre caratteristiche di latenza e prestazioni inferiori, tra cui un utilizzo ridotto della CPU e l'evitamento delle ricerche sequenziali. Inoltre, le sonde eBPF forniscono l'accesso a dati contestuali che aiutano a eseguire il debug di problemi complessi a livello di kernel e a migliorare l'osservabilità. Amazon EKS supporta un esportatore eBPF basato su dati che sfrutta le sonde per registrare i risultati delle policy su ogni nodo ed esportare i dati in raccoglitori di log esterni per facilitare il debug. Per ulteriori informazioni, consulta la documentazione relativa ad eBPF.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

SNAT

Rete personalizzata

Configurazione del cluster per le policy di rete Kubernetes

Considerazioni

Applicazione delle policy all'avvio Pod

Prerequisiti

Versione minima del cluster

Versione minima VPC CNI

Versione minima del kernel Linux

Per configurare il cluster per l'utilizzo delle policy di rete Kubernetes

Installazione del file system BPF

Nota

Abilitazione della policy di rete nella CNI di VPC

Demo delle policy di rete con Stars

Per eseguire la demo policy Stars

Risoluzione dei problemi relativi alle policy di rete

Log delle policy di rete

Nota

Componenti aggiuntivi di Amazon EKS

Componenti aggiuntivi autogestiti

Invia i log delle policy di rete ad Amazon CloudWatch Logs

Invio dei log delle policy di rete con il Amazon VPC CNI plugin for Kubernetes

Nota

Prerequisiti

Componenti aggiuntivi di Amazon EKS

Componenti aggiuntivi autogestiti

Invio dei log delle policy di rete con un daemonset Fluent Bit

SDK eBPF incluso

Policy di rete Kubernetes