5 головних недоліків змінних середовища, вирішених за допомогою AWS Parameter Store

Усім привіт, мене звати Олександр Книга, я Solution Architect та технічний директор Weblab Technology і Shaman BV, захоплююсь розробкою ПЗ та адепт open source.

Спочатку поговоримо про самі недоліки середовища, а потім про те, як їх вирішити за допомогою AWS Parameters Store.

№ 1. Обмежений розмір

Яскравий приклад — AWS Lambda із сумарною квотою в 4KB для всіх змінних середовища однієї функції. А що робити, якщо вам потрібен закодований base64 текст із двійковою інформацією чи декілька JWT-токенів?

№ 2. Відʼєднаність

Змінні точно будуть повторюватись, особливо якщо ви маєте декілька deployment pipelines. Та сама змінна середовища може бути застосована до різних сервісів, які виконуються на ECS, EC2 чи AWS Lambda. Ви можете мати десятки подібних спільних змінних. Хто захоче оновлювати це все вручну? Найімовірніше, для них вам знадобиться централізоване сховище.

№ 3. Відкритість (незахищеність)

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

№ 4. Статичність

Для оновлення змінних середовищ потрібно запускати deployment процес повторно, що для більшості проєктів є ризиком та повʼязано із зайвими витратами. Також це може створювати додаткові точки для холодного старту і є досить повільним процесом.

№ 5. Відсутність історії

Ви не можете скасувати зміни (roll back), якщо раніше не зберегли попереднє значення змінної. Змінні середовища — це конфігурація, а неправильна конфігурація — дуже поширена причина проблем безпеки.

Щоб переконатись у цьому, вистачить навіть того факту, що A05:2021-Security Misconfiguration було додано до списку OWASP TOP 10.

Коли варто використовувати змінні середовища

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

AWS Parameters Store

AWS Parameters Store не є популярним. Простими словами, це місце для зберігання ваших даних конфігурації. Більшість даних, «умовно» збережених у змінних середовищах, можна перемістити в Parameters Store.

Офіційні примітки. Parameter Store — це модуль AWS Systems Manager, раніше відомого як Amazon Simple Systems Manager (SSM). Ви могли бачити посилання на Parameters Store з використанням акроніму SSM. AWS CLI дозволяє керувати Parameter Store завдяки команді ssm.

Чи дійсно Parameter Store є хорошою альтернативою

Давайте подивимось на чекліст проблем, які ми мали зі змінними середовища, та застосуємо їх до Parameter Store.

  1. Обмеження за розміром. Вирішено. Ви можете створити 10_000 4KB параметрів на standard tier та 100_000 8KB на advanced tier.
  2. Відʼєднаність. Вирішено. Параметри централізовано.
  3. Відкритість (незахищеність). Вирішено. Параметри можуть бути зашифровані за допомогою KMS.
  4. Статичність. Вирішено. Параметри доступні під час фактичного виконання коду через AWS SDK.
  5. Відсутність історії. Вирішено. Кожне оновлення створює нову версію параметра та запис у журналі аудиту. Код навіть може використовувати попередні версії параметрів.

Ієрархія параметрів

Parameters Store дозволяє групувати параметри в ієрархії. Ви можете уявити структуру даних у вигляді дерева. Щоб скористатися перевагами ієрархії, вам необхідно використовувати слеш як роздільник. Наприклад:

/testapp/dev/core_db/connection
/testapp/dev/core_db/permissions
/testapp/dev/core_db/password
/testapp/dev/rcache/password
/testapp/dev/rcache/connection
/testapp/stage/core_db/connection
/testapp/stage/core_db/permissions
/testapp/stage/core_db/password
/testapp/stage/rcache/password
/testapp/stage/rcache/connection
...

Така організація дає змогу додаткам читати групи параметрів.

Типи, рівні, цінні, Parameter Policies, IAM Policies

Для повного розуміння можливостей сервісу варто зазначити формальності, які представлені в офіційній документації.

