Як зберігати зашифровані секрети в коді для проекту без сервера?

На сервері без сервера.com найпростіший спосіб викрити секрет функції AWS Lambda - це зберігати її у serverless.ymlфайлі (наприклад, зашифрованому KMS).

Але вчинення зашифрованих секретів Git - не найкраща річ у світі. Потрібно змінити код, коли секрет має змінитися, з одного боку.

Але тільки з точки зору безпеки, які кращі альтернативи? наприклад, секрет може бути збережений у S3 (зашифрований), щоб Ламбда отримав доступ до цього місця та ключ KMS, але чи справді це краще в будь-якому значущому плані?

Тут слід врахувати пару елементів:

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

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

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

Є кілька бібліотек з відкритим кодом, які підтримуватимуть цю операцію:

• Пітон: CredS3
• Перейти: кросівки

Я зазвичай розглядаю секрети як дані конфігурації за обсягом. Як такий, він не живе поряд з кодом, оскільки ними обробляються різні графіки та процеси випуску. Окреме місце git repo, KMS, dynamo, s3 або всередині вашої системи управління конфігурацією (шеф-кухар / зашифрована база даних у світі шеф-кухарів) - хороші місця. По суті, вам не потрібно створювати та розгортати нову версію свого програмного забезпечення, щоб оновлювати секрет.

Якщо потреби в управлінні секретами є складнішими, щось на зразок Hasicorp Vault ( https://github.com/hashicorp/vault ) було б хорошим варіантом.