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 del 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 di Kubernetes offrono un meccanismo per limitare 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 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 politiche di rete possono essere applicate alle connessioni in entrata o in uscita al pod, spesso chiamate 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 compatibilità e aderenza agli standard Kubernetes. Puoi definire le politiche utilizzando diversi identificatori supportati dall'API upstream. Per impostazione predefinita, tutto il traffico in entrata e in uscita è consentito a un pod. Quando viene specificata una policy di rete con un PolicyType Ingress, solo le connessioni consentite nel pod sono quelle provenienti 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 della 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 dei privilegi minimi

Crea una politica di rifiuto predefinita

Come per le politiche RBAC, si consiglia di seguire i principi di accesso con privilegi minimi per quanto riguarda le politiche di rete. Inizia creando una politica di negazione totale 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 query DNS

Una volta impostata la regola deny all predefinita, 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 regole in modo incrementale per consentire in modo selettivo il flusso di traffico tra namespace e pod

Comprendi i requisiti dell'applicazione e crea regole di ingresso e uscita granulari in base alle esigenze. L'esempio seguente mostra come limitare il traffico in ingresso dalla porta 80 a quella da. app-one client-one Questo aiuta a ridurre al minimo la superficie di attacco e riduce il rischio di accesso non autorizzato.

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 vpc-network-policy-controller i log di Node-Agent

Abilita i log del gestore del controller del piano di controllo EKS per diagnosticare la funzionalità delle politiche di rete. È possibile trasmettere i log del control plane a un gruppo di CloudWatch log e utilizzare CloudWatchLog insights per eseguire interrogazioni avanzate. Dai log, è possibile visualizzare quali oggetti dell'endpoint 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 su Amazon Cloudwatch dai nodi di lavoro EKS. Una volta abilitato, puoi sfruttare CloudWatchContainer 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. È possibile trovare il file 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 scorre attraverso un VPC, come l'indirizzo IP e la porta di origine e destinazione, insieme ai pacchetti accettati/eliminati. 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 pod e altri metadati, semplificando 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 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 gli 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.3, esistevano gruppi di sicurezza separati configurati 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 all'indirizzo -group-reqs.html. https://docs.aws.amazon.com/eks/ latest/userguide/sec Le regole minime per il gruppo di sicurezza del piano di controllo consentono la porta 443 in entrata 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 kubelet ascoltano. Analogamente, le regole del gruppo minimo di nodi consentono la porta 10250 in entrata dal piano di controllo SG e la porta 443 in uscita verso il 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 devi 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.

È possibile controllare quali pod sono assegnati a un gruppo di sicurezza creando un SecurityGroupPolicy oggetto e specificando un o un. PodSelector ServiceAccountSelector L'impostazione dei selettori su {} assegnerà il SGs riferimento in a tutti i pod in un namespace o SecurityGroupPolicy a tutti gli account di servizio in uno spazio dei nomi. Assicurati di aver preso visione di tutte le considerazioni prima di implementare i gruppi di sicurezza per i pod.

Sebbene i gruppi di sicurezza per i pod offrano un modo nativo di AWS 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 policy di rete ai gruppi di sicurezza AWS. Se hai implementato una service mesh come Istio, puoi utilizzare un gateway di uscita per limitare l'uscita della 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 AWS Security groups for pods (SGP)

Le migliori pratiche relative all'utilizzo dei gruppi di sicurezza per i pod e della politica di rete

Quando si tratta di sicurezza della rete, un approccio a più livelli è spesso la soluzione più efficace. L'uso combinato della policy di rete di Kubernetes e di SGP può fornire una solida defense-in-depth strategia per le applicazioni eseguite 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. Consente di aggiungere in modo trasparente funzionalità come osservabilità, gestione del traffico e sicurezza, senza aggiungerle al proprio codice.

Service Mesh applica le policy al Layer 7 (applicazione) del modello OSI, mentre le policy di rete Kubernetes operano al Layer 3 (rete) e al Layer 4 (trasporto). Ci sono molte offerte in questo spazio come AWSAppMesh, Istio, Linkerd, ecc.

Quando utilizzare Service mesh per l'applicazione delle politiche

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

ThirdParty Motori di policy di rete