Типи параметрів можуть бути такими.

  1. String. Звичайний текст, до якого ми звикли під час роботи з environment variables.
  2. SecureString. Те ж саме, що і String, але з шифруванням від KMS.
  3. StringList. Текст, розділений комами. В результаті виходить щось схоже на колекцію String. Цей тип не може бути захищений KMS.

Кожен параметр у stardard tier безкоштовний, але за кожен параметр в advanced tier доведеться платити по $0,05 на місяць. Стандартний параметр можна перевести у просунутий будь-коли, але не навпаки, оскільки зворотний перехід може призвести до втрати даних у параметрі під час скорочення значення розміру 8KB до 4KB.

Parameter Policies, доступні лише для просунутих параметрів, можуть оновити значення або анулювати його. Це буде корисно, наприклад, для короткочасної зміни пароля — скажімо, протягом 90 днів. Проте ніхто не заважає створити зовнішній процес, який буде альтернативою цим політикам.

Також ви можете детально налаштувати політику IAM для доступу до параметрів.

А чому б не використовувати у цій же ситуації AWS Secrets Manager

Secrets Manager призначений спеціально для конфіденційної інформації, такої як реєстраційні дані бази даних (database credentials). Усі змінні захищені за замовчуванням, що робить їх використання простим та безпечним. Це також дає додатковий функціонал, як, наприклад, Key Rotation. Ця функція може оновлювати для вас паролі замість політики сповіщень, яку має Parameter Store.

Дійсно, іноді краще використовувати Secrets Manager. Однак Parameters Store надає універсальні рішення та має ширший спектр варіантів використання. Також Secrets Manager можна назвати дорогим, оскільки його вартість становить $0,4 за одиницю конфіденційних даних та $0,05 за кожні 10_000 API викликів.

Щодо Hashicorp Vault

Hashicorp Vault — це чудовий інструмент з відкритим кодом, який дозволяє надійно зберігати й контролювати «секрети» та конфіденційні дані. Порівняно з Parameters Store він має більше можливостей: ви можете вибрати сloud або опцію самостійного хостингу. Втім, варіант із сloud не завжди оптимальний через затримку передачі секретних даних до точки запиту та з огляду на вимоги безпеки, які може мати ваша компанія.

Варіант Self-hosted передбачає додаткові витрати на provisioning та обслуговування. За все, що стосується безпеки сховища програми, відповідає винятково користувач.

Parameters Store надійно зберігає ваші ключі (durable), є доступним (available) та працює без збоїв (reliable). Hashicorp Vault також має ці нефункціональні характеристики, але для них ви повинні налаштувати реплікацію принаймні на трьох вузлах.

Я б сказав, що Hashicorp Vault — це хороший варіант, якщо ви намагаєтесь залишатися cloud-agnostic або будуєте рішення для великого enterprise-проєкту.

Parameter Store: мережева затримка

Параметри розташовані на зовнішньому хості, тому доступ до них відбуватиметься із затримкою. Ми провели невелике дослідження, щоб знайти найкращий підхід та зрозуміти, чого очікувати.

Для дослідження затримки ми будемо використовувати AWS Lambda та AWS SDK. Щоб AWS Lambda змогла отримати доступ до Parameter Store, необхідно налаштувати роль IAM (відеодемонстрація).

SSM-команда в SDK має такі методи:

  1. getParameter (читає один параметр);
  2. getParameters (читає колекцію параметрів);
  3. getParametersByPath (рекурсивно читає всі параметри в піддереві).

Тестовий набір 1:

  1. /testapp/dev/core_db/key1. Standard. String
  2. /testapp/dev/core_db/key2. Standard. SecureString
  3. /testapp/dev/core_db/key3. Standard. String
  4. /testapp/dev/core_db/key4. Standard. String

Тестовий набір 2:

  1. /testapp/dev/core_db/key1. Standard. String

Тестовий набір 3:

  1. /testapp/dev/core_db/key2. Standard. SecureString

