AWS Config - кастомные правила для автоматизации работы системного администратора
Сервис AWS Config предназначен для оценки и аудита конфигурации ресурсов AWS. AWS Config ведет непрерывный мониторинг конфигурации ресурсов AWS и фиксирует результаты. Сервис позволяет автоматизировать сопоставление записанных и требуемых конфигураций и оценку соответствия.
Что это означает на практике? Расскажу о своем недавнем кейсе.
Ко мне обратился клиент, использующий сервис AWS Secrets Manager для хранения API ключей и токенов OAuth. Ключей и токенов было очень много (несколько сотен).
Они были разного типа, и их ротация (обновление) осуществлялась с использованием различных AWS Lambda функций. Администраторам было сложно вручную отслеживать, все ли в системе работает корректно, нет ли ключей, которые по какой-то причине не обновлены в течение заданного промежутка времени. К примеру, если кто-то внесет изменение в функцию, отвечающую за ротацию ключа, он перестанет обновляться, и этого не будет видно.
Передо мной встала задача создания 2х кастомных правил AWS Config:
1) Дата последнего обновления любого ключа AWS Secrets Manager должна быть не старше, чем 90 дней назад.
2) Не должно быть Secrets, для которых не задана функция ротации, и в настройках автоматического выполнения функции ротации должен стоять период ротации менее 90 дней.
Для создания и проверки выполнения данных правил в системе мне понадобилось создать 2 AWS Lambda функции с доступом к AWS Config, AWS Secrets Manager и CloudWatch (для логирования).
Здесь answer["type"] может принимать 2 значения: COMPLIANT, если правило выполняется или NON_COMPLIANT, если правило не выполняется.
Можно перейти в подробности и посмотреть, для какого конкретного Secret не выполняется правило:
Таким образом экономится рабочее время системных администраторов - им не нужно ежедневно перепроверять все секретные ключи и токены в Secrets Manager вручную - достаточно время от времени заходить в дашборд.
Что это означает на практике? Расскажу о своем недавнем кейсе.
Ко мне обратился клиент, использующий сервис AWS Secrets Manager для хранения API ключей и токенов OAuth. Ключей и токенов было очень много (несколько сотен).
Они были разного типа, и их ротация (обновление) осуществлялась с использованием различных AWS Lambda функций. Администраторам было сложно вручную отслеживать, все ли в системе работает корректно, нет ли ключей, которые по какой-то причине не обновлены в течение заданного промежутка времени. К примеру, если кто-то внесет изменение в функцию, отвечающую за ротацию ключа, он перестанет обновляться, и этого не будет видно.
Передо мной встала задача создания 2х кастомных правил AWS Config:
1) Дата последнего обновления любого ключа AWS Secrets Manager должна быть не старше, чем 90 дней назад.
2) Не должно быть Secrets, для которых не задана функция ротации, и в настройках автоматического выполнения функции ротации должен стоять период ротации менее 90 дней.
Для создания и проверки выполнения данных правил в системе мне понадобилось создать 2 AWS Lambda функции с доступом к AWS Config, AWS Secrets Manager и CloudWatch (для логирования).
Далее я создала сами правила AWS Config, подключив в каждом из них соответствующую Lambda-функцию для проверки и указав периодичность проверки:
Чтобы запрограммировать логику проверки правила в AWS Lambda функции, нужно проработать несколько моментов:
1) Мы ожидаем, что обращаться к функции будет только сервис AWS Config, и это нужно проверять при запуске функции. Источник обращения передается в функцию в переменной event. Для тестирования в ходе написания Lambda-обработчика конфигурационного правила можно использовать следующий шаблон:
2) После проверки источника запроса (код проверки, как и другие скучные моменты я не привожу в данном посте) необходимо получить необходимые данные - в данном кейсе это настройки Secrets. Для доступа к ресурcам AWS используется python библиотека boto3. Получить данные, необходимые для проверки - очень просто:
3) Анализируем полученные данные на соответствие заданным правилам и готовим ответ:
4) После того, как ответ подготовлен, его нужно отправить обратно запросившему его правилу AWS Config:
Если какое-то из правил не выполняется, это сразу видно в дашборде AWS Config:
Можно перейти в подробности и посмотреть, для какого конкретного Secret не выполняется правило:
Таким образом экономится рабочее время системных администраторов - им не нужно ежедневно перепроверять все секретные ключи и токены в Secrets Manager вручную - достаточно время от времени заходить в дашборд.
Комментарии