aws

AWS: Trusted Advisor алерты CloudWatch и уведомления в Slack

Thank you for reading this post, don't forget to subscribe!

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

Что бы настро­ить уве­дом­ле­ния – исполь­зу­ем мет­ри­ки 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):

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

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

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

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

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

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

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

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

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

Гото­во