⁠Подключение к EC2 виртуалкам

Для подключения по SSH к #EC2 инстансам #best_practices является ипользование #SSM #Session_Manager. Однако теперь это можно в некоторой степени дополнить использованием EC2 Instance Connect.

https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh-access-to-your-ec2-instances/

Предварительно установленный на виртуалку (к которой нужно подключиться) сервис #ec2_instance_connect позволяет прокинуть ваш публичный ключ в meta-data инстанса, где он будет жить 60 секунд и может быть использован для логина ssh-демоном.

Весьма удобная схема с временными ключами, где за авторизацию отвечает #IAM, а значит можно коннектиться с другого инстанса с правами данного инстанса, с локального компа с правами юзера или через браузер #AWS_Console (на картинке внизу).

Т.к. это происходит через AWS API, то коннектиться можно с приватных айпишников.

В отличие от SSM Session Manager, #ec2_instance_connect требует открытый 22 порт на входящие (хотя можно и рекомендуется его ограничить лишь амазоновскими айпишниками, т.к. соединение идёт через сервисы амазона).

Как было сказано, для работы с EC2 Instance Connect - его сначала нужно устанавливать. Предустановлен он лишь в Amazon Linux 2 - очередная причина, почему правильно его использовать (и именно AL2, а не первый).

#SSH

⁠SSH туннелирование через SSM Sessions Manager

Куда

На виртуалке, куда мы хотим коннектиться должен быть установлен SSM агент. Правильные пацаны юзают Amazon Linux 2, где он стоит по умолчанию на новых версиях. Однако даже на только что поднятых из консоли виртуалках стоит не самая последняя версия (фу, Амазон), потому запускаем стандартный установочный однострочник:

sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

Для неудачников на своих Убунтах и прочих некошерных линуксах - двигаем по ссылке первоисточника.

Присоединяем к виртуалке нужные #IAM права (было тут и тут), без которых она не имеет права зарегистрироваться в #SSM и вы не сможете использовать #Session_Manager для подключения к ней.

Для всех (т.е. 0.0.0.0/0 - обязательно) открываем порт 22 (укоряюще смотрит на всех безопасников Амазона).

В принципе с виртуалкой всё. Однако чтобы избежать вероятных проблемных моментов (нет каких-то обновлений, старая версия агента, солнечный ветер, дым из трубы, плохое настроение) — чёткие пацаны жмут виртуалке ресет и тогда она точно готова.

Откуда

На виртуалке (компьютере), откуда будем коннектиться на подготовленную ранее виртуалку, требуется #aws_cli (само собой разумеется) и должен быть установлен Session Manager Plugin.

Правим файл SSH-конфига (который в домашнем каталоге ~/.ssh/config), добавляя для хостов, куда хотим коннектиться запуск ProxyCommand - см. официальную ссылку.

Всё, должно работать:

ssh -i /root/.ssh/ttt19 ec2-user@i-016de9a622dfd5430

(см. картинку)

===

#multi_account_strategy

Для случаев, если виртуалка, куда нужно коннектиться, находится в другом аккаунте, то используем описанную схему, т.е. добавляем в ProxyCommand нужный профиль.

Для примера, вот полная версия реального файла /root/.ssh/config:

# CodeCommit
Host git-codecommit.*.amazonaws.com
 User ADDAJA5W7IDY5CHX3YKK
 IdentityFile ~/.ssh/codecommit_devops-user

# SSH over Session Manager
host i-* mi-*
 ## single account
 #ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

 ## multi account (stage account)
 ProxyCommand sh -c "aws --profile=stage ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

#tutorial

⁠SSM Session Manager + Port Forwarding

Очередной последний гвоздь в крышку Bastion схемы работы - теперь можно через SSM прокидывать на локальный комп нужный порт.

Потестируем. Как обычно, для всех новых фич обычно требуется последние версии всего. Смотрим версию #aws_cli:

aws --version
aws-cli/1.16.218 Python/2.7.14 Linux/4.14.97-90.72.amzn2.x86_64 botocore/1.12.208

Для порт-форвардинга требуется 1.16.220 и новей, так что обновляем.

aws --version
aws-cli/1.16.228 Python/2.7.14 Linux/4.14.97-90.72.amzn2.x86_64 botocore/1.12.218

Теперь 1.16.228 - можно двигать дальше. Проверяем и ставим, если ещё не ставился session-manager-plugin.

Проверяем версию агента (на картинке снизу) - не самая свежая, но можно и древней (2.3.672.0 и новей).

Значит можно запускать. В моём случае запуск в другом аккаунте, потому используется флажок --profile:

aws --region=us-east-1 --profile=openfs ssm start-session \
--target i-08a829418da3d9b15 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"],"localPortNumber":["8080"]}'

Starting session with SessionId: botocore-session-1567069474-007a8050d8e22a3ed
Port 8080 opened for sessionId botocore-session-1567069474-007a8050d8e22a3ed

portNumber - это порт на инстансе, который будет форвардиться на наш локальный порт на компе localPortNumber.

Открываем в браузере 127.0.0.1:8080 и видим локально у себя локальное на удалённом инстансе. Либо доступ к базе, какому-то сервису - в общем, любому порту.

