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

Sicurezza di rete

La sicurezza di rete ha diverse sfaccettature. Il primo riguarda l'applicazione di regole che limitano il flusso di traffico di rete tra i servizi. Il secondo riguarda la crittografia del traffico mentre è in transito. I meccanismi per implementare queste misure di sicurezza su EKS sono vari ma spesso includono i seguenti elementi:

Controllo del traffico

Crittografia di rete

Politica di rete

All'interno di un cluster Kubernetes, tutte le comunicazioni da Pod a Pod sono consentite per impostazione predefinita. Sebbene questa flessibilità possa contribuire a promuovere la sperimentazione, non è considerata sicura. Le policy di rete Kubernetes offrono un meccanismo per limitare il traffico di rete tra Pod (spesso definito East/West traffico) e tra Pod e servizi esterni. Le policy di rete Kubernetes operano ai livelli 3 e 4 del modello OSI. Le policy di rete utilizzano pod, selettori di namespace ed etichette per identificare i pod di origine e destinazione, ma possono anche includere indirizzi IP, numeri di porta, protocolli o una combinazione di questi. Le policy di rete possono essere applicate sia alle connessioni in entrata che in uscita al pod, spesso denominate regole di ingresso e uscita.

Con il supporto nativo delle policy di rete del plugin Amazon VPC CNI, puoi implementare policy di rete per proteggere il traffico di rete nei cluster kubernetes. Questo si integra con l'API Kubernetes Network Policy upstream, garantendo la compatibilità e l'aderenza agli standard Kubernetes. È possibile definire le policy utilizzando diversi identificatori supportati dall'API upstream. Per impostazione predefinita, tutto il traffico in ingresso e in uscita è consentito verso un pod. Quando viene specificata una policy di rete con un PolicyType Ingress, solo le connessioni consentite nel pod sono quelle dal nodo del pod e quelle consentite dalle regole di ingresso. Lo stesso vale per le regole di uscita. Se vengono definite più regole, al momento di prendere la decisione viene presa in considerazione l'unione di tutte le regole. Pertanto, l'ordine di valutazione non influisce sul risultato della politica.

Raccomandazioni

Guida introduttiva alle politiche di rete: segui il principio del privilegio minimo

Crea una politica di rifiuto predefinita

Come per le politiche RBAC, si consiglia di seguire i principi di accesso meno privilegiati nelle politiche di rete. Inizia creando una policy Deny all che limiti tutto il traffico in entrata e in uscita all'interno di un namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

rifiuto per default

Crea una regola per consentire le interrogazioni DNS

Una volta impostata la regola predefinita «nega tutto», puoi iniziare a sovrapporre regole aggiuntive, ad esempio una regola che consente ai pod di interrogare CoreDNS per la risoluzione dei nomi.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-access
  namespace: default
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

allow-dns-access

Aggiungi in modo incrementale regole per consentire selettivamente il flusso di traffico tra namespaces/pods

Comprendi i requisiti dell'applicazione e crea regole di ingresso e uscita dettagliate, se necessario. L'esempio seguente mostra come limitare il traffico in ingresso sulla porta 80 da e verso. app-one client-one Questo aiuta a minimizzare la superficie di attacco e riduce il rischio di accessi non autorizzati.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-app-one
  namespace: default
spec:
  podSelector:
    matchLabels:
      k8s-app: app-one
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          k8s-app: client-one
    ports:
    - protocol: TCP
      port: 80

allow-ingress-app-one

Monitoraggio dell'applicazione delle politiche di rete

package kubernetes.admission
import data.kubernetes.networkpolicies

deny[msg] {
    input.request.kind.kind == "Pod"
    pod_label_value := {v["k8s-app"] | v := input.request.object.metadata.labels}
    contains_label(pod_label_value, "sample-app")
    np_label_value := {v["k8s-app"] | v := networkpolicies[_].spec.podSelector.matchLabels}
    not contains_label(np_label_value, "sample-app")
    msg:= sprintf("The Pod %v could not be created because it is missing an associated Network Policy.", [input.request.object.metadata.name])
}
contains_label(arr, val) {
    arr[_] == val
}

Risoluzione dei problemi

Monitora i log di vpc-network-policy-controller, node-agent

