В общем случае стоит избегать использования #IAM #ManagedPolicy, т.к. граждане в Амазоне не утруждают себя использованием ограниченных #permissions в них и запросто ставят "жирные" #policy.

Например, в AmazonEC2RoleforSSM, которое рекомендуется для работы с #SSM #Session_Manager, имеется правило на работу #s3 с любыми ресурсами:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetBucketLocation",
    "s3:PutObject",
    "s3:GetObject",
    "s3:GetEncryptionConfiguration",
    "s3:AbortMultipartUpload",
    "s3:ListMultipartUploadParts",
    "s3:ListBucket",
    "s3:ListBucketMultipartUploads"
  ],
  "Resource": "*"
}

#ужас #сколькоможнотерпеть

Чтобы использовать безопасные #iam_policy для #SSM #Session_Manager, придётся использовать длинную простыню правил:

https://github.com/applerom/cloudformation-examples/blob/master/ssm/ssm-manager-policy.yml

#security

⁠Минимальная схема не является рекомендованной, т.к. поднятие ресурсов в мастер-аккаунте не есть #best_practices. Согласно оным мастер-аккаунт должен быть пустым и страшно защищённым.

Правда пока сам Амазон не способствует такой реализации - отдельные сервисы (#CloudTrail, #Config, #SSO и др.) до сих пор завязаны некоторым своим функционалом на использование именно мастера. В результате для соблюдения архитектурной чистоты приходится плодить костыли и с нетерпением ждать, когда же эти косяки будут исправлены.

Однако делать нужно правильно, несмотря на некоторые текущие моменты. Как минимум знать и стремиться.

Здесь и далее всё будет подразумевать использование AWS #Organizations, что и есть реализация #multi_account_strategy.

===
Рекомендуемая схема
===

В рекомендуемой схеме мастер аккаунт пустой (с поправкой на то, что пока ещё требует запуска в нём) - как минимум, никакие виртуалки в нём точно не запускаем, а наш #devops становится суб-аккаунтом и смещается по иерархии ниже.

Для различных функций, в том числе связанных со всей организацией, некоторая часть мух из предыдущей "мухо-котлетной" схемы выделяются в отдельный аккаунт с расплывчатым названием Secure. Туда переезжают ключи шифрования, домены (только регистрации, а не Hosted zones), бэкапы, #CloudTrail-логи и прочие сущности с особой важностью для организации в целом.

Современные фичи Амазона изменяют некоторые архитектурные элементы.

• Bastion выбрасываем - появление #SSM #Session_Manager закрывает его функционал.

• Для #VPC_peering используем #Transit_Gateway.

• В Devops-аккаунте добаляется #Shared_VPC, которая используется для окружений без жёстких требований по безопасности (условно dev-test), хотя, в принципе, можно и для всех окружений.

Также в Devops-аккаунте появился #Jenkins как CI-инструмент - это может быть любой другой вам привычный (я же использую Jenkins, как говорил Портос, потому, что я использую Jenkins).

Амазоновцы таки отреагировали на народные чаяния и убрали из рекомендаций для #SSM эту жирную политику AmazonEC2RoleForSSM, переведя её в статус deprecated.

Вместо неё теперь рекомендуется использовать #IAM #ManagedPolicy AmazonSSMManagedInstanceCore, которая обеспечивает базовый функционал SSM агента, докидывая уже своё по необходимости.

#справедливость #язнал #яверил

⁠Подключение к 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

⁠SSM Session Manager + SSH

Вслед за недавно появившимся EC2 Instance Connect, прокачался идеологически правильный способ коннекта к виртуалке - через #Session_Manager. Теперь он умеет туннелировать SSH и SCP.

Настройка SSH Session Manager Sessions (отличное название, чуваки, снимаю шляпу) по официальной ссылке:

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html

У кого уже стоит Session Manager plugin - нужно обновить до версии 1.1.23.0 или более новой.

⁠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