Applicazione automatica degli aggiornamenti di sicurezza per AWS Elastic Beanstalk

Sono stato un fan di Heroku fin dai suoi primi giorni. Ma mi piace il fatto che AWS Elastic Beanstalk ti dia un maggiore controllo sulle caratteristiche delle istanze. Una cosa che amo di Heroku è il fatto che posso distribuire un'app e non preoccuparmi di gestirla. Sto assumendo Heroku è garantire tutti gli aggiornamenti di sicurezza del sistema operativo sono tempestivamente applicate. Devo solo assicurarmi che la mia app sia sicura.

La mia ricerca iniziale su Beanstalk mostra che sebbene costruisca e configura le istanze per te, dopodiché passa a un processo di gestione più manuale. Gli aggiornamenti di sicurezza non verranno applicati automaticamente alle istanze. Sembra che ci siano due aree di preoccupazione:

• Nuove versioni AMI - Quando arrivano le nuove versioni AMI sembra che vorremmo eseguire l'ultima versione (presumibilmente più sicura). Ma la mia ricerca sembra indicare che è necessario avviare manualmente una nuova configurazione per vedere l'ultima versione di AMI e quindi creare un nuovo ambiente per utilizzare quella nuova versione . Esiste un modo automatizzato migliore per trasformare le tue istanze in nuove versioni AMI?
• Tra le versioni ci saranno aggiornamenti di sicurezza rilasciati per i pacchetti. Sembra che vogliamo aggiornare anche quelli. La mia ricerca sembra indicare che le persone installano comandi per eseguire occasionalmente un aggiornamento yum. Ma poiché le nuove istanze vengono create / distrutte in base all'utilizzo, sembra che le nuove istanze non abbiano sempre gli aggiornamenti (ovvero il tempo che intercorre tra la creazione dell'istanza e il primo aggiornamento yum). Di tanto in tanto avrai istanze che non sono patchate. E avrai anche istanze che si sistemano costantemente fino a quando non viene applicata la nuova versione AMI. L'altra mia preoccupazione è che forse questi aggiornamenti di sicurezza non sono stati sottoposti alla recensione di Amazon (come fanno le versioni AMI) e potrebbe interrompere la mia app per aggiornarli automaticamente. So che Dreamhost ha subito un'interruzione di 12 ore perché stavano applicando gli aggiornamenti debian in modo completamente automatico senza alcuna revisione. Voglio assicurarmi che non succeda la stessa cosa.

Quindi la mia domanda è: Amazon fornisce un modo per offrire PaaS completamente gestiti come Heroku? Oppure AWS Elastic Beanstalk è davvero più di uno script di installazione e successivamente sei da solo (oltre agli strumenti di monitoraggio e distribuzione che forniscono)?

Prima di tutto, per essere chiari, nessun Elastic Beanstalk non è PaaS nel modo in cui ci stai pensando. Se lo fai a pezzi, è molto più simile ad avere modelli di istanze virtualizzati e automazione della distribuzione delle applicazioni come pupazzi o chef. Insieme a questo si ottiene l'accesso automatico al servizio di bilanciamento del carico di timore reverenziale e al monitoraggio del cloud watch, che consente di avviare nuovi server delle applicazioni o arrestare quelli esistenti in base alle metriche.

Ciò che sembra PaaS è che il principale punto di forza è il sistema di distribuzione delle applicazioni che prende il tuo codice e lo copia su tutti i server delle applicazioni nel tuo cluster.

Una delle lamentele che alcune persone hanno su PaaS è che il fornitore PaaS prende le decisioni sull'ambiente dell'applicazione. Questa mi sembra la proposta di valore di PaaS: come cliente puoi concentrarti sulla funzionalità dell'applicazione e lasciare tutti gli altri dettagli al venditore PaaS. Stai pagando che qualcun altro gestisca l'infrastruttura e fornisca l'amministrazione del sistema. Per quella semplicità stai pagando loro un premio, come nel caso di Heroku, che gestisce anche la loro infrastruttura su ec2, solo in modo trasparente per te.