Prendi in considerazione un motore di policy di rete di terze parti quando hai requisiti di policy avanzati come politiche di rete globali, supporto per regole basate sui nomi host DNS, regole di livello 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 l'intero set di funzionalità delle policy di rete di Kubernetes, Calico supporta policy di rete estese con un set più ricco di funzionalità, incluso il supporto per le regole di livello 7, ad esempio HTTP, se integrato con Istio. Le policy di Calico possono essere applicate a namespace, pod, account di servizio o a livello globale. Quando le politiche riguardano 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 ignorare tali regole, consentendo ai professionisti della sicurezza IT di delegare in modo sicuro l'amministrazione dei namespace. Isovalent, i manutentori di Cilium, hanno anche esteso le politiche di rete per includere il supporto parziale per le regole di livello 7, ad esempio HTTP. Cilium supporta anche i nomi di host DNS, che possono essere utili per limitare il traffico tra Kubernetes Services/Pods e le risorse che vengono eseguite all'interno o all'esterno del tuo VPC. Al contrario, Calico Enterprise include una funzionalità che consente di mappare una policy di rete Kubernetes a un gruppo di sicurezza AWS, oltre a nomi host DNS.

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

Migrazione al motore di policy di rete Amazon VPC CNI

Per mantenere la coerenza ed evitare comportamenti imprevisti nelle comunicazioni tra i 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 le tue risorse 3P esistenti in Kubernetes prima di abilitare il supporto NetworkPolicy CRDs delle policy di rete VPC CNI. NetworkPolicy Inoltre, verifica le politiche 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 dei pod.

Strumento di migrazione

Per aiutarti nel processo di migrazione, abbiamo sviluppato uno strumento chiamato K8s Network Policy Migrator che converte le policy di rete esistenti in politiche di Calico/Cilium rete native di CRDs Kubernetes. Dopo la conversione, puoi testare direttamente le politiche di rete convertite sui tuoi nuovi cluster che eseguono il controller di policy 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 progettazione delle policy di rete CNI di AWS VPC, ma viene messo a disposizione dei clienti con la massima diligenza. Ti invitiamo a utilizzare questo strumento per facilitare il processo di migrazione. Nel caso in cui riscontrassi problemi o bug con lo strumento, ti chiediamo gentilmente di creare un problema. GitHub Il tuo feedback è prezioso per noi e contribuirà al miglioramento continuo dei nostri servizi.

Risorse aggiuntive

Crittografia in transito

Le applicazioni che devono essere conformi a PCI, HIPAA o altre normative potrebbero dover crittografare i dati mentre sono in transito. Al giorno d'oggi TLS è di fatto la scelta ideale 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 sulla base di un segreto condiviso negoziato all'inizio della sessione. Di seguito sono riportati alcuni modi in cui è possibile 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 sistema di bilanciamento del carico, 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.

Interfacce di rete per container () CNIs

WeaveNetpuò essere configurato per crittografare automaticamente tutto il traffico utilizzando la NaCl crittografia per il traffico «sleeve» e l' IPsec ESP per il traffico datapath veloce.

Service Mesh

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

Il aws-app-mesh-examplesGitHub repository fornisce procedure dettagliate per la configurazione degli MTL utilizzando certificati X.509 e SPIRE come provider SDS con il contenitore Envoy:

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

Il aws-app-mesh-examplesGitHub repository fornisce procedure dettagliate per la configurazione di TLS utilizzando certificati emessi da ACM e certificati inclusi nel pacchetto Envoy:

Controller di ingresso e sistemi di bilanciamento del carico

