AWS: Trusted Advisor, часть 2 – алерты CloudWatch и уведомления в Slack

Автор: | 11/25/2021
 

В продолжение темы по работе с AWS TrustedAdvisor – рассмотрим настройку отправки уведомлений и обновление данных в Trusted Advisor.

Начало – AWS: Trusted Advisor, часть 1 – обзор возможностей.

Что бы настроить уведомления – используем метрики Trusted Advisor, которые он шлёт в CloudWatch, см. список на странице Trusted Advisor metrics and dimensions.

Далее, CloudWatch будет слать алерты в SNS, оттуда – в Opsgenie, а тот уже будет пересылать их в Slack.

Идея заключается в том, что бы получать уведомления, если кто-то создаст, к примеру, AWS Security Group с открытойым в мир задницей доступом. Настроим сами алерты, их отправку в Slack, и обновление данных в TrustedAdvisor, что бы уведомления получать каждый день (или каждый час – up to you, как говорится, но см. ниже – Trusted Advisor refresh checks – периодичность обновления).

Настройка Opsgenie

Создадим отдельную CloudWatch интеграцию в Opsgenie – находим CloudWatch:

Назовём интеграцию “TrustedAdvisor-Security“:

Сохраняем – вернёмся сюда позже, что бы настроить сообщение в Slack.

Настройка AWS Simple Notification Service

AWS SNS настраиваем в регионе us-east-1, N. Virginia, так как часть метрик доступна только в нём, как в самом первом регионе AWS. Тут же потом будем настраивать и CloudWatch Alarms.

Переходим в SNS, создаём топик с типом Standart, назовём его opsgenie-trustedadvisor-security-us-east-1-sns – вроде неплохая идея включать в название сервис/назначение топика и его регион:

После создания – добавляем Subscription:

Копируем URL из Opsgenie:

Возвращаемся к SNS Subscription, указываем Protocol == HTTPS, вставляем URL из Opsgenie:

Сохраняем, переходим к CloudWatch.

Что будем мониторить?

В данном примере будем делать алерт по проверке Security Groups – Specific Ports Unrestricted, но что в целом?

Переходим на AWS Trusted Advisor check reference, смотрим список и выбираем.

К примеру мне пока понравились такие проверки:

Cost optimization:
  • Amazon RDS Idle DB Instances
  • Idle Load Balancers
  • Low Utilization Amazon EC2 Instances
  • Unassociated Elastic IP Addresses
Performance:
  • High Utilization Amazon EC2 Instances
  • Amazon EC2 to EBS Throughput Optimization
Security:
  • Security Groups – Specific Ports Unrestricted
  • Security Groups – Unrestricted Access
  • Amazon S3 Bucket Permissions
  • Amazon RDS Security Group Access Risk
  • ELB Security Groups
  • Exposed Access Keys

При этом у каждой из них есть Green, Yellow и Red уровни важности.

Для Security Groups – Specific Ports Unrestricted важность определяется по следующим критериям (нашёл только в Trusted Advisor Dashboard, почему было не включить в докeментацию?):

  • Green: Access to port 80, 25, 443, or 465 is unrestricted.

  • Red: Access to port 20, 21, 1433, 1434, 3306, 3389, 4333, 5432, or 5500 is unrestricted.

  • Yellow: Access to any other port is unrestricted.

Настроим отправку алерта при срабатывании на Red.

Настройка CloudWatch Alarms

Переходим в CloudWatch Alarms, создаём новый алерт:

Кликаем Select metrics:

Находим нужную метрику Trusted Advisor, в данном случае – Security Groups – Specific Ports Unrestricted – RedResources:

Настраиваем условия срабатывания алерта – в Statistic используем Simple Count, и период 5 минут:

В Conditions выбираем Greater/Equal и than 1, а в Additional configuration указываем Treat missing data as good:

Настраиваем Actions – отправлять уведомление через SNS-топик, который создали выше:

Задаём имя, опционально добавляем описание:

Проверяем – создаём любую SecurityGroup, в ней разрешаем доступ из 0.0.0.0/0 к порту 3306, что бы затриггерить Red Resources:

Сохраняем новый алерт и, казалось бы – всё, жди алерта? Но нет – “Нельзя просто так взять, и затриггерить TrustedAdvisor“.

Trusted Advisor refresh checks – периодичность обновления

Причина – периодичность обновления данных в Trusted Advisor: некоторые проверки обновляются периодически сами, некоторые – при работе с dashboard или с помощью API или AWS CLI.

Открываем документацию по Security Groups – Specific Ports Unrestricted, и читаем:

Тут про refresh не сказано ничего. Зато есть Check ID – сейчас он нам пригодится, что бы выполнить обновление вручную.

А вот проверка на Amazon RDS Public Snapshots выполняется автоматически несколько раз в день, и ручное обновление недоступно:

Trusted Advisor – ручное обновление

Для ручного обновления можно:

  1. просто открыть дашборду TrustedAdvisor, и развернуть проверку Security Groups – Specific Ports Unrestricted
  2. использовать API-вызов RefreshTrustedAdvisorCheck
  3. либо AWS CLI и refresh-trusted-advisor-check

Используем CLI – вызываем команду, передаём регион us-east-1 (N. Virginia, где мы делали алерт), и через --check-id передаёт ID проверки, который видели в документации (также его можно получить через CLI вызов aws support describe-trusted-advisor-checks):

aws --region us-east-1 support refresh-trusted-advisor-check --check-id HCP4007jGY
{
"status": {
"checkId": "HCP4007jGY",
"status": "enqueued",
"millisUntilNextRefreshable": 3599991
}
}

Статус enqueued значит, что обновление запущено, можно ждать результат – через несколько минут прилетит алерт.

Если в status значение “success” – значит, проверка недавно выполнялась, и необходимо подождать, пока не истечёт millisUntilNextRefreshable (3599990 мс == 60 минут).

Получаем алерт в Opsgenie:

И сообщение в Slack:

Настройка отображения алерта в Slack

Текст сейчас бесполезен – просто уведомление, что превышен порог, и алерт сработал.

Настроим – переходим в интеграцию, кликаем Advanced:

И настраиваем сообщение в Slack:

Повторяем проверку:

Готово.