Contribuisci a migliorare questa pagina

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

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina su che si trova nel riquadro destro di ogni pagina.

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

Ruota l'autorità di certificazione (CA) del cluster EKS

Nell'infrastruttura a chiave pubblica (PKI), un'autorità di certificazione (CA) è un'entità attendibile che emette e firma certificati digitali. Questi certificati stabiliscono l'identità e consentono la comunicazione crittografata tra sistemi tramite TLS (Transport Layer Security). Quando un client si connette a un server, il server presenta un certificato firmato da una CA. Il client verifica il certificato del server rispetto alle CA di cui si fida prima di consentire il proseguimento della connessione.

In Amazon Elastic Kubernetes Service (Amazon EKS), viene creata una CA per ogni cluster EKS al momento della creazione del cluster. Segue lo stesso modello di Kubernetes upstream: ogni cluster EKS ha una propria CA che firma i certificati per il server API. Questo è ciò che consente ai componenti del piano di controllo, ai nodi di lavoro e ai client di autenticarsi sul server API e stabilire connessioni crittografate al cluster EKS.

Queste autorità di certificazione (CA) hanno un periodo di validità definito. La rotazione delle CA è il processo di sostituzione dell'autorità di certificazione del cluster EKS prima della scadenza, garantendo che il cluster rimanga operativo e accessibile. Disponiamo di protezioni integrate che gestiscono automaticamente questo processo. Se non avvii tu stesso la rotazione delle CA, aggiungeremo automaticamente una CA successore e la attiveremo prima della scadenza della CA in uscita, assicurando che il cluster rimanga disponibile.

Durante la rotazione delle CA, una CA successore viene aggiunta al cluster EKS. EKS distribuisce automaticamente la CA successore a tutti i componenti AWS gestiti (piano di controllo, istanze EKS Auto Mode e AWS nodi Fargate). Sei responsabile dell'aggiornamento dei nodi di lavoro che gestisci (non EKS Auto Mode, non Fargate) e dei client esterni (come i file e le CI/CD pipeline kubeconfig) in modo che considerino attendibile la CA successore prima che venga attivata. Dopo l'attivazione della CA successore, il cluster EKS passa alla firma dei certificati con la CA successore. La CA in uscita viene quindi ritirata.

La rotazione delle CA è richiesta per ogni cluster EKS perché le CA hanno un periodo di validità finito. Il periodo di validità dipende da quando è stata creata la CA del cluster. Per maggiori dettagli, consulta la sezione delle domande frequenti. Le protezioni EKS garantiscono che il cluster stesso rimanga disponibile per tutto il ciclo di vita della rotazione, ma il successo della rotazione dipende anche dall'aggiornamento dei nodi di lavoro che gestisci e dei client esterni in modo che mantengano la connettività dopo l'attivazione della CA successore.

Le API, l'esperienza della console, le notifiche e le linee guida dettagliate nelle sezioni che seguono sono progettate per supportarti in questo processo. L'intero ambito delle responsabilità è trattato nella sezione relativa al modello di responsabilità condivisa.

Come funziona la rotazione di CA

La rotazione della CA in Amazon EKS è un processo in più fasi. Disponiamo di misure di sicurezza automatiche per preservare la disponibilità dei cluster EKS durante l'intero ciclo di vita della rotazione, indipendentemente dal fatto che tu agisca o meno. Una rotazione riuscita, in cui tutti i componenti mantengano la connettività, richiede i passaggi descritti nelle sezioni seguenti.

Fase 1: aggiungere una CA successore

Una CA successore viene aggiunta al cluster EKS. Da questo punto, il cluster EKS considera attendibili contemporaneamente sia la CA in uscita che la CA successore. I certificati continuano ad essere emessi dalla CA uscente. Non si verificano interruzioni.

Puoi aggiungere tu stesso una CA successore in qualsiasi momento utilizzando la AWS CLI, l'API EKS, la Console o l'infrastruttura come codice (IaC), ad esempio AWS CloudFormation, purché il cluster sia attivo. Se non lo fai, ne aggiungeremo automaticamente uno per tuo conto.

La CA successore non può essere attivata fino al AWS completamento della distribuzione ai componenti AWS gestiti in EKS (Fase 2). Questo è il momento giusto per iniziare a identificare i nodi di lavoro e i client esterni che devono essere aggiornati. L'identificazione di tutti i sistemi che si connettono al server API del cluster EKS può richiedere tempo, in particolare in ambienti con più team, CI/CD pipeline e strumenti di monitoraggio. L'avvio anticipato di questo processo offre la massima flessibilità per coordinare gli aggiornamenti in base alle proprie tempistiche.

Fase 2: distribuzione della CA successiva

Dopo aver aggiunto la CA successore, AWS aggiorna i componenti gestiti nel cluster EKS (il piano di controllo, le istanze EKS Auto Mode e i nodi AWS Fargate) per riconoscere e considerare attendibili entrambe le CA. È possibile monitorarne l'avanzamento tramite lo stato di distribuzione della CA. La CA successore non può essere attivata finché la distribuzione non è completa.

Dopo aver completato la distribuzione della CA ai componenti gestiti, sei responsabile dell'aggiornamento di due gruppi: i nodi di lavoro che gestisci (modalità automatica non EKS, non Fargate) e i client esterni affinché si fidino della CA successore. Ciò garantisce che continueranno a connettersi al server API dopo l'attivazione della CA successore. Se alcuni componenti non vengono aggiornati prima dell'attivazione della CA successore, è disponibile il rollback della CA per ripristinare la connettività mentre si completano gli aggiornamenti rimanenti.

Fase 3: attivazione della CA successore

Dopo aver completato la distribuzione della CA successore a tutti i componenti AWS gestiti in EKS, è possibile attivare la CA successore. Ti consigliamo di attivare la CA successore secondo la tua tempistica. Concediti il tempo necessario per scoprire e aggiornare i nodi di lavoro che gestisci e i client esterni per fidarti della CA successore. Dopo l'attivazione della CA successore, il cluster EKS emette i certificati firmati dalla CA successore. La CA in uscita rimane affidabile ma non viene più utilizzata per la firma. Una finestra di rollback è disponibile per un periodo limitato dopo l'attivazione, che consente di tornare alla CA in uscita, se necessario. Il rollback è trattato in dettaglio in una sezione successiva.