Abilita i registri del controller del piano di controllo EKS per diagnosticare la funzionalità delle politiche di rete. È possibile trasmettere i log del piano di controllo a un gruppo di CloudWatch log e utilizzare CloudWatch Log insights per eseguire query avanzate. Dai log, puoi visualizzare quali oggetti endpoint del pod sono stati risolti in una policy di rete, lo stato di riconciliazione delle policy ed eseguire il debug se la policy funziona come previsto.

Inoltre, Amazon VPC CNI consente di abilitare la raccolta e l'esportazione dei log di applicazione delle policy in Amazon Cloudwatch dai nodi di lavoro EKS. Una volta abilitato, puoi sfruttare CloudWatch Container Insights per fornire informazioni sull'utilizzo relativo alle politiche di rete.

Amazon VPC CNI fornisce anche un SDK che fornisce un'interfaccia per interagire con i programmi eBPF sul nodo. L'SDK viene installato quando aws-node viene distribuito sui nodi. Puoi trovare il binario SDK installato /opt/cni/bin nella directory del nodo. Al momento del lancio, l'SDK fornisce supporto per funzionalità fondamentali come l'ispezione di programmi e mappe eBPF.

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

Registra i metadati del traffico di rete

AWS VPC Flow Logs acquisisce i metadati sul traffico che fluisce attraverso un VPC, come l'indirizzo IP e la porta di origine e di destinazione insieme ai pacchetti. accepted/dropped Queste informazioni potrebbero essere analizzate per individuare attività sospette o insolite tra le risorse all'interno del VPC, inclusi i Pods. Tuttavia, poiché gli indirizzi IP dei pod cambiano spesso man mano che vengono sostituiti, i Flow Logs potrebbero non essere sufficienti da soli. Calico Enterprise estende i Flow Logs con etichette per i pod e altri metadati, facilitando la decifrazione dei flussi di traffico tra i pod.

Gruppi di sicurezza

EKS utilizza AWS VPC Security Groups (SGs) per controllare il traffico tra il piano di controllo di Kubernetes e i nodi di lavoro del cluster. I gruppi di sicurezza vengono utilizzati anche per controllare il traffico tra i nodi di lavoro e altre risorse VPC e indirizzi IP esterni. Quando esegui il provisioning di un cluster EKS (con Kubernetes versione 1.14-eks.3 o successiva), viene creato automaticamente un gruppo di sicurezza del cluster. Questo gruppo di sicurezza consente una comunicazione senza restrizioni tra il piano di controllo EKS e i nodi dei gruppi di nodi gestiti. Per semplicità, si consiglia di aggiungere il cluster SG a tutti i gruppi di nodi, inclusi i gruppi di nodi non gestiti.

Prima della versione 1.14 di Kubernetes e della versione EKS eks.3, erano configurati gruppi di sicurezza separati per il piano di controllo EKS e i gruppi di nodi. Le regole minime e suggerite per i gruppi di sicurezza del piano di controllo e del gruppo di nodi sono disponibili in Le regole minime per https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html. il gruppo di sicurezza del piano di controllo consentono l'ingresso della porta 443 dal nodo di lavoro SG. Questa regola è ciò che consente ai kubelet di comunicare con il server API Kubernetes. Include anche la porta 10250 per il traffico in uscita verso il nodo di lavoro SG; 10250 è la porta su cui i kubelets sono in ascolto. Analogamente, le regole del gruppo minimo di nodi consentono l'ingresso della porta 10250 dal piano di controllo SG e la porta 443 in uscita dal piano di controllo SG. Infine, esiste una regola che consente la comunicazione senza restrizioni tra i nodi all'interno di un gruppo di nodi.

Se hai bisogno di controllare la comunicazione tra i servizi eseguiti all'interno del cluster e i servizi eseguiti all'esterno del cluster, ad esempio un database RDS, prendi in considerazione i gruppi di sicurezza per i pod. Con i gruppi di sicurezza per i pod, puoi assegnare un gruppo di sicurezza esistente a una raccolta di pod.

Puoi controllare quali pod vengono assegnati a un gruppo di sicurezza creando un SecurityGroupPolicy oggetto e specificando un o un. PodSelector ServiceAccountSelector Impostando i selettori su, gli SG a cui si fa riferimento in {} verranno assegnati SecurityGroupPolicy a tutti i pod in un namespace o a tutti gli account di servizio in un namespace. Assicuratevi di aver preso confidenza con tutte le considerazioni prima di implementare i gruppi di sicurezza per i pod. https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html#security-groups-pods-considerations

