Aplicar automaticamente as atualizações de segurança para o AWS Elastic Beanstalk

Question

Sou fã de 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 eu poder implantar um aplicativo e não me preocupar em gerenciá-lo. Estou assumindo que o Heroku está garantindo que todas as atualizações de segurança do SO sejam aplicadas em tempo hábil. Eu só preciso ter certeza de que meu aplicativo é seguro.

Minha pesquisa inicial no Beanstalk mostra que, embora ele construa e configure 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 há duas áreas de preocupação:

• Novos lançamentos da AMI - À medida que novos lançamentos da AMI chegam, parece que gostaríamos de executar o mais recente (presumivelmente mais seguro). Mas minha pesquisa parece indicar que você precisa manualmente Inicie uma nova configuração para ver a versão mais recente da AMI e crie um novo ambiente para usar essa nova versão . Existe uma maneira melhor automatizada de rotacionar suas instâncias para novas versões da AMI?
• Entre as versões, haverá atualizações de segurança liberadas para pacotes. Parece que queremos atualizá-los também. Minha pesquisa parece indicar pessoas que instalam comandos para executar ocasionalmente uma atualização do yum . Mas como novas instâncias são criadas / destruídas com base no uso, parece que as novas instâncias nem sempre teriam 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 são corrigidas. E você também terá instâncias atualizadas constantemente 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 sido revisadas pela própria Amazon (como as versões da AMI fazem) e podem interromper meu aplicativo para atualizá-las automaticamente. Eu sei que o Dreamhost uma vez teve uma interrupção de 12 horas porque eles estavam aplicando atualizações do Debian completamente automaticamente, sem qualquer revisão. Eu quero ter certeza de que a mesma coisa não aconteça comigo.

Então, minha pergunta é que a Amazon oferece uma maneira de oferecer PaaS totalmente gerenciada como Heroku? Ou o AWS Elastic Beanstalk é realmente apenas um script de instalação e depois você está sozinho (além das ferramentas de monitoramento e implantação que eles fornecem)?

    

Answer 1

Em primeiro lugar, para ser claro, não Elastic Beanstalk não é PaaS na maneira que você está pensando sobre isso. Se você dividir em partes, é mais como ter modelos de instâncias virtualizadas e automação de implantação de aplicativos, como fantoches ou chefs. Junto com isso, você obtém acesso automatizado ao serviço de balanceador de carga do Awe e monitoramento do monitoramento da nuvem, que permite inicializar novos servidores de aplicativos ou encerrar os existentes com base nas métricas.

O que o faz sentir como PaaS é que o principal ponto de venda é o sistema de implementaçã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 a PaaS é que o fornecedor de PaaS toma decisões sobre o ambiente de aplicativos. Isso me parece a proposição de valor do PaaS: como cliente, você se concentra na funcionalidade do aplicativo e deixa todos os outros detalhes para o fornecedor de PaaS. Você está pagando por outra pessoa para gerenciar a infraestrutura e fornecer administração do sistema. Para essa simplicidade, você está pagando um prêmio, como no caso do Heroku, que também está executando sua infraestrutura no ec2, apenas de uma maneira transparente para você.

A Amazon está realmente oferecendo o Elastic Beanstalk no topo do 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 através de IaaS, e o EB está apenas orquestrando a configuração de um grupo de recursos ec2 que você pode configurar, considerando o tempo e o conhecimento.

Agora, em termos das especificidades de uma AMI, novamente as AMI's são uma das muitas peças ec2 que são empregadas para facilitar o EB. Não há nada de mágico em um EB AMI - é apenas um linux da Amazon e pré-configurado para funcionar com o EB. Como qualquer outra AMI, você pode iniciá-la no EC2, ajustá-la e derivar uma nova AMI personalizada a partir 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 pré-configurados yum repos mantidos pela Amazon.

Como você provavelmente sabe, o Amazon linux já está configurado para instalar os 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 à correção. Patching pode interromper o serviço. Se você está extremamente preocupado com o patch de segurança, você sempre pode usar um comando container e um cron de instalação para rodar 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 do EB, em seguida, pode alternar para ele quando estiver pronto e pronto, seguido do encerramento do antigo. Isso é descrito aqui: link

Assim como o restante da AWS, existe uma maneira de acessar e controlar programaticamente todos os recursos não SaaS, portanto não há nada que impeça você de criar AMIs corrigidas, que são usadas para criar novos ambientes EB e implementá-las. O EB não vai forçar detalhes específicos sobre você, nem está fornecendo um grupo de administração do sistema para manter a infraestrutura.

    

Answer 2

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

link

    

Answer 3

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

O Heroku é executado no topo da AWS usando uma camada de gerenciamento diferente. No entanto, torna-se uma dor no rabo quando você tem que fazer coisas como proteger seu aplicativo. Embora eles façam os melhores esforços para gerenciar sua solução com eficiência e manter a segurança, etc., eles não podem e não assumirão o risco e as conseqüências de uma vulnerabilidade no seu aplicativo no final do dia. Eles querem fazer seus serviços como cortadores de biscoitos quanto possível.

A capacidade de ajustar o IaaS subjacente à plataforma é um ponto strong e atraente do IMO do Beanstalk.