Puoi attivare tu stesso la CA successore quando sei sicuro che i nodi di lavoro che gestisci e i client siano stati aggiornati. In caso contrario, attiveremo automaticamente la CA successore all'avvicinarsi della scadenza.

Il periodo di doppia fiducia

Il periodo che intercorre tra l'aggiunta di una CA successore (Fase 1) e il ritiro della CA uscente è chiamato periodo di doppio trust. Durante questo periodo, il cluster EKS considera attendibili entrambe le CA contemporaneamente. Questo è ciò che rende la rotazione senza interruzioni: i componenti possono essere aggiornati in modo incrementale perché il cluster EKS accetta i certificati firmati da entrambe le CA.

Il periodo di doppia fiducia ti dà il tempo di identificare e aggiornare tutti i nodi di lavoro che gestisci e i client esterni senza dover coordinare tutte le modifiche contemporaneamente.

È importante capire in che modo l'attivazione della CA successore influisce sulla connettività. Quando un client si connette al server API, verifica l'identità del server controllando che il certificato del server sia stato firmato da una CA di cui si fida.

Dopo l'attivazione della CA successore, il server API presenta il certificato firmato dalla CA successore. I client che hanno aggiornato il trust bundle per includere la CA successore eseguiranno la verifica con successo e si connetteranno normalmente. I client che non hanno aggiornato il trust bundle non riconosceranno il certificato del server e non saranno in grado di stabilire una connessione.

Il diagramma seguente mostra il flusso di connessione TLS dopo l'attivazione della CA successiva.

Ecco perché è importante aggiornare i nodi di lavoro e i client esterni prima dell'attivazione della CA successore: hanno bisogno della CA successore nel loro trust bundle per verificare l'identità del server API e connettersi. Il periodo di doppia fiducia e il rollback di CA forniscono tempo e una rete di sicurezza per completare questa operazione.

Modello di responsabilità condivisa

La rotazione delle CA in Amazon EKS segue lo stesso modello di responsabilità condivisa che si applica in generale a tutti. AWS AWS è responsabile della sicurezza e della disponibilità dell'infrastruttura cloud e tu sei responsabile della sicurezza e della configurazione dei tuoi carichi di lavoro al suo interno. Per ulteriori informazioni su come la responsabilità condivisa si applica ad Amazon EKS, consulta le best practice di sicurezza di EKS.

Nel contesto della rotazione delle CA, ciò significa:

AWS è responsabile per

Sei responsabile per

Non possiamo eseguire queste azioni per tuo conto. I clienti esterni esistono al di fuori dei confini AWS operativi. La configurazione CA trust dei nodi di lavoro non gestiti da EKS Auto Mode o Fargate è impostata al momento dell'avvio o tramite processi di bootstrap controllati solo dall'utente. Ciò è coerente con il funzionamento di TLS Trust: il client detiene il proprio trust store e solo l'amministratore del cliente può aggiornarlo.

Le sezioni che seguono si espandono su ogni lato: cosa AWS fa per te e cosa devi fare insieme a una guida dettagliata su come farlo.

What AWS fa per te

AWS gestisce quanto segue durante l'intero ciclo di vita della rotazione della CA per il cluster EKS:

Creazione automatica della CA

Se non aggiungi una CA successore alla tua timeline, ne aggiungeremo una automaticamente quando la CA in uscita del tuo cluster EKS si avvicina alla scadenza. Ciò garantisce che il processo di rotazione inizi con il tempo sufficiente per individuare e aggiornare i clienti prima della scadenza.

Aggiornamenti del piano di controllo

Aggiorniamo automaticamente il piano di controllo del cluster EKS per affidarci alla CA successore. Dopo l'attivazione della CA successore, il piano di controllo emette i certificati firmati dalla CA successore. Non è richiesta alcuna azione da parte dell'utente per il piano di controllo.

Aggiornamenti EKS Auto Mode e Fargate

Aggiorniamo automaticamente i nodi EKS Auto Mode e i pod Fargate per affidarci alla CA successiva. Questi componenti sono completamente gestiti da noi e non richiedono alcuna azione da parte dell'utente durante la rotazione della CA.

Aggiornamenti di EKS Capabilities

Aggiorniamo automaticamente EKS Capabilities (AWS Controllers for Kubernetes (ACK), Argo CD e kro (Kube Resource Orchestrator)) per affidarci alla CA successore. Queste risorse gestite comunicano con il server API del cluster e vengono aggiornate come parte del processo di distribuzione della CA. Non è richiesta alcuna azione da parte dell'utente per le risorse gestite in EKS Capabilities. Per ulteriori informazioni, vedere EKS Capabilities.

Monitoraggio dello stato della distribuzione

Man mano che aggiorniamo i componenti gestiti nel tuo cluster EKS, puoi monitorare l'avanzamento dello stato di distribuzione della CA. Questo ti dice se abbiamo completato la nostra parte della rotazione. La CA successore non può essere attivata finché la distribuzione non è completa.

Built-in garanzie

Abbiamo delle protezioni integrate per proteggere il tuo cluster EKS durante la rotazione:

Queste misure di sicurezza assicurano che la disponibilità del cluster EKS sia preservata per tutto il ciclo di vita della rotazione, indipendentemente dal fatto che tu agisca o meno.

Notifications

Ti informiamo in ogni fase del ciclo di vita della rotazione di CA. Le notifiche vengono inviate tramite AWS Health, Cluster Insights ed e-mail. Ogni notifica indica cosa è successo, quale azione (se necessaria) è richiesta da parte tua e dove si trova il tuo cluster EKS nella timeline di rotazione.

Puoi anche configurare le tue notifiche utilizzando Amazon EventBridge per integrare gli eventi di rotazione delle CA nei flussi di lavoro di monitoraggio e avviso esistenti.

Cosa devi fare (e perché)

Una rotazione CA di successo richiede l'aggiornamento dei componenti che AWS non possono essere raggiunti per tuo conto. Questi si dividono in due categorie:

Clienti esterni

