Автоматичне застосування оновлень безпеки для AWS Elastic Beanstalk

Я шанувальник Хероку з найдавніших днів. Але мені подобається те, що AWS Elastic Beanstalk дає вам більше контролю над характеристиками примірників. Одне, що мені подобається в Heroku, - це те, що я можу розгорнути додаток і не турбуватися про управління ним. Я припускаю, що Heroku забезпечує своєчасне застосування всіх оновлень безпеки ОС. Мені просто потрібно переконатися, що мій додаток захищено.

Моє початкове дослідження Beanstalk показує, що, хоча він створює та налаштовує для вас екземпляри, після цього переходить до більш ручного процесу управління. Оновлення безпеки не застосовуватимуться автоматично до екземплярів. Здається, є дві проблеми:

• Нові випуски AMI - Коли нові версії AMI потрапляють, схоже, ми хотіли б запустити останні (мабуть, найбільш безпечні). Але, схоже, моє дослідження свідчить про те, що вам потрібно вручну запустити нову установку, щоб побачити останню версію AMI, а потім створити нове середовище, щоб використовувати цю нову версію . Чи є кращий автоматизований спосіб перетворення примірників у нові версії AMI?
• Між випусками з'являться оновлення безпеки для пакетів. Здається, ми також хочемо оновити їх. Моє дослідження, схоже, вказує на те, що люди встановлюють команди, щоб періодично запускати yum-оновлення. Але оскільки нові екземпляри створюються / знищуються на основі використання, здається, що нові екземпляри не завжди матимуть оновлення (тобто час між створенням екземпляра та першим оновленням yum). Тому періодично у вас з’являться екземпляри, які не виправлені. І у вас також з'являться примірники, які постійно виправляють себе, поки не буде застосовано новий реліз AMI. Моя інша стурбованість полягає в тому, що, можливо, ці оновлення безпеки не пройшли власний огляд Amazon (як це зроблено у версіях AMI), і це може зламати мій додаток для автоматичного оновлення. Я знаю, що у Dreamhost колись було відключення на 12 годин, оскільки вони застосовували оновлення debian повністю автоматично, без будь-якого огляду. Я хочу переконатися, що те саме не трапиться і зі мною.

Отже, моє запитання полягає в тому, чи Amazon пропонує спосіб запропонувати повністю керовані PaaS, як Heroku? Або AWS Elastic Beanstalk справді більше, ніж просто сценарій встановлення, і після цього ви перебуваєте самостійно (крім інструментів моніторингу та розгортання, які вони надають)?

По-перше, щоб бути зрозумілим, жодна еластична бінсталка не є PaaS у тому, як ви це думаєте. Якщо ви розбиєте його на шматки, це справді більше схоже на наявність віртуалізованих шаблонів екземплярів та автоматизації розгортання додатків, як лялька чи шеф-кухар. Поряд з цим, ви отримуєте автоматизований доступ до служби балансування навантажень та моніторингу хмарних годин, що дозволяє запускати нові сервери додатків або вимикати існуючі на основі показників.

Що PaaS відчуває, що головна продажна точка - це система розгортання програми, яка бере ваш код і копіює його на всі сервери додатків у вашому кластері.

Однією із скарг, яку деякі мають щодо PaaS, є те, що постачальник PaaS приймає рішення про вас щодо середовища застосування. Мені це здається як пропозиція про значення PaaS: як клієнт ви маєте сконцентруватися на функціональності програми та залишити всі інші деталі постачальнику PaaS. Ви платите за когось іншого за управління інфраструктурою та забезпечення системного адміністрування. За цю простоту ви платите їм премію, як у випадку з Heroku, який також працює над їхньою інфраструктурою поверх ec2, тільки таким чином, який вам зрозумілий.

Amazon дійсно пропонує Elastic Beanstalk на вершині Ec2 та їх REST api, і не докладає великих зусиль, щоб приховати це від вас. Це тому, що вони заробляють свої гроші за допомогою IaaS, а EB просто організовує налаштування групи ресурсів ec2, яку ви могли б налаштувати самостійно, враховуючи час та вміючи.

Тепер, з точки зору специфіки AMI, знову ж таки, AMI є однією з багатьох частин ec2, які використовуються для полегшення EB. У EB AMI немає нічого магічного - це лише Amazon linux ami, попередньо налаштований на роботу з EB. Як і будь-який інший AMI, ви можете запустити його в EC2, налаштувати його та отримати новий індивідуальний AMI з вашого запущеного примірника. Amazon Linux - це в основному схрещування між Centos та Fedora, з виправленнями паравіртуалізації та попередньо налаштованими yum repos, які підтримує Amazon.

Як ви, напевно, знаєте, Amazon linux вже налаштований для встановлення патчів безпеки під час завантаження. Однак запущені екземпляри не відрізняються від будь-якого іншого сервера щодо виправлення. Виправлення може перервати службу. Якщо ви надзвичайно стурбовані виправленням безпеки, ви завжди можете використовувати команду контейнера та установку cron для запуску yum update - безпеки з певною періодичністю.

Ви також можете використовувати API API для зміни конфігурації EB або автоматизувати створення нового середовища EB. Потім ви можете перейти на нього, як тільки воно буде готове, з подальшим вимкненням старого. Це описано тут: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

Як і решта AWS, існує спосіб програмного доступу та контролю кожної функції, яка не є SaaS, тому ніщо не заважає вам створювати виправлені AMI, які потім використовуються для створення нових середовищ EB та їх розгортання. EB не збирається застосовувати конкретні параметри конфігурації, а також не надає вам групу системного адміністрування для підтримки інфраструктури.

Станом на квітень 2016 року, Elastic Beanstalk підтримує автоматичні оновлення платформи:

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

Усі програми та середовища Beanstalk можна налаштувати за допомогою файлів EBEXTENSIONS, які упаковані разом з пакетом розгортання програми (наприклад, файл WAR для додатків Java) з конфігурацією на основі YAML для оновлення або перенастроювання будь-якої частини вашої програми, контейнера, ОС тощо. Beanstalk є PaaS, оскільки це платформа, яка дозволяє розгортати програми, не турбуючись про основні IaaS. Всі постачальники PaaS наприкінці дня затьмарюють базовий IaaS через певну форму автоматизації. Однак, оскільки мова йде про інформатику, про яку ми говоримо, не існує єдиного оптимального стану для всіх застосувань і без можливості налаштувати IaaS під PaaS, ви зобов'язані постачальника послуг PaaS запевнити, що ваші програми працюють безперебійно, швидко і надійно.

Heroku працює поверх AWS, використовуючи інший рівень управління, що все. Однак це стає болем у попці, коли потрібно робити такі речі, як забезпечення своєї заявки. Хоча вони докладають максимум зусиль для ефективного управління своїм рішенням та підтримання безпеки тощо. Вони не можуть і не беруть на себе ризик та наслідки вразливості вашого додатка наприкінці дня. Вони хочуть зробити свої послуги максимально можливими.

Можливість налаштувати IaaS, що лежить в основі платформи, є силою та привабливістю IMO Beanstalk.