Aplicación automática de actualizaciones de seguridad para AWS Elastic Beanstalk

He sido fanático de Heroku desde los primeros días. Pero me gusta el hecho de que AWS Elastic Beanstalk le brinda más control sobre las características de las instancias. Una cosa que me encanta de Heroku es el hecho de que puedo implementar una aplicación y no preocuparme por administrarla. Estoy asumiendo Heroku es asegurar todas las actualizaciones de seguridad del sistema operativo se aplican oportuna. Solo necesito asegurarme de que mi aplicación sea segura.

Mi investigación inicial sobre Beanstalk muestra que aunque construye y configura las instancias para usted, luego pasa a un proceso de administración más manual. Las actualizaciones de seguridad no se aplicarán automáticamente a las instancias. Parece que hay dos áreas de preocupación:

• Nuevos lanzamientos de AMI: a medida que llegan los nuevos lanzamientos de AMI, parece que queremos ejecutar la última versión (presumiblemente la más segura). Pero mi investigación parece indicar que necesita iniciar manualmente una nueva configuración para ver la última versión de AMI y luego crear un nuevo entorno para usar esa nueva versión . ¿Existe una mejor manera automatizada de rotar sus instancias en nuevas versiones de AMI?
• Entre lanzamientos habrá actualizaciones de seguridad lanzadas para paquetes. Parece que también queremos actualizarlos. Mi investigación parece indicar que las personas instalan comandos para ejecutar ocasionalmente una actualización yum. Pero dado que las nuevas instancias se crean / destruyen en función del uso, parece que las nuevas instancias no siempre tendrían las actualizaciones (es decir, el tiempo entre la creación de la instancia y la primera actualización de yum). Así que ocasionalmente tendrás instancias que no están parcheadas. Y también tendrá instancias parchándose constantemente hasta que se aplique la nueva versión de AMI. Mi otra preocupación es que tal vez estas actualizaciones de seguridad no hayan pasado por la propia revisión de Amazon (como lo hacen los lanzamientos de AMI) y podría romper mi aplicación para actualizarlas automáticamente. Sé que Dreamhost tuvo una interrupción de 12 horas porque aplicaban actualizaciones de Debian de forma completamente automática sin ninguna revisión. Quiero asegurarme de que no me pase lo mismo.

Entonces, mi pregunta es ¿Amazon proporciona una manera de ofrecer PaaS totalmente administrado como Heroku? ¿O es AWS Elastic Beanstalk realmente más que un simple script de instalación y después de eso usted está solo (aparte de las herramientas de monitoreo e implementación que proporcionan)?

En primer lugar, para ser claros, no Elastic Beanstalk no es PaaS en la forma en que lo piensas. Si lo divide en pedazos, es realmente más como tener plantillas de instancias virtualizadas y automatización de implementación de aplicaciones como títeres o chef. Junto con esto, obtienes acceso automatizado al asombroso servicio de equilibrador de carga y monitoreo de vigilancia en la nube, que te permite iniciar nuevos servidores de aplicaciones o cerrar los existentes en función de las métricas.

Lo que lo hace sentir como PaaS es que el principal punto de venta es el sistema de implementación de aplicaciones que toma su código y lo copia a todos los servidores de aplicaciones en su clúster.

Una de las quejas que algunas personas tienen sobre PaaS es que el proveedor de PaaS toma decisiones por usted sobre el entorno de la aplicación. Esto me parece la propuesta de valor de PaaS: como cliente, puede concentrarse en la funcionalidad de la aplicación y dejar todos los demás detalles al proveedor de PaaS. Estás pagando por alguien más para administrar la infraestructura y proporcionar la administración del sistema. Por esa simplicidad, les está pagando una prima, como en el caso de Heroku, que también está ejecutando su infraestructura sobre ec2, solo de una manera que sea transparente para usted.

Amazon realmente está ofreciendo Elastic Beanstalk sobre Ec2 y sus API REST, y no está haciendo un gran esfuerzo para ocultarlo. Esto se debe a que están ganando dinero a través de IaaS, y EB solo está organizando la configuración de un grupo de recursos ec2 que podría configurar usted mismo, dado el tiempo y los conocimientos.

Ahora, en términos de las características específicas de un AMI, nuevamente los AMI son una de las muchas piezas ec2 que se emplean para facilitar la EB. No hay nada mágico en un EB AMI: es solo un Amazon Linux ami preconfigurado para trabajar con EB. Al igual que cualquier otra AMI, puede iniciarla en EC2, modificarla y derivar una nueva AMI personalizada de su instancia en ejecución. Amazon Linux es básicamente un cruce entre Centos y Fedora, con parches de paravirtualización y repositorios yum preconfigurados mantenidos por Amazon.

Como probablemente sepa, Amazon Linux ya está configurado para instalar parches de seguridad en el momento del arranque. Sin embargo, las instancias en ejecución no son diferentes a cualquier otro servidor en lo que respecta a parches. Los parches pueden interrumpir el servicio. Si está extremadamente preocupado por los parches de seguridad, siempre puede usar un comando contenedor y configurar cron para ejecutar yum update --seguridad con cierta periodicidad.

También puede utilizar la API de EB para alterar la configuración de EB o automatizar la creación de un nuevo entorno de EB, luego puede cambiar a él una vez que esté listo y listo, seguido de apagar el anterior. Esto se describe aquí: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

Al igual que el resto de AWS, hay una manera de acceder y controlar mediante programación todas las funciones que no son SaaS, por lo que no hay nada que le impida crear AMI parcheados, que luego se utilizan para crear nuevos entornos EB y desplegarlos. EB no va a forzar detalles de configuración sobre usted, ni le está proporcionando un grupo de administración del sistema para mantener la infraestructura.

A partir de abril de 2016, Elastic Beanstalk admite actualizaciones automáticas de plataforma:

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

Todas las aplicaciones y entornos de Beanstalk se pueden configurar a través de archivos EBEXTENSIONS que se empaquetan con el paquete de implementación de su aplicación (por ejemplo, archivo WAR para aplicaciones Java) con configuración basada en YAML para actualizar o reconfigurar cualquier parte de su aplicación, contenedor, sistema operativo, etc. Beanstalk es PaaS ya que es una plataforma que le permite implementar aplicaciones sin tener que preocuparse por el IaaS subyacente. Todos los proveedores de PaaS al final del día ofuscan el IaaS subyacente a través de alguna forma de automatización. Sin embargo, dado que estamos hablando de informática, no existe un único estado óptimo para todas las aplicaciones y sin la capacidad de ajustar IaaS bajo PaaS, usted está a merced del proveedor de servicios de PaaS para garantizarle que sus aplicaciones funcionen sin problemas, Rápido y seguro.

Heroku se ejecuta sobre AWS usando una capa de administración diferente, eso es todo. Sin embargo, se convierte en una molestia cuando tienes que hacer cosas como asegurar tu aplicación. Si bien hacen los mejores esfuerzos para administrar su solución de manera eficiente y mantener la seguridad, etc., no pueden asumir el riesgo y las consecuencias de una vulnerabilidad en su aplicación al final del día. Quieren que sus servicios sean lo más cortadores posible.

La capacidad de modificar IaaS subyacente a la plataforma es una fortaleza y un atractivo de Beanstalk IMO.