Gestione delle modifiche

Questo documento delinea le migliori pratiche per introdurre modifiche alle configurazioni dei servizi edge di AWS come CloudFront, Lambda@Edge e AWS WAF. Queste modifiche possono includere l'aggiornamento del codice CloudFront Function, la modifica del runtime di una funzione Lambda@Edge, l'aggiunta di un nuovo comportamento della cache in CloudFront, l'aggiornamento delle regole WAF o l'abilitazione di nuove funzionalità di CloudFront come HTTP/3. Se disponi di configurazioni relativamente statiche e semplici e preferisci un'interfaccia utente per la gestione manuale, puoi fare affidamento sulla Console AWS. Tuttavia, per configurazioni più complesse, si consiglia di sfruttare le pipeline CI/CD per implementare le modifiche alla configurazione e gli aggiornamenti del codice in modo controllato.

Le pipeline CI/CD migliorano i cicli di rilascio del software aumentando la velocità di sviluppo, offrendo una maggiore qualità del codice e riducendo gli errori umani grazie all'automazione. I servizi edge di AWS come CloudFront e le funzioni edge possono essere gestiti in una pipeline CI/CD utilizzando Infrastructure as code (IaC). Le risorse edge possono essere distribuite tramite API (ad esempio l'API di CloudFront), la CLI di AWS o strumenti di astrazione di livello superiore come CloudFormation, Terraform e AWS Cloud Development Kit (CDK).

Il CDK, basato su CloudFormation, offre il massimo livello di astrazione consentendo di distribuire risorse AWS utilizzando un linguaggio di programmazione. Ad esempio, le seguenti tre righe di codice JavaScript possono distribuire un bucket S3 con CloudFront come origine:

Dai un'occhiata alla libreria di costrutti CDK per i costrutti riutilizzabili da includere nel tuo codice CDK.

Nella pipeline CI/CD, è necessario un repository come AWS CodeCommit per archiviare il codice (codice CDK, codice delle funzioni edge), uno strumento come AWS CodeDeploy per distribuire l'infrastruttura e uno strumento di orchestrazione come AWS CodePipeline per gestire le fasi della pipeline CI/CD. Questo post del blog dimostra l'utilizzo degli strumenti di sviluppo AWS per implementare una pipeline CI/CD per CloudFront, ma puoi anche utilizzare i tuoi strumenti CI/CD preferiti. Considera le seguente limitazioni quando crei la pipeline CI/CD per i servizi AWS Edge:

• CloudFront, Funzioni CloudFront e AWS WAF WebACL regionali possono essere distribuiti da qualsiasi Regione AWS
• Lambda@Edge e WAF WAF WebACL for CloudFront possono essere distribuiti solo dalla regione us-east-1 in nord Virginia.
• Le policy di Firewall Manager devono essere distribuite nell'account AWS dell'amministratore di Firewall Manager

La configurazione edge può essere testata a diversi livelli. Innanzitutto, si può replicare l'infrastruttura, ad esempio una distribuzione CloudFront con AWS WAF WebACL negli account di prova. Questa operazione potrebbe essere svolta durante la fase di sviluppo o per eseguire test funzionali automatici prima di passare alla produzione. Tieni presente che non puoi utilizzare due distribuzioni CloudFront con lo stesso CNAME. Di conseguenza, è necessario differenziare la configurazione CNAME per la tua risorsa CloudFront in base alla fase CI/CD. Ad esempio, puoi utilizzare il nome di dominio di CloudFront (xyz.cloudfront.net) per la fase di sviluppo, quindi un CNAME dedicato per lo staging (staging.www.example.com) e, infine, il CNAME pubblico per l'implementazione in produzione (per esempio www.example.com). È possibile anche differenziare i controlli di sicurezza per fase, ad esempio limitando l'accesso a IP specifici utilizzando AWS WAF per la fase di staging.

Dopo che la nuova configurazione supera le fasi di test, è possibile implementare un approccio di rilascio canary utilizzando la funzionalità di implementazione continua di CloudFront per testare la modifica della produzione su una piccola parte del traffico. Utilizzando questa funzionalità, è possibile creare una configurazione diversa della distribuzione di produzione e inviare solo una parte del traffico globale. Sono disponibili due possibilità per indirizzare il traffico alla nuova configurazione: utilizzando un'intestazione di richiesta specifica, utile per i test sintetici, o utilizzando una politica ponderata per indirizzare una percentuale configurabile di traffico alla nuova configurazione, con l'opzione di abilitare la permanenza. Nella versione attuale di questa funzionalità, puoi testare le modifiche solo su un sottoinsieme di parametri della configurazione di CloudFront. Leggi la documentazione per capire meglio cosa puoi testare usando questa funzionalità.

Consideriamo uno scenario in cui più team introducono modifiche alla configurazione di CloudFront, ma un solo team gestisce la pipeline CI/CD per tutti i team. Un esempio potrebbe essere lo scenario in cui diversi team gestiscono microservizi diversi, esponendo tutti le proprie API sul dominio principale ospitato da una singola distribuzione CloudFront. Se si consente a ciascun team di accedere alla configurazione completa della distribuzione CloudFront, si aumenta il raggio di esplosione di una singola modifica non valida. Dall'altro lato, se si consente solo al team CI/CD di apportare modifiche alla distribuzione CloudFront, si riduce la velocità di sviluppo e si introduce un collo di bottiglia nel ciclo di vita del rilascio. Invece, è possibile generare la configurazione in modo dinamico sulla base di configurazioni parziali di proprietà di ciascun team di microservizi. In una implementazione semplice, ogni team gestisce la configurazione del proprio percorso (caching, funzioni edge, ecc.) in un file di testo ospitato in un bucket S3. Nella pipeline CI/CD, è possibile introdurre un passaggio aggiuntivo per creare dinamicamente la configurazione finale di CloudFront utilizzando i diversi file di configurazione parziale.

I servizi Shield e WAF possono essere implementati, utilizzando gli stessi strumenti descritti in precedenza, in una pipeline CI/CD.

Tuttavia, si consiglia di utilizzare la Gestione dei firewall AWS per implementare regole WAF e protezioni Shield per i seguenti vantaggi:

• Facilita l'applicazione di una governance di sicurezza centralizzata (ad esempio l'implementazione di regole centrali in combinazione con regole gestite dai team applicativi)
• Offre un'implementazione più rapida, fondamentale per correggere le vulnerabilità critiche utilizzando AWS WAF.
• Semplifica l'implementazione tra account e pipeline CI/CD eterogenee (ad esempio, ereditate dalle acquisizioni). Tuttavia, con questo approccio, è necessario gestire la deriva se si utilizza una pipeline CI/CD con rilevamento della deriva.

Inoltre, è possibile utilizzare, come dimostrato da OLX, una pipeline CI/CD per apportare modifiche alle politiche di Firewall Manager nell'account amministratore, che verrà distribuito nell'organizzazione AWS da Firewall Manager.

L'implementazione sicura delle regole WAF nella produzione può essere eseguita utilizzando diverse strategie. È possibile aggiungere nuove regole a un WebACL esistente in modalità conteggio e quindi modificarlo in modalità blocco. Tuttavia, con questo approccio, è necessario prestare attenzione alla WCU massima del WebACL. Un altro approccio consiste nell'implementare le modifiche a un WebACL di staging e testare le modifiche in un ambiente di staging.