Qualsiasi sistema che si connette al server API del cluster EKS dall'esterno del cluster. Ciò include workstation per sviluppatori, CI/CD pipeline (Jenkins, GitHub Actions, ArgoCD) GitLab, strumenti di monitoraggio e osservabilità, script di automazione e qualsiasi applicazione che utilizza un kubeconfig per comunicare con il server API.

Ciascuno di questi sistemi mantiene la propria configurazione di fiducia. Quando la CA successore è attivata, il server API presenta i certificati firmati dalla CA successore. L'aggiornamento di questi client in modo che considerino attendibile la CA successore prima dell'attivazione della CA successore garantisce che mantengano la connettività. Se manca un client, CA rollback può ripristinare l'accesso durante il completamento dell'aggiornamento.

Nodi di lavoro (modalità automatica non EKS, non Fargate)

La configurazione CA trust dei nodi di lavoro non gestiti da EKS Auto Mode o Fargate è impostata al momento dell'avvio o tramite il processo di bootstrap di kubelet. Questi nodi devono essere aggiornati in modo che si fidino della CA successore. L'azione richiesta dipende dal tipo di nodo di lavoro:

Gruppi di nodi gestiti

Esegue un aggiornamento della versione del gruppo di nodi, che attiva una sostituzione progressiva dei nodi. I nuovi nodi vengono avviati automaticamente con la configurazione aggiornata di CA trust.

Karpenter-controlled nodi

Se il rilevamento della deriva è abilitato, Karpenter eseguirà i cicli dei nodi all'interno della finestra di deriva configurata e i nuovi nodi preleveranno la CA successiva senza alcuna azione manuale. Se il rilevamento della deriva è disabilitato o impostato su una finestra lunga, tratta questi nodi come nodi autogestiti.

Self-managed nodi

Sostituisci i nodi in modo che si avviino con la configurazione di fiducia di CA aggiornata. Ciò comporta in genere l'aggiornamento del modello di avvio con i dati CA aggiornati e l'attivazione di una sostituzione progressiva tramite il gruppo Auto Scaling.

Nodi ibridi

Aggiorna la configurazione di trust su ogni nodo ibrido per includere la CA successore. Il processo specifico dipende dal modo in cui i nodi ibridi sono stati avviati e da come viene gestita la loro configurazione di trust.

Puoi identificare quali tipi di nodi di lavoro sono in esecuzione nel tuo cluster EKS utilizzando Cluster Insights. Una guida dettagliata per l'aggiornamento di ciascun tipo è fornita in una sezione successiva.

Forniamo CA rollback come rete di sicurezza in caso di perdita di alcuni nodi di lavoro. Tuttavia, l'aggiornamento di tutti i nodi di lavoro prima dell'attivazione della CA successiva evita completamente le interruzioni della connettività. I nodi non aggiornati prima dell'attivazione della CA successore perderanno la connettività al server API del cluster EKS fino a quando non verranno sostituiti o non verrà eseguito il rollback della CA.

Perché solo tu puoi farlo

I clienti esterni esistono al di fuori dei confini AWS operativi. Una CI/CD pipeline in esecuzione nella rete aziendale, il laptop di uno sviluppatore, uno strumento di monitoraggio ospitato in sede: non AWS dispone di alcun meccanismo per accedere a questi sistemi e aggiornarne la configurazione di fiducia.

Non-EKS La configurazione di attendibilità dei nodi di lavoro in modalità automatica è controllata tramite modelli di avvio, script di dati utente o processi di bootstrap di tua proprietà. L'aggiornamento richiede la sostituzione dei nodi o la modifica della loro configurazione, entrambe azioni all'interno dell'infrastruttura.

Questo è un vincolo del modello di fiducia TLS utilizzato oggi da Kubernetes. Non esiste un meccanismo a livello di protocollo che consenta al server API di verificare se un client ha aggiornato il proprio pacchetto di fiducia. Il server può presentare il proprio certificato solo quando un client si connette. Se il client si fida della CA che lo ha firmato, la connessione ha esito positivo. In caso contrario, fallisce. Non esiste un percorso di verifica pre-attivazione che AWS consenta di confermare la disponibilità dei componenti per conto dell'utente.

Quando iniziare

Inizia a identificare i tuoi clienti esterni il prima possibile. Questa è la parte più dispendiosa in termini di tempo della rotazione delle CA, in particolare in ambienti con più team che distribuiscono in modo indipendente i carichi di lavoro nel cluster EKS. Quanto prima si inizia a individuare i clienti, tanto più tempo si ha a disposizione per coordinare gli aggiornamenti tra i team senza pressioni.

Una guida dettagliata su come aggiornare ogni tipo di client e nodo di lavoro è fornita nelle sezioni che seguono.

Prerequisiti

Prima di iniziare la rotazione CA, conferma quanto segue:

Non sono richieste autorizzazioni IAM aggiuntive oltre a quelle necessarie per gestire il cluster EKS. Se oggi puoi chiamare le API EKS per il tuo cluster EKS, puoi eseguire la rotazione CA.

Nozioni di base

Puoi eseguire la rotazione della CA utilizzando l'interfaccia a riga di AWS comando o la console Amazon EKS. Assicurati di eseguire la AWS CLI versione 2.x o successiva (aws --versionper verificare).

Utilizzo di AWS CLI

La seguente procedura dettagliata illustra il processo di rotazione completa della CA utilizzando la CLI e le AWS API EKS.

Passaggio 1: controlla la CA attiva

Visualizza l'autorità di certificazione attiva sul tuo cluster EKS.

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Output previsto:

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

Mostra la CA creata al momento della creazione del cluster EKS. È attualmente in uso (firma dei certificati) e la distribuzione è completa (tutti i componenti AWS gestiti in EKS si fidano di esso).

Fase 2: Visualizza i dettagli e la scadenza della CA

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

Output previsto:

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

Il validity blocco mostra quando è stata creata la CA (notBefore) e quando scade (notAfter). rollbackAvailableindica se è possibile ripristinare una CA precedente dopo l'attivazione della CA successiva. Per la CA iniziale creata con il cluster EKS, ciò sarà false dovuto al fatto che non esiste una CA precedente a cui tornare.

Fase 3: aggiungere una CA successore

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