Поигравшись жмём CTRL-C и (с некоторым лагом) сессия оборовётся.
^CTerminate signal received, exiting.

Итого - отличная штука, бесплатная (только за трафик) - точно стоит освоить и пользоваться.

#ssm #session_manager

⁠Автообновление SSM-агента

Отличная новость - можно включить автообновление для всех ранее настроенных SSM-агентов:

https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html

Например, здесь приходилось проверять, чтобы агент был последним - теперь же любую новую фичу он будет подхватывать сразу!

#ssm

⁠EC2 Console + Session Manager

В консоль таки добавили соединение через SSM Session Manager - теперь не нужно прыгать по сервисам для того, чтобы просто зайти через него на виртуалку. Найти не так просто (улыбаемся и машем), потому инструкция прилагается.

Правая клавиша на инстансе (у которого стоит и настроен SSM agent), жмём Connect. (вверху картинки)

Далее, к сожалению, придётся ещё кликать, т.к. по умолчанию стоит инфо по подключению через SSH - меняем на Session Manager и снова жмём Connect. (в середине)

Открывается обычное терминальное окно SSM Session Manager - радуемся. (нижняя)

#SSM #EC2 #AWS_Console

⁠SSM + Fargate

Тем, кто любит SSM - заслуживающий рассмотрения случай интеграции SSM с Fargate:

https://github.com/andrewkrug/fargate-ir

Конкретно здесь функционал предназначен для incident response, однако мне кажется, что это правильный подход в сторону унификации использования SSM, когда практики, характерные для ОС, распространяются также и на контейнеры.

#SSM #Fargate

Отличная утилитка под SSM Session Manager для борьбы с ключами SSH на ваших инстансах (чтобы их не использовать):

https://github.com/xen0l/aws-gate

#SSM

Встроенный SSM-агент для ECS-Optimized Amazon Linux 2 AMI:

https://aws.amazon.com/about-aws/whats-new/2020/02/amazon-ecs-optimized-linux-2-amis-come-pre-installed-aws-systems-manager-agent/

Теперь можно будет убрать из скриптов ставшую лишней строчку yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm (т.к. теперь SSM-агент идёт из коробки).

#SSM #ECS #AMI

​​Настройка Managed Policy для SSM:

https://aws.amazon.com/blogs/mt/applying-managed-instance-policy-best-practices/

Правильный и полезный SSM агент и Sessions Manager появился с кошмарными Managed Policy, поторые были заменены год назад на AmazonSSMManagedInstanceCore.

В статье полезная табличка (на картинке) и последовательность обновления, если у вас уже были настроены старые жирные Managed политики. А также автоматизация этого процесса с помощью AWS Config remediation, если у вас много таких виртуалок.

#SSM #IAM

Вывести имена виртуалок с SSM агентами:

aws ssm describe-instance-information --query InstanceInformationList[*].ComputerName

SSM виртуалки плюс их IP-адреса:

aws ssm describe-instance-information --query InstanceInformationList[*].[ComputerName,IPAddress]

Нужная виртуалка с конкретным IP с выводом чисто текста (для скрипта):

aws ssm describe-instance-information --query "InstanceInformationList[?IPAddress=='10.12.13.162'].ComputerName" --output text

#query #SSM

Хороший (длинный и детальный) туториал по использованию SSM Automation на примере разворота Chaos Monkey:

https://medium.com/@adhorn/creating-your-own-chaos-monkey-with-aws-systems-manager-automation-6ad2b06acf20

#SSM

CodeBuild + SSM

Чтобы отладить что-то в CodeBuild можно использовать SSM Session Manager:

https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html

То есть можно тормознуть процесс сборки CodeBuild с помощью вставки codebuild-breakpoint, после приконнектиться через SSM, посмотреть на местности, что не так и после продолжить билд с помощью команды codebuild-resume.

#CodeBuild #SSM

Примитивный, но действенный способ сэкономить для часто встречающегося сценария — тушить или уменьшать мощность ресурсов на ночь. Например, виртуалки и/или RDS базы данных. Для реализации этого поможет SSM Manager + CloudWatch Events:

https://aws.amazon.com/blogs/mt/systems-manager-automation-documents-manage-instances-cut-costs-off-hours/

#SSM #cost_optimization

Автоматизация настройки CloudWatch алярмов для виртуалок с помощью SSM:

https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/

#SSM #CloudWatch

Использование AWS Config + SSM для автоматизации закрытия открытых портов (например, для соблюдения compliance требований):

https://aws.amazon.com/blogs/security/how-to-auto-remediate-internet-accessible-ports-with-aws-config-and-aws-system-manager/

#Config #SSM #security #compliance

Чтобы указать последнюю версию SSM Parameter в CloudFormation шаблоне — просто не указываем поле version:

version
If you do not specify the exact version, CloudFormation uses the latest version of the parameter whenever you create or update the stack.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-ssm-pattern

#SSM #CloudFormation

SSM Incident Manager:

https://aws.amazon.com/blogs/mt/creating-contacts-escalation-plans-response-plans-aws-systems-manager-incident-manager/

Incident Manager incorporates the best practices we follow for internal incident management at Amazon. When you use Incident Manager, you engage the right responders at the right time, track incident updates, automate remediation actions, and enable chat-based collaboration.

#SSM