I controller di ingresso consentono di indirizzare in modo intelligente l'elaborazione e richiedono un uso intensivo della CPU. HTTP/S traffic that emanates from outside the cluster to services running inside the cluster. Oftentimes, these Ingresses are fronted by a layer 4 load balancer, like the Classic Load Balancer or the Network Load Balancer (NLB). Encrypted traffic can be terminated at different places within the network, e.g. at the load balancer, at the ingress resource, or the Pod. How and where you terminate your SSL connection will ultimately be dictated by your organization’s network security policy. For instance, if you have a policy that requires end-to-end encryption, you will have to decrypt the traffic at the Pod. This will place additional burden on your Pod as it will have to spend cycles establishing the initial handshake. Overall SSL/TLS Di conseguenza, se hai la flessibilità, prova a eseguire l'offload SSL presso Ingress o il 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 del trasporto (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 certificati ai listener che lo richiedono abbinando i certificati AWS Certificate Manager (ACM) disponibili utilizzando il campo host. A partire da EKS v1.15 puoi usare 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 altri esempi di terminazione. SSL/TLS

ACM Private CA con cert-manager

Puoi abilitare TLS e mTLS per proteggere i carichi di lavoro delle applicazioni EKS all'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 gestita, sicura e altamente disponibile senza i costi iniziali e di manutenzione della gestione della propria CA. Se utilizzi l'autorità di certificazione Kubernetes predefinita, esiste l'opportunità di 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 di livello 3 (molto sicuri), rispetto alla CA predefinita che archivia le chiavi codificate in memoria (meno sicure). Una CA centralizzata offre inoltre un maggiore controllo e una migliore verificabilità dei certificati privati sia all'interno che all'esterno di un ambiente Kubernetes.

Modalità CA di breve durata per TLS reciproco tra carichi di lavoro

Quando si utilizza ACM Private CA for mTLS 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 di breve durata risulta 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 provare ad allineare il periodo di validità dei certificati privati alla durata dei pod del tuo cluster EKS. Scopri di più su ACM Private CA e sui suoi vantaggi qui.

Istruzioni di configurazione 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 utilizzando le normali istruzioni di installazione. Dopo aver installato cert-manager, installa il plugin Private CA Kubernetes cert-manager seguendo le istruzioni di configurazione riportate in. GitHub Il plug-in consente al 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 a 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": "<CA_ARN>"
        }
    ]
}

È possibile utilizzare anche Service Roles for IAM Accounts o IRSA. Consulta la sezione Risorse aggiuntive di seguito per esempi completi.

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

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

Implementa l'emittente che hai creato.

kubectl apply -f cluster-issuer.yaml

Il tuo cluster EKS è configurato per richiedere certificati da Private CA. Ora puoi utilizzare la Certificate risorsa di cert-manager per emettere certificati modificando i valori del issuerRef campo nell'emittente CA privato che hai creato sopra. Per maggiori dettagli su come specificare e richiedere le risorse relative ai certificati, consulta la guida alle risorse per i certificati di cert-manager. Vedi alcuni esempi qui.

ACM Private CA con Istio e cert-manager

Se esegui Istio nel tuo cluster EKS, puoi disabilitare il piano di controllo Istio (in particolareistiod) dal funzionamento come Autorità di certificazione (CA) principale e configurare ACM Private CA come CA principale per MTL tra i carichi di lavoro. Se utilizzi questo approccio, prendi in considerazione l'utilizzo della modalità CA di breve durata in ACM Private CA. Per maggiori dettagli, consulta la sezione precedente e 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 tuo carico di lavoro. Inoltre, gli account di servizio montano automaticamente un token associato. Questo token viene utilizzato dall'account di servizio per i carichi di lavoro per l'autenticazione con l'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 CA. Quando un carico di lavoro si avvia con il suo proxy sidecar Envoy, ha bisogno di un'identità assegnata da Istio per poter essere considerato affidabile e poter comunicare con gli altri servizi della rete 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 Istio. Questa CSR contiene il token dell'account del servizio in modo che l'identità del carico di lavoro possa essere verificata prima dell'elaborazione. Questo processo di verifica è gestito daistiod, che funge sia da Autorità di registrazione (o RA) che da CA. La RA funge da guardiano che assicura che solo la CSR verificata pervenga alla CA. Una volta verificata, la CSR verrà inoltrata alla CA che emetterà quindi un certificato contenente un'identità SPIFFE con l'account del servizio. Questo certificato è chiamato documento di identità verificabile SPIFFE (o SVID). Lo SVID viene assegnato al servizio richiedente per scopi di identificazione e per crittografare il traffico in transito tra i servizi di comunicazione.

Flusso predefinito per le richieste di firma dei certificati Istio:

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

Puoi 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 gli emittenti dei gestori di certificati, in questo caso ACM Private CA. L'agente istio-csr espone lo stesso servizio fornito da istiod nella configurazione predefinita di convalida delle chiamate in entrata. CSRs Tuttavia, dopo la verifica, convertirà le richieste in risorse supportate da cert manager (ad esempio integrazioni con emittenti CA esterni).

Ogni volta che viene generata una CSR da un carico di lavoro, 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 plugin AWS Private CA issuer. Cert manager utilizza questo plugin per richiedere certificati TLS da ACM Private CA. Il plug-in 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 la CSR.

Richieste di firma dei certificati Flow for Istio con istio-csr

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

Istruzioni di 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