Questo aggiunge una CA successore al cluster EKS. La risposta include una updateId che puoi usare per tenere traccia dei progressi.

Fase 4: Tieni traccia dell'aggiornamento

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

Attendi che lo stato dell'aggiornamento siaSuccessful.

Fase 5: Verifica lo stato della distribuzione

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Ora dovresti vedere due CA. La CA successore avrà signingStatus: NOT_USED e distributionStatus procederà COMPLETE successivamente IN_PROGRESS AWS all'aggiornamento di tutti i componenti gestiti nel cluster EKS.

Non procedere finché non sarà raggiunto lo stato di distribuzione della CA successore. COMPLETE

Passaggio 6: aggiorna il tuo kubeconfig

aws eks update-kubeconfig --name my-cluster --region us-west-2

Questo aggiorna il tuo kubeconfig locale in modo che entrambe le CA siano affidabili. Dopodiché, i comandi kubectl continueranno a funzionare dopo l'attivazione della CA successiva.

Passaggio 7: aggiorna i nodi di lavoro che gestisci e i client esterni

Questo è trattato in dettaglio nella sezione successiva. Dopo che tutti i nodi di lavoro gestiti e i client esterni sono stati aggiornati in modo da considerare attendibili la CA successore, procedi all'attivazione.

Fase 8: Attivazione della CA successore

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

Dopo l'attivazione della CA successore, il cluster EKS emette i certificati firmati dalla CA successore. Verifica la connettività per confermare che tutti i componenti funzionino come previsto.

Utilizzo della console Amazon EKS

La console Amazon EKS offre un'esperienza guidata per la rotazione delle CA. Puoi visualizzare lo stato della CA, aggiungere una CA successore, monitorare l'avanzamento della distribuzione e attivare la CA successore direttamente dalla console.

L'immagine seguente mostra la visualizzazione dei dettagli dell'autorità di certificazione nella console di Amazon EKS durante una rotazione attiva. La CA attiva e la CA successore vengono entrambe visualizzate con lo stato di firma, la data di scadenza e i giorni mancanti alla scadenza.

L'immagine seguente mostra la visualizzazione dell'avanzamento della rotazione nella console Amazon EKS. Ogni fase del processo di rotazione viene visualizzata con il suo stato attuale, inclusi l'aggiunta, la distribuzione, l'aggiornamento dei nodi di lavoro e dei client esterni, l'attivazione e l'eliminazione della CA in uscita.

Aggiornamento dei client Kubernetes

Dopo aver aggiunto la CA successore e aver AWS completato la distribuzione ai componenti gestiti nel cluster EKS (distributionStatus: COMPLETE), è necessario aggiornare i propri componenti per rendere attendibile la CA successore. Un «client» in questo contesto è qualsiasi sistema che si connette al server API del cluster EKS. Ciò include la configurazione locale di kubectl, le CI/CD pipeline, gli strumenti di monitoraggio, gli script di automazione e i nodi di lavoro.

I dati CA aggiornati per il cluster EKS (che ora contiene sia la CA attuale che quella successiva) possono essere recuperati utilizzando:

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

Utilizzate questo valore per aggiornare la configurazione di trust di ogni tipo di client nelle seguenti sottosezioni.

Kubeconfig (workstation per sviluppatori, pipeline, automazione) CI/CD

Esegui quanto segue per aggiornare il tuo kubeconfig locale:

aws eks update-kubeconfig --name my-cluster --region us-west-2

Questo recupera automaticamente i dati CA più recenti e aggiorna il tuo kubeconfig. Qualsiasi sistema che utilizza questo kubeconfig si fiderà di entrambe le CA.

Per CI/CD le pipeline e le automazioni che generano il proprio kubeconfig (ad esempio, utilizzando direttamente le API EKS o archiviando kubeconfig come segreto), aggiorna il campo con il valore recuperato da. certificate-authority-data describe-cluster

Gruppi di nodi gestiti

Esegui un aggiornamento della versione del gruppo di nodi per attivare una sostituzione progressiva dei nodi:

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

I nuovi nodi si avviano automaticamente con i dati CA aggiornati. La sostituzione progressiva garantisce che i nodi vengano sostituiti uno alla volta senza interrompere i carichi di lavoro in esecuzione.

Se gestisci i tuoi gruppi di nodi tramite Terraform o CloudFormation, la rotazione CA non crea deviazioni nello stato IaC. Il ciclo di vita della CA è gestito tramite API EKS dedicate, separate dalla configurazione delle risorse del cluster. Per maggiori dettagli su come la rotazione di CA interagisce con l'infrastruttura come codice, consulta la sezione Infrastructure as code.

Modello di avvio personalizzato con un'AMI personalizzata

Se il gruppo di nodi è distribuito con un'AMI personalizzata, AWS non unisce i dati utente. L'utente è responsabile della fornitura della corretta configurazione di bootstrap, incluso il CA trust bundle aggiornato. CA rotation non aggiorna automaticamente i dati utente e un nodo senza la CA successore non riesce a entrare nel cluster.

Verifica che i nodi siano in esecuzione sul modello di avvio aggiornato

Prima di procedere all'attivazione, verificate che tutti i nodi del gruppo di nodi gestiti siano in esecuzione sulla versione più recente del modello di avvio. Questa versione deve contenere il CA trust bundle aggiornato.

Karpenter-controlled nodi

Se il rilevamento della deriva è abilitato in Karpenter NodePool, Karpenter rileverà automaticamente che i nodi sono in esecuzione con dati CA obsoleti e li ciclerà entro la finestra di interruzione configurata. I nuovi nodi raccoglieranno la CA successiva senza alcuna azione manuale.

Verifica che il rilevamento della deriva sia abilitato nella tua NodePool configurazione:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

Se disruption è configurato con una politica di consolidamento, il rilevamento della deriva è attivo per impostazione predefinita. Karpenter sostituirà i nodi che sono passati dallo stato desiderato, che include le modifiche ai dati CA.

Se il rilevamento della deriva è abilitato, verifica che il budget previsto per le interruzioni consenta la sostituzione di tutti i Karpenter-controlled nodi prima della data di attivazione della CA successiva. Se il budget è troppo restrittivo (ad esempio, una finestra di manutenzione ristretta con una percentuale di sostituzione bassa), non tutti i nodi potrebbero essere sostituiti in tempo.