Sebbene i gruppi di sicurezza per pod offrano un AWS-native modo per controllare il traffico di rete all'interno e all'esterno del cluster senza il sovraccarico di un demone di policy, sono disponibili altre opzioni. Ad esempio, il motore di policy Cilium consente di fare riferimento a un nome DNS in una policy di rete. Calico Enterprise include un'opzione per mappare le politiche di rete ai gruppi di sicurezza AWS. Se hai implementato un service mesh come Istio, puoi utilizzare un gateway di uscita per limitare l'uscita di rete a domini o indirizzi IP specifici e completamente qualificati. Per ulteriori informazioni su questa opzione, leggi la serie in tre parti sul controllo del traffico in uscita in Istio.

Quando utilizzare Network Policy vs Security Group for Pods?

Quando utilizzare la politica di rete Kubernetes

Quando usare i gruppi di sicurezza AWS per pod (SGP)

Procedure consigliate che utilizzano i gruppi di sicurezza per i pod e le politiche di rete

Quando si tratta di sicurezza di rete, un approccio a più livelli è spesso la soluzione più efficace. L'utilizzo combinato delle policy di rete di Kubernetes e dell'SGP può fornire una solida strategia di difesa approfondita per le applicazioni in esecuzione in EKS.

Service Mesh Policy Enforcement o policy di rete Kubernetes

A service mesh è un livello di infrastruttura dedicato che puoi aggiungere alle tue applicazioni. Ti consente di aggiungere in modo trasparente funzionalità come osservabilità, gestione del traffico e sicurezza, senza aggiungerle al tuo codice.

Il service mesh applica le politiche al livello 7 (applicazione) del modello OSI, mentre le politiche di rete kubernetes operano al livello 3 (rete) e al livello 4 (trasporto). Ci sono molte offerte in questo spazio come AWSAppMesh, Istio, Linkerd, ecc.,

Quando utilizzare Service mesh per l'applicazione delle policy

Scegli la policy di rete Kubernetes per casi d'uso più semplici

ThirdParty Motori per le politiche di rete

Prendi in considerazione un Network Policy Engine di terze parti quando hai requisiti di policy avanzati come Global Network Policies, supporto per regole basate su nomi host DNS, regole Layer 7, regole ServiceAccount basate e deny/log azioni esplicite, ecc., Calico è un motore di policy open source di Tigera che funziona bene con EKS. Oltre a implementare il set completo di funzionalità delle policy di rete Kubernetes, Calico supporta policy di rete estese con una serie più ricca di funzionalità, incluso il supporto per le regole di livello 7, ad esempio HTTP, se integrate con Istio. Le policy di Calico possono essere suddivise in namespace, pod, account di servizio o a livello globale. Quando le policy rientrano nell'ambito di un account di servizio, associa una serie di regole a quell'account di servizio. ingress/egress Con le regole RBAC appropriate, è possibile impedire ai team di sovrascrivere queste regole, consentendo ai professionisti della sicurezza IT di delegare in modo sicuro l'amministrazione dei namespace. Isovalent, i manutentori di Cilium, hanno inoltre esteso le politiche di rete per includere il supporto parziale per le regole di livello 7, ad esempio HTTP. Cilium supporta anche i nomi host DNS, che possono essere utili per limitare il traffico tra Services/Pods Kubernetes e le risorse che vengono eseguite all'interno o all'esterno del VPC. Al contrario, Calico Enterprise include una funzionalità che consente di mappare una policy di rete Kubernetes a un gruppo di sicurezza AWS, nonché i nomi host DNS.

Puoi trovare un elenco delle politiche di rete Kubernetes comuni all'indirizzo. https://github.com/ahmetb/kubernetes-network-policy-recipes. Un set di regole simile per Calico è disponibile all'indirizzo https://docs.projectcalico.org/security/calico-network-policy.

Migrazione ad Amazon VPC CNI Network Policy Engine

Per mantenere la coerenza ed evitare comportamenti imprevisti di comunicazione tra pod, si consiglia di implementare un solo Network Policy Engine nel cluster. Se desideri migrare da 3P a VPC CNI Network Policy Engine, ti consigliamo di convertire i NetworkPolicy CRD 3P esistenti nelle risorse NetworkPolicy Kubernetes prima di abilitare il supporto per le policy di rete VPC CNI. Inoltre, testa le policy migrate in un cluster di test separato prima di applicarle nel tuo ambiente di produzione. Ciò consente di identificare e risolvere eventuali problemi o incongruenze nel comportamento di comunicazione del pod.