Тестовий набір 4:

  1. /testapp/dev/redis/key1. Standard. String
  2. /testapp/dev/redis/key2. Standard. String
Запитання, на які ми хочемо знайти відповіді:
  1. Скільки триває отримання єдиного параметру без шифрування?
  2. Як впливає шифрування на час очікування відповіді?
  3. Чи впливає кількість параметрів на час очікування?
  4. Який метод є найбільш практичним?

Ми будемо використовувати Nodejs 16, щоб знайти відповіді. Ви можете переглянути код функції, яку ми використовували для аналізу, за посиланням.

Результати аналізу

Пояснення назв стовпців.

  1. Min — мінімальний час виконання.
  2. Aver — середній час виконання.
  3. Medi — медіана часу виконання. Найкраща метрика для нашого випадку (найбільш представницька).
  4. Max — максимальний час виконання.
  5. Retr — число експериментів (спроб).
  6. N — число ключів у тестовому наборі.

Висновки

  1. getParametersByPath трохи швидший, ніж getParameters, але не суттєво.
  2. Паралельне читання кількох getParameter лінійно збільшує загальний час очікування.
  3. Дешифрування практично не впливає на час очікування.
  4. getParameters здається найбільш гнучкою опцією для реальних сценаріїв.
  5. Розраховуйте на близько 100 мс додаткової затримки на інтеграцію з AWS Parameters Store.

Кешування

100 мс іноді можуть бути критичними, тож ви маєте змогу кешувати отримані параметри в памʼяті протягом роботи, щоб уникнути витрат часу для майбутніх запитів.

Найкращих результатів кешування можна досягнути у контрольованих середовищах, зокрема в індивідуально керованих сервісах на EC2 чи ECS.

Кешування на AWS Lambda також буде корисним, тому що виклики AWS Lambda не гарантовано будуть ізольованими: деякі запити оброблятимуть розігріті контейнери. Але не забувайте час від часу анульовувати кеш залежно від потреб вашого додатку (наприклад, кожні 5 хвилин) чи використовуйте асинхронну стратегію оновлення параметрів.

Envrionment variables все одно залишатимуться з нами

Навіть якщо Parameters Store виглядає, як чудове рішення для централізованої конфігурації, нам досі потрібні змінні середовища, які ми встановлюємо протягом часу розгортання.

Наприклад, ми можемо вирішити не зберігати імена параметрів жорстко закодованими в програмі та встановити їх під час розгортання. Також ми здатні залишити середовище виконання (development, productions) в environment variables. Для багатьох сценаріїв зазначені 5 проблем зі змінними середовища є прийнятними.

Ви також можете залишити код вашого додатку незалежним від Parameters Store, створивши проміжний шар, який читатиме значення з Parameters Store та передаватиме їх до вашого застосунку чи сервісу у вигляді звичних environment variables. Це дозволить додаткам залишатися незалежними від змінних середовищ. Щоб отримати більше інформації, дивіться налаштування EC2 хмарним способом за допомогою AWS Parameter Store.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

якщо й використовувати хашикорп — то лише у корпоративній версії. він набагато зручніший

текст знову заліковий, не зупиняйтесь

А якщо порівняти secrets manager та hashicorp?? Мені здається hashi більш гнучкий та налаштований, а sm далеко не все підтримує, взяти хоча б той же azure

судячи з тексту з Parameter Store точно простіше розібратися, спробую

Aws — продукт Amazon, тому зрозуміло що підтримуватиме сервіси Amazon в першу чергу, Oracle і MySQL не підтримує

З токенів тільки Kibernetes, а ось Nomad та Openshift пролітають

звучить привабливо, навіть занадто — а чи є ще якесь підводне каміння? Про затримку під час інтеграції та зворотний перехід просунутого параметру яснозрозуміло

Трохи б додав що Hashicorp Vault рішення i більш корпоративне з міркувань безпеки

AWS Parameters Store не є популярним

Тому що це вендор лок і потребує використовувати API для доступу.

А за статтю дякую. Цікаво і корисно.

Підписатись на коментарі