Se il rilevamento della deriva è disabilitato o i budget previsti per le interruzioni limitano le sostituzioni a una finestra che supera la tempistica di rotazione prevista, puoi attivare manualmente la sostituzione dei nodi isolando e svuotando i nodi:

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Karpenter fornirà un nodo sostitutivo che si avvia con i dati CA aggiornati.

Self-managed nodi

Per i nodi autogestiti, è necessario aggiornare i dati della CA nel modello di avvio o nello script dei dati utente utilizzati dai nodi durante il bootstrap:

I nuovi nodi verranno avviati con i dati CA aggiornati e si affideranno sia alle CA attuali che a quelle successive.

AWS Pod Fargate (tipo di lancio EKS Fargate)

AWS I pod Fargate del cluster EKS funzionano in modo diverso dalle altre modalità di avvio del piano dati EKS (gruppi di nodi gestiti, nodi autogestiti, nodi). Karpenter-controlled

Quando un pod si connette al server API, accadono due cose: il pod si autentica utilizzando il token dell'account di servizio (dimostrando la propria identità al server API) e il pod verifica l'identità del server API controllando che il certificato del server sia stato firmato da una CA di cui si fida. I dati CA archiviati nell'ambiente del pod sono ciò che rende possibile questa verifica. Se il server API inizia a presentare certificati firmati da una CA successore di cui il pod non considera attendibili, il pod rifiuterà la connessione.

In altre modalità di avvio del piano dati EKS (gruppi di nodi gestiti, nodi autogestiti, Karpenter-controlled nodi), i dati CA risiedono sul nodo. Quando si sostituisce il nodo, il nuovo nodo si avvia con i dati CA aggiornati. I pod pianificati su quel nuovo nodo ricevono i dati CA aggiornati, consentendo loro di verificare il server API indipendentemente dalla CA che ha firmato il certificato.

In Fargate, ogni pod viene eseguito nel proprio ambiente di calcolo dedicato con il proprio processo kubelet. Questo kubelet si avvia con i dati della CA al momento della creazione del pod. Al di sotto non è presente alcun nodo condiviso e non si ha accesso diretto al calcolo sottostante.

Non è richiesta alcuna azione da parte del cliente per i nodi AWS Fargate in EKS durante la rotazione CA. AWS ricicla naturalmente i pod nei nodi Fargate attraverso il processo di patching. Dopo l'aggiunta di una CA successiva, i pod Fargate preesistenti vengono riciclati come parte di questo processo. Si affideranno alla CA successore senza alcuna azione da parte tua. Poiché AWS aggiunge la CA successore con largo anticipo rispetto a qualsiasi tempistica di attivazione della CA AWS avviata in EKS, i pod Fargate saranno stati riciclati e si affideranno alla CA successore nel momento in cui attiverà la CA successore. AWS È presente una protezione integrata che impedisce l'attivazione della CA successiva fino al termine del riciclaggio dei pod Fargate.

Ciò significa che entrambe le opzioni del piano dati gestito (EKS Auto Mode e Fargate) per un cluster EKS offrono la stessa esperienza utente per la rotazione della CA: non è richiesta alcuna azione da parte del cliente per i nodi di lavoro. Sei comunque responsabile dell'aggiornamento di tutti i client esterni che si connettono al server API.

Questo è un caso limite. Data la tempistica di rotazione (la CA successore è stata aggiunta anni prima della scadenza), il naturale ciclo di patching si concluderà ben prima dell'attivazione della CA successiva nella maggior parte degli scenari. La protezione esiste come misura preventiva nell'improbabile caso in cui un cliente tenti l'attivazione anticipata.

Client esterni (strumenti di monitoraggio, integrazioni di terze parti)

Qualsiasi applicazione o strumento che si connette al server API del cluster EKS utilizzando una configurazione kubeconfig o certificate trust deve essere aggiornato con i dati CA aggiornati. Questo include:

Per ognuno di questi, sostituisci i dati CA archiviati con il valore aggiornato didescribe-cluster.

Come verificare che un client sia stato aggiornato

Dopo aver aggiornato un client, verifica che possa ancora comunicare con il server API:

kubectl get nodes

Se il comando ha esito positivo, il tuo kubeconfig si fida dei dati CA attivi. Dopo l'attivazione della CA successiva, esegui lo stesso comando per confermare la continuità della connettività.

Infrastructure as code (IaC)

È possibile eseguire la rotazione della CA insieme alla propria infrastruttura di codice (IaC) esistente senza creare deviazioni o richiedere modifiche alle configurazioni IaC.

Perché la rotazione CA non influisce sullo stato IaC

Il ciclo di vita della CA è gestito tramite API EKS dedicate (create-certificate-authority,activate-certificate-authority,delete-certificate-authority) completamente separate dalla configurazione delle risorse del cluster EKS. Indipendentemente dal fatto che la rotazione della CA sia avviata dall'utente o automaticamente da AWS, nessuna proprietà tracciata dagli strumenti IaC sulla risorsa del cluster EKS viene modificata.

Ciò significa che:

Il certificateAuthority.data campo restituito da describe-cluster è un output di sola lettura. Riflette l'attuale pacchetto di fiducia combinato (entrambe le CA durante il periodo di doppia fiducia) ma non è una proprietà configurabile. Gli strumenti IaC non lo considerano qualcosa da riconciliare.

I campi di attribuzione (createdBy,activatedBy) in ogni record CA consentono di distinguere tra le operazioni avviate dall'utente e le operazioni AWS avviate automaticamente, il che supporta i flussi di lavoro di audit e gestione delle modifiche.

Utilizzo con rotazione CA CloudFormation

La rotazione della CA può essere attivata CloudFormation utilizzando una WriteOnly proprietà sulla AWS::EKS::Cluster risorsa. Questa proprietà attiva l'attivazione ma non viene memorizzata nello stato dello stack, pertanto gli aggiornamenti successivi dello stack senza di essa non tentano di ripristinarla o disattivarla.

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

Questo primo aggiornamento dello stack aggiunge una CA successore al cluster. Attendi il raggiungimento COMPLETE dello stato di distribuzione della CA successore prima di procedere.

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