Strumento di migrazione

Per assisterti nel processo di migrazione, abbiamo sviluppato uno strumento chiamato K8s Network Policy Migrator che converte i CRD con le policy di Calico/Cilium rete esistenti in policy di rete native di Kubernetes. Dopo la conversione, puoi testare direttamente le politiche di rete convertite sui tuoi nuovi cluster che eseguono il controller delle politiche di rete VPC CNI. Lo strumento è progettato per aiutarti a semplificare il processo di migrazione e garantire una transizione senza intoppi.

Tieni presente che lo strumento di migrazione non è attualmente supportato dal team di ingegneri delle politiche di rete di AWS VPC CNI, ma viene messo a disposizione dei clienti nel migliore dei modi. Ti invitiamo a utilizzare questo strumento per facilitare il processo di migrazione. Nel caso in cui dovessi riscontrare problemi o bug con lo strumento, ti chiediamo gentilmente di creare un GitHub problema. Il tuo feedback è prezioso per noi e ci aiuterà a migliorare continuamente i nostri servizi.

Risorse aggiuntive

Crittografia dei dati in transito

Le applicazioni che devono essere conformi a PCI, HIPAA o ad altre normative potrebbero dover crittografare i dati mentre sono in transito. Al giorno d'oggi TLS è di fatto la scelta per crittografare il traffico via cavo. TLS, come il suo predecessore SSL, fornisce comunicazioni sicure su una rete utilizzando protocolli crittografici. TLS utilizza la crittografia simmetrica in cui le chiavi per crittografare i dati vengono generate in base a un segreto condiviso negoziato all'inizio della sessione. Di seguito sono riportati alcuni modi per crittografare i dati in un ambiente Kubernetes.

Istanze Nitro

Il traffico scambiato tra i seguenti tipi di istanze Nitro, ad esempio C5n, G4, I3en, M5dn, M5n, P3dn, R5dn e R5n, viene crittografato automaticamente per impostazione predefinita. Quando è presente un hop intermedio, come un gateway di transito o un load balancer, il traffico non è crittografato. Vedi Encryption in transit per ulteriori dettagli sulla crittografia in transito e per l'elenco completo dei tipi di istanze che supportano la crittografia di rete per impostazione predefinita.

Service Mesh

La crittografia in transito può essere implementata anche con una service mesh come App Mesh, Linkerd v2 e Istio. AppMesh supporta MTL con X.509 certificati o Envoy's Secret Discovery Service (SDS). Linkerd e Istio supportano entrambi gli MTL.

Il GitHub repository aws-app-mesh-examples fornisce procedure dettagliate per configurare MTL utilizzando certificati e SPIRE come provider SDS con il contenitore Envoy: X.509

App Mesh supporta anche la crittografia TLS con un certificato privato rilasciato da AWS Certificate Manager (ACM) o un certificato archiviato nel file system locale del nodo virtuale.

Il GitHub repository aws-app-mesh-examples fornisce procedure dettagliate per configurare TLS utilizzando certificati emessi da ACM e certificati inclusi nel contenitore Envoy:

Controller di ingresso e sistemi di bilanciamento del carico

I controller di ingresso consentono di indirizzare in modo intelligente il HTTP/S traffico proveniente dall'esterno del cluster verso i servizi in esecuzione all'interno del cluster. Spesso, questi Ingress sono preceduti da un sistema di bilanciamento del carico di livello 4, come il Classic Load Balancer o il Network Load Balancer (NLB). Il traffico crittografato può essere interrotto in diversi punti della rete, ad esempio presso il load balancer, la risorsa di ingresso o il Pod. Le modalità e i luoghi di interruzione della connessione SSL dipenderanno in ultima analisi dalla politica di sicurezza della rete dell'organizzazione. Ad esempio, se hai una politica che richiede la crittografia end-to-end, dovrai decrittografare il traffico sul Pod. Ciò comporterà un onere aggiuntivo per il tuo Pod, che dovrà impiegare cicli per stabilire la stretta di mano iniziale. L' SSL/TLS elaborazione complessiva richiede un uso intensivo della CPU. Di conseguenza, se hai la flessibilità, prova a eseguire l'offload SSL su Ingress o sul load balancer.