Amazon sta davvero offrendo Elastic Beanstalk oltre a Ec2 e le loro API REST, e non sta facendo uno sforzo per nasconderlo. Questo perché stanno guadagnando i loro soldi tramite IaaS ed EB sta solo orchestrando la configurazione di un gruppo di risorse ec2 che potresti impostare tu stesso, dato il tempo e il know how.

Ora, in termini di specificità di un AMI, ancora una volta gli AMI sono uno dei tanti pezzi di ec2 impiegati per facilitare l'EB. Non c'è nulla di magico in un AMI EB: è solo un AMI Amazon Linux preconfigurato per funzionare con EB. Come qualsiasi altra AMI, puoi avviarla in EC2, modificarla e ricavare una nuova AMI personalizzata dalla tua istanza in esecuzione. Amazon Linux è fondamentalmente un incrocio tra Centos e Fedora, con patch di paravirtualizzazione e repository yum preconfigurati gestiti da Amazon.

Come probabilmente saprai, Amazon Linux è già configurato per installare patch di sicurezza all'avvio. Tuttavia, le istanze in esecuzione non sono diverse rispetto a qualsiasi altro server per quanto riguarda le patch. Il patching potrebbe interrompere il servizio. Se sei estremamente preoccupato per le patch di sicurezza, puoi sempre usare un comando container e impostare cron per eseguire l'aggiornamento yum - sicurezza con una certa periodicità.

È inoltre possibile utilizzare l'API EB per modificare la configurazione EB o automatizzare la creazione di un nuovo ambiente EB, quindi è possibile scambiarlo una volta che è attivo e pronto, seguito dallo spegnimento di quello precedente. Questo è descritto qui: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

Come il resto di AWS, esiste un modo per accedere e controllare a livello di programmazione tutte le funzionalità non SaaS, quindi non c'è nulla che ti impedisca di creare AMI con patch, che vengono quindi utilizzati per creare nuovi ambienti EB e implementarli. EB non ti imporrà specifiche di configurazione, né ti fornirà un gruppo di amministrazione del sistema per mantenere l'infrastruttura.

Ad aprile 2016, Elastic Beanstalk supporta gli aggiornamenti automatici della piattaforma:

https://aws.amazon.com/about-aws/whats-new/2016/04/aws-elastic-beanstalk-introduces-managed-platform-updates/

Tutte le applicazioni e gli ambienti Beanstalk possono essere configurati tramite i file EBEXTENSIONS che sono impacchettati con il pacchetto di distribuzione dell'applicazione (ad es. File WAR per le app Java) con configurazione basata su YAML per aggiornare o riconfigurare qualsiasi parte dell'applicazione, contenitore, sistema operativo ecc. Beanstalk è PaaS poiché è una piattaforma che consente di distribuire applicazioni senza doversi preoccupare dello IaaS sottostante. Tutti i fornitori di PaaS alla fine della giornata offuscano lo IaaS sottostante attraverso una qualche forma di automazione. Tuttavia, poiché si tratta dell'informatica di cui stiamo parlando, non esiste un unico stato ottimale per tutte le applicazioni e senza la possibilità di modificare lo IaaS nell'ambito del PaaS, siete in balia del fornitore di servizi PaaS per assicurarvi che le vostre applicazioni funzionino senza problemi, veloce e sicuro.

Heroku funziona su AWS usando un diverso livello di gestione. Tuttavia, diventa un dolore nel culo quando devi fare cose come proteggere la tua applicazione. Mentre fanno il possibile per gestire la soluzione in modo efficiente e mantenere la sicurezza, ecc., Non possono e non si assumeranno il rischio e le conseguenze di una vulnerabilità nella tua app alla fine della giornata. Vogliono rendere i loro servizi il più semplice possibile.

La capacità di modificare l'IaaS alla base della piattaforma è un punto di forza e un fascino di Beanstalk IMO.