Questo secondo aggiornamento dello stack attiva l'attivazione della CA successore. Poiché ActiveCertificateAuthorityId è una WriteOnly proprietà, non viene restituita in lettura e non CloudFormation rileverà la deriva se la CA attiva cambia all'esterno CloudFormation (ad esempio, tramite l'attivazione automatica da parte di). AWS

Importante: l' CloudFormation integrazione della rotazione della CA segue uno schema diverso rispetto alle risorse tipiche CloudFormation . Un'autorità di certificazione in EKS non è una risorsa indipendente con un proprio ARN. Esiste come parte del ciclo di vita del certificato del cluster ed è autorizzata tramite il cluster stesso, in modo simile a come una policy di ruolo IAM è autorizzata tramite il ruolo principale (AWS::IAM::RolePolicy) o un'associazione EIP è autorizzata tramite la sua istanza (). AWS::EC2::EIPAssociation I clienti che gestiscono la rotazione tramite CA CloudFormation devono essere consapevoli di questa distinzione.

Gruppi di nodi gestiti e IaC

L'esecuzione di un aggiornamento della versione del gruppo di nodi per aggiornare i nodi con la configurazione CA trust aggiornata è un'azione operativa. I nuovi nodi si avviano automaticamente con i dati di trust CA attivi dal cluster. Se i modelli IaC non codificano i dati CA nei modelli di avvio o nei dati utente, non sono necessarie modifiche al modello.

Rollback CA

Dopo aver attivato una CA successore, puoi eseguire il rollback alla CA precedente se rilevi problemi di connettività con i nodi di lavoro che gestisci (modalità automatica non EKS, non Fargate) o client esterni. Il rollback riattiva la CA precedente come autorità di firma per il cluster EKS.

Quando il rollback di CA è disponibile

Il rollback CA è disponibile dopo l'attivazione di CA a condizione che:

Puoi verificare se il rollback di CA è disponibile in qualsiasi momento utilizzando il rollbackAvailable campo restituito da: describe-certificate-authority

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

Quando il rollback di CA non è disponibile

Il rollback di CA non è disponibile dopo l'attivazione automatica finale. Se AWS attiva la CA successore per l'ultima volta (45 giorni prima della scadenza della CA), la rotazione deve procedere in avanti. L'attivazione automatica finale si verifica solo se la prima attivazione automatica è stata precedentemente annullata. Esiste come ultima risorsa di protezione per garantire che il cluster EKS non raggiunga la scadenza della CA senza una CA valida.

Come eseguire il rollback

Per eseguire il rollback, riattiva la CA precedente:

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

Cosa succede durante il rollback della CA

Quando prendere in considerazione il rollback di CA

Il rollback di CA è un meccanismo di sicurezza per le situazioni in cui l'attivazione della CA successiva rivela un problema di connettività che non hai rilevato in precedenza:

Dopo il rollback, viene mantenuto l'intero periodo di dual trust per identificare e risolvere il problema prima di riattivare la CA successiva.

Ripristino senza rollback della CA

Se si attiva la CA successiva prima di aggiornare i gruppi di nodi gestiti e la finestra di rollback della CA non è più disponibile (ad esempio, dopo la scadenza finale per l'attivazione automatica), è possibile eseguire il ripristino eseguendo un aggiornamento continuo sui gruppi di nodi interessati. Tuttavia, il tentativo iniziale di aggiornamento progressivo fallirà perché i nodi disconnessi non possono ricevere comandi di rimozione dei pod dal server API.

Fasi di ripristino

Considerazioni e limitazioni

Disponibilità regionale

La rotazione CA è disponibile in tutte le regioni AWS commerciali in cui Amazon EKS è supportato.

Massimo due CA

Un cluster EKS può avere al massimo due CA in qualsiasi momento: la CA attiva e una successore. Non è possibile aggiungere una seconda CA successore fino al completamento della rotazione precedente.

Nessuna revoca del certificato

La rotazione CA non supporta la revoca di singoli certificati. Ciò è coerente con Kubernetes a monte, che non implementa la revoca dei certificati (CRL o OCSP). La rotazione sostituisce l'intera CA, che naturalmente invalida tutti i certificati firmati dalla CA in uscita dopo che è stata rimossa dal trust bundle.

AWS-le CA aggiunte non possono essere eliminate

Se AWS viene aggiunta automaticamente una CA successore, non è possibile eliminarla. Questa protezione garantisce che il processo di rotazione non possa essere interrotto da un'eliminazione accidentale. Customer-appended Le CA possono essere eliminate purché non siano la CA di firma attiva.

Periodo di validità della CA

La CA originale creata con il cluster ha un periodo di validità di 10 anni. Le CA successive create tramite il processo di rotazione hanno periodi di validità di 5 anni. Tutte le CA future per il cluster seguiranno il periodo di validità di 5 anni. Verifica la scadenza della CA utilizzando. describe-certificate-authority

Dimensione dei dati utente EC2 durante il dual trust

Durante il periodo di doppia fiducia, il trust bundle del cluster aumenta di dimensioni a causa della presenza di due certificati CA (circa 2,8 KB combinati o circa 1,9 KB con compressione gzip). Per i nodi di lavoro in cui vengono forniti dati utente personalizzati nei modelli di avvio EC2, verifica che la dimensione totale dei dati utente non superi il limite dei dati utente EC2 di 16 KB. Se i dati utente esistenti sono vicini a questo limite, l'aggiunta di una seconda CA potrebbe causare il fallimento della creazione del modello di avvio e impedire il provisioning di nuovi nodi. Valuta la possibilità di comprimere il contenuto dei dati utente utilizzando gzip per ridurne le dimensioni.

Aggiornamenti della versione durante la rotazione della CA

Gli aggiornamenti della versione del cluster EKS e la rotazione della CA sono operazioni indipendenti. Tuttavia, non è possibile eseguire entrambe le operazioni contemporaneamente. Se è in corso un'operazione di rotazione della CA, l'aggiornamento della versione verrà rifiutato fino al completamento dell'operazione CA e viceversa.

Porta la tua CA (BYOCA)

L'utilizzo della propria CA AWS privata per il backup dei certificati del cluster EKS non è attualmente supportato.

Domande frequenti

Come posso iniziare con la rotazione di CA?

Per iniziare, corri aws eks list-certificate-authorities --cluster-name my-cluster per visualizzare la CA attiva e la sua scadenza. Se sei pronto per iniziare la rotazione, corri aws eks create-certificate-authority --cluster-name my-cluster ad aggiungere una CA successore. La procedura dettagliata completa è descritta nella sezione Guida introduttiva. Puoi anche eseguire la rotazione della CA tramite la console Amazon EKS.

Sono previsti costi associati alla rotazione della CA?

No La rotazione CA è disponibile senza costi aggiuntivi per tutti i cluster EKS.

Cosa succede se non faccio ruotare la mia CA prima che scada?

Disponiamo di protezioni automatiche che impediscono al cluster EKS di raggiungere la scadenza della CA senza una CA valida. Se non avvii tu stesso la rotazione delle CA, aggiungeremo e attiveremo automaticamente una CA successore prima della scadenza, assicurando che il cluster rimanga disponibile.

Tuttavia, una rotazione corretta richiede anche l'aggiornamento dei nodi di lavoro gestiti (modalità automatica non EKS, non Fargate) e i client esterni affinché si fidino della CA successore. Se questi componenti non vengono aggiornati prima dell'attivazione della CA successore, perderanno la connettività al server API.

In Kubernetes, se una CA non viene ruotata prima della scadenza, tutti i certificati firmati da tale CA diventano non validi. Il server API non può più essere raggiunto da nessun client e il cluster diventa non disponibile.

Quanto tempo ho a disposizione per completare la rotazione della CA?

Il tempo complessivo necessario per completare la rotazione della CA dipende sia dalle misure di protezione AWS automatizzate che dal processo di aggiornamento personalizzato.

AWS fornisce tempistiche definitive per ciò che gestisce. Una CA successore viene aggiunta circa 2 anni prima della scadenza della CA in uscita. Se non attivi tu stesso la CA successore, la attiveremo automaticamente circa 6 mesi prima della scadenza. Se effettui il rollback dopo l'attivazione automatica, eseguiremo un'attivazione automatica definitiva 45 giorni prima della scadenza. Queste misure di sicurezza assicurano che il cluster EKS rimanga disponibile indipendentemente dal fatto che tu agisca.

Una corretta rotazione delle CA dipende anche dall'aggiornamento dei nodi di lavoro gestiti (modalità automatica non EKS, non Fargate) e dai client esterni affinché si fidino della CA successore prima dell'attivazione della CA successore. Il tempo necessario dipende dalla configurazione del nodo di lavoro del piano dati, dall'impronta del client esterno e dal tempo necessario per eseguire l'individuazione e gli aggiornamenti di questi componenti.

La rotazione della CA causa tempi di inattività del mio cluster?

No. Il cluster EKS rimane disponibile per l'intero ciclo di vita di rotazione di CA. Il piano di controllo continua a soddisfare le richieste in ogni fase. Durante il periodo di doppia fiducia, sia le CA in uscita che quelle successive vengono considerate attendibili contemporaneamente, consentendo l'aggiornamento incrementale dei componenti senza interrompere le operazioni del cluster. Se si esegue il rollback alla CA precedente a causa di problemi sul lato client, AWS esegue un rollforward finale circa 45 giorni prima della scadenza della CA in uscita a titolo di salvaguardia.

È importante distinguere tra il cluster EKS (piano di controllo) e i componenti del piano dati. Il piano di controllo è completamente gestito da AWS e rimane disponibile per tutta la rotazione.

Per EKS Auto Mode e Fargate, AWS aggiorna automaticamente i nodi di lavoro. Non vi è alcun rischio di perdita di connettività per i nodi di lavoro in queste modalità di avvio del piano dati. Sei comunque responsabile dell'aggiornamento di tutti i client esterni che si connettono al server API.

Per i gruppi di nodi gestiti, i nodi autogestiti, Karpenter-controlled le istanze (senza il rilevamento della deriva abilitato) e i nodi ibridi, sei responsabile della sostituzione o dell'aggiornamento di tali nodi prima dell'attivazione della CA successore. Se non vengono sostituiti, tali nodi perderanno la connettività al piano di controllo dopo l'attivazione della CA successiva, anche se il piano di controllo stesso rimane completamente operativo.

I miei carichi di lavoro verranno interrotti durante la rotazione della CA?

I carichi di lavoro in esecuzione (pod) non vengono interrotti dalla rotazione di CA stessa. I pod comunicano tra loro attraverso la rete del cluster, che non è interessata da una modifica della CA. La CA viene utilizzata per la comunicazione tra i componenti e il server API, non per il traffico pod-to-pod.

Se i nodi di lavoro devono essere sostituiti come parte dell'aggiornamento per rendere attendibili la CA successore (ad esempio, gruppi di nodi gestiti che eseguono un aggiornamento progressivo o Karpenter che sostituisce i nodi deviati), i pod su tali nodi verranno riprogrammati come parte del normale processo di sostituzione dei nodi. Questo è il comportamento standard di Kubernetes durante la sostituzione dei nodi, non un effetto collaterale della rotazione della CA. Assicurati di avere i Pod Disruption Budgets (PDB) configurati per i carichi di lavoro critici per controllare in che modo i pod vengono eliminati durante la sostituzione dei nodi.

Quando scadrà la CA del mio cluster?

Puoi verificare quando scade la CA del tuo cluster utilizzando la AWS CLI, le API EKS o la console Amazon EKS. Ad esempio, puoi eseguire quanto segue:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

Puoi trovare l'ID della tua CA eseguendoaws eks list-certificate-authorities --cluster-name my-cluster.

Qual è il periodo di validità della CA del mio cluster?

La CA originale creata con il cluster ha un periodo di validità di 10 anni. Le CA successive create tramite il processo di rotazione hanno periodi di validità di 5 anni. Tutte le CA future per il cluster seguiranno il periodo di validità di 5 anni. Puoi verificare la scadenza della tua CA utilizzando. describe-certificate-authority

Posso avviare personalmente una rotazione della CA prima AWS lo fa automaticamente?

Sì. È possibile aggiungere una CA successore in qualsiasi momento utilizzando. aws eks create-certificate-authority --cluster-name my-cluster Non è necessario attendere l'inizio della AWS rotazione. Iniziare in anticipo ti dà più tempo per identificare e aggiornare i nodi di lavoro e i clienti esterni secondo i tuoi orari.

Posso eseguire il rollback dopo aver attivato una CA successiva?

Sì, il rollback della CA è disponibile dopo l'attivazione della CA successore purché la finestra di rollback non sia scaduta. CA rollback riattiva la CA precedente come autorità di firma. Non è disponibile dopo l'attivazione automatica finale (45 giorni prima della scadenza della CA). Puoi controllare il rollbackAvailable campo sulla tua CA utilizzandodescribe-certificate-authority. Per i dettagli, consulta la sezione CA Rollback.

Come faccio a sapere se è sicuro attivare la CA successiva?

L'attivazione della CA successore è sicura quando tutti i nodi di lavoro gestiti (modalità automatica non EKS, non Fargate) e i client esterni sono stati aggiornati in modo da considerare attendibili la CA successore. È possibile verificarlo confermando che ogni client può comunicare correttamente con il server API utilizzando la configurazione di trust aggiornata. AWS non fornisce un solo indicatore che indichi che tutti i client sono pronti, in quanto non è in grado di visualizzare i sistemi esterni. Iniziate il processo di scoperta in anticipo per avere il tempo di identificare tutti i clienti.

Come posso monitorare l'avanzamento della rotazione della CA su più cluster?

È possibile eseguire questa operazione a livello di programmazione utilizzando la AWS CLI o l'API EKS. Usa per ogni clusteraws eks list-certificate-authorities. I seguenti campi forniscono la consapevolezza della situazione per il monitoraggio a livello di flotta:

Il seguente script di esempio verifica lo stato di rotazione della CA in un elenco di cluster:

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

Puoi estenderlo per coprire più regioni e account e filtrare i cluster a cui è stata aggiunta una CA successore, in attesa di intervento o che si stanno avvicinando alle scadenze di attivazione automatica.

Le notifiche vengono inoltre inviate per cluster tramite AWS Health ed e-mail in ogni fase del ciclo di vita della rotazione.

Cosa succede se attivo la CA successiva prima di aggiornare tutti i miei clienti?

Qualsiasi client che non è stato aggiornato per considerare attendibile la CA successore perderà la connettività al cluster EKS. Dopo l'attivazione della CA successore, il server API presenta i certificati firmati dalla CA successore. I client che non si fidano di essa falliranno la verifica TLS e non saranno in grado di connettersi. In tal caso, puoi ripristinare la CA precedente (se la finestra di rollback è ancora disponibile) per ripristinare la connettività mentre correggi i client rimanenti.

Cosa succede se non raggiungo la scadenza della CA?

AWS impedisce che ciò accada. Le protezioni automatiche assicurano che il cluster EKS non raggiunga la scadenza della CA senza una CA valida. Se non l'hai fatto, aggiungeremo una CA successore e la attiveremo automaticamente circa 6 mesi prima della scadenza. Se effettui il rollback dopo la prima attivazione automatica, AWS esegue un rollforward definitivo 45 giorni prima della scadenza. Il tuo cluster rimarrà disponibile.

Tuttavia, se i nodi di lavoro gestiti (modalità automatica non EKS, non Fargate) e i client esterni non sono stati aggiornati in modo da considerare attendibili la CA successore al momento dell'attivazione automatica, tali componenti perderanno la connettività al server API.

Posso perdere l'accesso al mio cluster durante la rotazione della CA?

Il cluster EKS (piano di controllo) rimane disponibile per l'intero ciclo di vita di rotazione di CA. AWS le misure di protezione assicurano che il cluster stesso non diventi non disponibile.

Tuttavia, i singoli client gestiti possono perdere l'accesso se non vengono aggiornati in modo da considerare attendibili la CA successore prima dell'attivazione della CA successore. Ad esempio, se kubeconfig, CI/CD pipeline o strumento di monitoraggio fanno ancora riferimento solo alla CA in uscita, tali client non saranno in grado di connettersi dopo l'attivazione della CA successore. In tal caso, CA rollback può ripristinare l'accesso mentre si aggiornano i client interessati.

Devo riavviare i miei pod?

L'esecuzione dei workload pod non è direttamente influenzata dalla rotazione delle CA. Il kubelet su ogni nodo gestisce le comunicazioni con il server API, quindi i workload pod continueranno a funzionare senza interruzioni finché i nodi saranno aggiornati. Tuttavia, i controller e gli operatori interni al cluster che utilizzano client-go per comunicare con il server API potrebbero dover essere riavviati dopo l'attivazione della CA successore, poiché client-go non rilegge dinamicamente il CA trust bundle. Per i nodi AWS Fargate, in particolare, gestisce l'aggiornamento automaticamente attraverso il naturale processo di riciclo dei pod. AWS

Il mio pacchetto di fiducia cambierà durante la rotazione?

Sì. Durante la rotazione delle CA, il trust bundle del cluster conterrà contemporaneamente due autorità di certificazione: la CA in uscita e la CA successore. Questo è il comportamento previsto durante il periodo di dual trust ed è il modo in cui il processo di rotazione mantiene la connettività per tutti i componenti.

Le applicazioni e i client devono essere configurati in modo da considerare attendibili un pacchetto CA anziché aggiungere un singolo certificato CA. Il pinning CA (convalida rigorosa rispetto a una singola CA) non è consigliato, poiché causerà errori quando il trust bundle viene aggiornato. Questo vale per qualsiasi configurazione TLS sul lato client che si connette al server API del cluster EKS.

Perché la tempistica delle mie notifiche è diversa da quella descritta in questa documentazione?

Se il cluster è stato creato nel 2018-2019, riceverà notifiche automatiche con una tempistica modificata. La prima notifica includerà le date pertinenti e i passaggi successivi specifici del cluster. I traguardi di notifica standard vengono calcolati in relazione alla data di scadenza della CA del cluster. Per i cluster in questo intervallo, le date calcolate precedono la disponibilità di questa funzionalità, pertanto viene applicata una pianificazione modificata.