Usa la crittografia con i sistemi di bilanciamento del carico AWS Elastic

AWS Application Load Balancer (ALB) e Network Load Balancer (NLB) supportano entrambi la crittografia dei trasporti (SSL e TLS). L'alb.ingress.kubernetes.io/certificate-arnannotazione per l'ALB consente di specificare quali certificati aggiungere all'ALB. Se ometti l'annotazione, il controller tenterà di aggiungere i certificati ai listener che la richiedono abbinando i certificati AWS Certificate Manager (ACM) disponibili utilizzando il campo host. A partire da EKS v1.15 è possibile utilizzare l'service.beta.kubernetes.io/aws-load-balancer-ssl-certannotazione con l'NLB come mostrato nell'esempio seguente.

apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: default
  labels:
    app: demo-app
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<certificate ARN>"
     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 80
    protocol: TCP
  selector:
    app: demo-app
//---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
  namespace: default
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 443
              protocol: TCP
            - containerPort: 80
              protocol: TCP

Di seguito sono riportati ulteriori esempi di terminazione. SSL/TLS

CA privata ACM con cert-manager

Puoi abilitare TLS e MTLS per proteggere i carichi di lavoro delle tue applicazioni EKS in ingresso, sul pod e tra i pod utilizzando ACM Private Certificate Authority (CA) e cert-manager, un popolare componente aggiuntivo di Kubernetes per distribuire, rinnovare e revocare i certificati. ACM Private CA è una CA altamente disponibile, sicura e gestita senza i costi iniziali e di manutenzione della gestione della propria CA. Se si utilizza l'autorità di certificazione Kubernetes predefinita, è possibile migliorare la sicurezza e soddisfare i requisiti di conformità con ACM Private CA. ACM Private CA protegge le chiavi private nei moduli di sicurezza hardware FIPS 140-2 Level 3 (molto sicuri), rispetto alla CA predefinita che memorizza le chiavi codificate in memoria (meno sicura). Una CA centralizzata offre inoltre un maggiore controllo e una migliore verificabilità per i certificati privati sia all'interno che all'esterno di un ambiente Kubernetes.

Short-Lived Modalità CA per il TLS reciproco tra carichi di lavoro

Quando si utilizza ACM Private CA per MTL in EKS, si consiglia di utilizzare certificati di breve durata con modalità CA di breve durata. Sebbene sia possibile emettere certificati di breve durata in modalità CA generica, l'utilizzo della modalità CA a vita breve è più conveniente (circa il 75% in meno rispetto alla modalità generale) per i casi d'uso in cui è necessario emettere frequentemente nuovi certificati. Inoltre, dovresti cercare di allineare il periodo di validità dei certificati privati con la durata dei pod nel tuo cluster EKS. Scopri di più su ACM Private CA e sui suoi vantaggi qui.

Istruzioni per la configurazione di ACM

Inizia creando una CA privata seguendo le procedure fornite nei documenti tecnici di ACM Private CA. Una volta che hai una CA privata, installa cert-manager seguendo le normali istruzioni di installazione. Dopo aver installato cert-manager, installa il plug-in cert-manager Private CA Kubernetes seguendo le istruzioni di configurazione in. GitHub Il plugin consente a cert-manager di richiedere certificati privati da ACM Private CA.

Ora che hai una CA privata e un cluster EKS con cert-manager e il plug-in installati, è il momento di impostare le autorizzazioni e creare l'emittente. Aggiorna le autorizzazioni IAM del ruolo del nodo EKS per consentire l'accesso ad ACM Private CA. Sostituisci il valore <CA_ARN> con il valore della tua CA privata:

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:acm-pca:us-west-2:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012"
        }
    ]
}

È possibile utilizzare anche i ruoli di servizio per gli account IAM o IRSA. Per esempi completi, consulta la sezione Risorse aggiuntive riportata di seguito.

Crea un emittente in Amazon EKS creando un file di definizione delle risorse personalizzato denominato cluster-issuer.yaml contenente il testo seguente, sostituendo le informazioni con la tua CA privata. <CA_ARN> <Region>

apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
          name: demo-test-root-ca
spec:
          arn: <CA_ARN>
          region: <Region>

Distribuisci l'emittente che hai creato.

kubectl apply -f cluster-issuer.yaml

