Управление секретами и конфигурацией в облаке

Пароль базы данных, встроенный в образ, становится доступен всем, кто его загрузит. Вместо этого внедряйте секреты во время выполнения, а не сборки. 🔐

Обычные настройки, например путь к модели, — это конфигурация. Чувствительные значения, например ключи API, — это секреты. И те и другие хранятся вне образа, но обрабатываются по-разному.

Несекретные настройки передаются как переменные окружения во время развёртывания. Один и тот же образ после этого может по-разному работать в тестовой и рабочей средах.

Приложение считывает эти значения через os.environ. Укажите разумное значение по умолчанию, чтобы код мог работать локально без задания каждой переменной.

Настоящие секреты следует хранить в менеджере секретов, например AWS Secrets Manager или Google Secret Manager. Он шифрует данные, хранит их версии и регистрирует доступ.

Подключайте секрет по ссылке, а платформа смонтирует значение во время выполнения. Секрет никогда не появится в команде развёртывания.

Секрет можно передать как переменную окружения или смонтированный файл. Сертификаты и длинные ключи часто удобнее считывать по пути к файлу.

Предоставляйте сервисной учётной записи только те секреты, которые ей действительно нужны. Это правило минимальных привилегий уменьшает последствия утечки токена.

Зафиксируйте секрет на версии, например latest, а затем замените его, добавив новую версию. Новые экземпляры подхватят её без пересборки образа.

Журналы хранятся долго и доступны многим, поэтому выведенный ключ практически становится общедоступным. Удаляйте секреты и из вывода, и из трассировок ошибок.

Если конфигурация и секреты находятся снаружи, один образ работает везде. Меняйте поведение, подставляя переменные, а не пересобирая образ.

Вы отделили конфигурацию от секретов, внедрили и то и другое во время выполнения, использовали менеджер секретов и безопасно заменили секреты. Теперь один образ работает где угодно. 🔑