Aplicação automática de atualizações de segurança ao AWS Elastic Beanstalk

Sou fã do Heroku desde os primeiros dias. Mas gosto do fato de que o AWS Elastic Beanstalk oferece mais controle sobre as características das instâncias. Uma coisa que eu amo no Heroku é o fato de poder implantar um aplicativo e não me preocupar em gerenciá-lo. Estou assumindo que a Heroku está garantindo que todas as atualizações de segurança do sistema operacional sejam aplicadas em tempo hábil. Eu só preciso garantir que meu aplicativo seja seguro.

Minha pesquisa inicial sobre o Beanstalk mostra que, apesar de criar e configurar as instâncias para você, depois disso, ele passa para um processo de gerenciamento mais manual. As atualizações de segurança não serão aplicadas automaticamente às instâncias. Parece que existem duas áreas de preocupação:

• Novas versões da AMI - À medida que as novas versões da AMI chegam, parece que queremos executar as mais recentes (presumivelmente mais seguras). Mas minha pesquisa parece indicar que você precisa iniciar manualmente uma nova configuração para ver a versão mais recente da AMI e criar um novo ambiente para usar essa nova versão . Existe uma maneira automatizada melhor de transformar suas instâncias em novas versões da AMI?
• Entre os lançamentos, haverá atualizações de segurança liberadas para pacotes. Parece que queremos atualizá-los também. Minha pesquisa parece indicar que as pessoas instalam comandos para executar ocasionalmente uma atualização do yum. Porém, como novas instâncias são criadas / destruídas com base no uso, parece que as novas instâncias nem sempre têm as atualizações (ou seja, o tempo entre a criação da instância e a primeira atualização do yum). Então, ocasionalmente, você terá instâncias que não estão corrigidas. E você também terá instâncias constantemente se corrigindo até que a nova versão da AMI seja aplicada. Minha outra preocupação é que talvez essas atualizações de segurança não tenham passado pela própria revisão da Amazon (como fazem as versões da AMI) e pode ser uma falha no meu aplicativo atualizá-las automaticamente. Eu sei que o Dreamhost teve uma interrupção de 12 horas porque eles estavam aplicando as atualizações do debian completamente automaticamente, sem nenhuma revisão. Quero garantir que a mesma coisa não aconteça comigo.

Então, minha pergunta é: a Amazon fornece uma maneira de oferecer PaaS totalmente gerenciado como o Heroku? Ou o AWS Elastic Beanstalk é realmente apenas um script de instalação e depois você fica por conta própria (além das ferramentas de monitoramento e implantação que eles fornecem)?

Primeiro, para deixar claro, nenhum Elastic Beanstalk não é PaaS da maneira que você pensa sobre isso. Se você o dividir em pedaços, é realmente mais como ter modelos de instância virtualizados e automação de implantação de aplicativos como fantoche ou chef. Junto com isso, você obtém acesso automatizado ao serviço de balanceador de carga e monitoramento de observação na nuvem, que permitem iniciar novos servidores de aplicativos ou desligar os existentes com base em métricas.

O que faz com que pareça PaaS é que o principal ponto de venda é o sistema de implantação de aplicativos que pega seu código e o copia para todos os servidores de aplicativos em seu cluster.

Uma das reclamações que algumas pessoas têm sobre o PaaS é que o fornecedor do PaaS toma decisões por você sobre o ambiente do aplicativo. Isso me parece a proposta de valor do PaaS: como cliente, você se concentra na funcionalidade do aplicativo e deixa todos os outros detalhes para o fornecedor do PaaS. Você está pagando por outra pessoa para gerenciar a infraestrutura e fornecer administração do sistema. Por essa simplicidade, você está pagando a eles um prêmio, como no caso do Heroku, que também está executando a infraestrutura deles no ec2, apenas de uma maneira transparente para você.

A Amazon está realmente oferecendo o Elastic Beanstalk sobre o Ec2 e suas APIs REST, e não está fazendo muito esforço para esconder isso de você. Isso ocorre porque eles estão ganhando dinheiro via IaaS e a EB está apenas orquestrando a configuração de um grupo de recursos ec2 que você pode configurar sozinho, com o tempo e o know-how.

Agora, em termos de especificidades de uma AMI, novamente as AMIs são uma das muitas peças de ec2 usadas para facilitar o EB. Não há nada mágico em um EB AMI - é apenas um Amazon linux ami pré-configurado para trabalhar com o EB. Como qualquer outra AMI, você pode iniciá-la no EC2, ajustá-la e derivar uma nova AMI personalizada da sua instância em execução. O Amazon Linux é basicamente um cruzamento entre o Centos e o Fedora, com patches de paravirtualização e repositórios yum pré-configurados mantidos pela Amazon.

Como você provavelmente sabe, o Amazon linux já está configurado para instalar patches de segurança no momento da inicialização. No entanto, as instâncias em execução não são diferentes de qualquer outro servidor em relação à aplicação de patches. A aplicação de patches pode interromper o serviço. Se você está extremamente preocupado com o patch de segurança, sempre pode usar um comando de contêiner e configurar o cron para executar o yum update --security em alguma periodicidade.

Você também pode utilizar a API do EB para alterar a configuração do EB ou automatizar a criação de um novo ambiente de EB. Depois, é possível trocá-lo quando estiver pronto e seguido pelo desligamento do antigo. Isso é descrito aqui: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

Como o restante da AWS, existe uma maneira de acessar e controlar programaticamente todos os recursos que não são SaaS, portanto, não há nada que o impeça de criar AMIs remendadas, que são usadas para criar novos ambientes EB e implementá-las. A EB não forçará detalhes específicos de configuração para você, nem fornecerá um grupo de administração de sistema para manter a infraestrutura.

Em abril de 2016, o Elastic Beanstalk suporta atualizações automáticas da plataforma:

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

Todos os aplicativos e ambientes do Beanstalk podem ser configurados por meio de arquivos EBEXTENSIONS que acompanham o pacote de implantação do aplicativo (por exemplo, arquivo WAR para aplicativos Java) com configuração baseada em YAML para atualizar ou reconfigurar qualquer parte do aplicativo, contêiner, SO etc. O Beanstalk é PaaS, pois é uma plataforma que permite implantar aplicativos sem se preocupar com o IaaS subjacente. Todos os provedores de PaaS no final do dia ofuscam o IaaS subjacente por meio de alguma forma de automação. No entanto, como se trata de ciência da computação, não existe um estado ideal para todos os aplicativos e sem a capacidade de ajustar o IaaS no PaaS, você está à mercê do provedor de serviços PaaS para garantir que seus aplicativos funcionem sem problemas, rápido e seguro.

O Heroku é executado no topo da AWS usando uma camada de gerenciamento diferente. No entanto, torna-se um pé no saco quando você precisa fazer coisas como proteger seu aplicativo. Embora eles façam o possível para gerenciar sua solução com eficiência e manter a segurança, etc., eles não podem e não assumem o risco e as consequências de uma vulnerabilidade no seu aplicativo no final do dia. Eles querem tornar seus serviços o mais cortantes possível.

A capacidade de ajustar o IaaS subjacente à plataforma é uma força e apelo do Beanstalk IMO.