Il cluster EKS è configurato per richiedere certificati da Private CA. È ora possibile utilizzare la Certificate risorsa di cert-manager per emettere certificati modificando i valori del issuerRef campo con l'emittente CA privato creato in precedenza. Per maggiori dettagli su come specificare e richiedere le risorse per i certificati, consulta la guida alle risorse per i certificati di cert-manager. https://cert-manager.io/docs/usage/certificate/ Vedi alcuni esempi qui.

CA privata ACM con Istio e cert-manager

Se stai eseguendo Istio nel tuo cluster EKS, puoi disabilitare il piano di controllo Istio (in particolareistiod) dal funzionare come autorità di certificazione (CA) principale e configurare ACM Private CA come CA root per gli MTL tra i carichi di lavoro. Se scegli questo approccio, valuta la possibilità di utilizzare la modalità CA di breve durata in ACM Private CA. Per maggiori dettagli, fate riferimento alla sezione precedente e a questo post del blog.

Come funziona la firma dei certificati in Istio (impostazione predefinita)

I carichi di lavoro in Kubernetes vengono identificati utilizzando gli account di servizio. Se non specifichi un account di servizio, Kubernetes ne assegnerà automaticamente uno al carico di lavoro. Inoltre, gli account di servizio montano automaticamente un token associato. Questo token viene utilizzato dall'account di servizio per l'autenticazione dei carichi di lavoro rispetto all'API Kubernetes. L'account di servizio può essere sufficiente come identità per Kubernetes, ma Istio dispone di un proprio sistema di gestione delle identità e di una CA. Quando un carico di lavoro viene avviato con il relativo proxy envoy sidecar, ha bisogno di un'identità assegnata da Istio per essere considerato affidabile e autorizzato a comunicare con altri servizi nella mesh.

Per ottenere questa identità da Istio, istio-agent invia una richiesta nota come richiesta di firma del certificato (o CSR) al piano di controllo di Istio. Questo CSR contiene il token dell'account di servizio in modo che l'identità del carico di lavoro possa essere verificata prima di essere elaborata. Questo processo di verifica è gestito daistiod, che funge sia da Autorità di registrazione (o RA) che da CA. L'RA funge da gatekeeper e si assicura che solo la CSR verificata arrivi alla CA. Una volta verificato, il CSR verrà inoltrato alla CA che emetterà quindi un certificato contenente un'identità https://spiffe.io/ SPIFFE con l'account del servizio. Questo certificato è chiamato documento di identità verificabile SPIFFE (o SVID). Lo SVID viene assegnato al servizio richiedente a fini di identificazione e per crittografare il traffico in transito tra i servizi comunicanti.

Flusso predefinito per le richieste di firma dei certificati Istio:

Come funziona la firma dei certificati in Istio con ACM Private CA

È possibile utilizzare un componente aggiuntivo cert-manager chiamato Istio Certificate Signing Request agent (istio-csr) per integrare Istio con ACM Private CA. Questo agente consente di proteggere i carichi di lavoro Istio e i componenti del piano di controllo con emittenti di cert manager, in questo caso ACM Private CA. L'agente istio-csr espone lo stesso servizio fornito da istiod nella configurazione predefinita di convalida dei CSR in entrata. Tranne che, dopo la verifica, convertirà le richieste in risorse supportate da cert manager (ad esempio integrazioni con emittenti CA esterni).

Ogni volta che un carico di lavoro contiene una CSR, questa verrà inoltrata a istio-csr, che richiederà i certificati da ACM Private CA. Questa comunicazione tra istio-csr e ACM Private CA è abilitata dal plug-in di emissione AWS Private CA. https://github.com/cert-manager/aws-privateca-issuer Cert Manager utilizza questo plugin per richiedere certificati TLS da ACM Private CA. Il plug-in dell'emittente comunicherà con il servizio ACM Private CA per richiedere un certificato firmato per il carico di lavoro. Una volta firmato, il certificato verrà restituito a istio-csr, che leggerà la richiesta firmata e la restituirà al carico di lavoro che ha avviato il CSR.

Flusso di richieste di firma dei certificati Istio con istio-csr

image: :istio-csr-with-acm-private-ca.png [Flusso per le richieste di firma dei certificati Istio con istio-csr]

Istruzioni per la configurazione di Istio con CA privata

Richieste di firma dei certificati Istio

image: :istio-csr-requests.png [richieste di firma del certificato Istio]

Strumenti e risorse