https://community.aws/content/2biM1C0TkMkvJ2BLICiff8MKXS9/format-and-parse-amazon-s3-url
Суть:
есть масса форматов путей у S3, включая особенности про дефолтный регион (вне его такое не работает) - и просто не прочитав про это, можно долго думать что не так.
Если используется амазон и S3 - читать обязательно.
Казалось бы, уже давно отработанный механизм с .ssh/authorized_keys в случае амазона ВДРУГ дал сбой. Вдруг - потому что ещё несколько лет назад этой ПРОБЛЕМЫ не было.
Смотрим /var/log/auth.log и видим там крайне сомнительные строки
AuthorizedKeysCommand /usr/share/ec2-instance-connect/eic_run_authorized_keys username SHA256:ecphulTPPp7xHnSCVkuQH2fcXemYKjT8xFftheRDz+s failed, status 22
Но секрет прост: кто-то "переиграл в безопасность" и
# apt show ec2-instance-connect
...
Description: Configures ssh daemon to accept EC2 Instance Connect ssh keys
EC2 Instance Connect is a service that publishes ssh keys for use by EC2
instances based on AWS Credentials. These keys are consumed by on-instance
configuration provided by this package. The ssh daemon will query EC2
Instance Metadata service for user-keys at ssh calltime, validate any if
present as well as validating their signature, and if all checks pass return
will include them in the authorized keys list.
Фикс версия 1:
apt remove ec2-instance-connect
systemctl restart sshd
Фикс версия 2:
rm /usr/lib/systemd/system/ssh.service.d/ec2-instance-connect.conf
systemctl daemon-reload
И ещё немного почитать
https://github.com/widdix/aws-ec2-ssh/issues/157
И причина:
ExecStart=/usr/sbin/sshd -D -o "AuthorizedKeysCommand /usr/share/ec2-instance-connect/eic_run_authorized_keys %%u %%f" -o "AuthorizedKeysCommandUser ec2-instance-connect" $SSHD_OPTS
Установка: если раньше надо было качать архивы и распаковывать, то уже (давно) есть фирменные репы, например
https://www.terraform.io/docs/cli/install/apt.html
Дальше есть видео на офсайте
https://learn.hashicorp.com/tutorials/terraform/aws-build
В частности, надо поставить aws cli и получить Access Key (нужные линки под видео)
Дальше описываем provider и resource. При этом даже офдока создаёт путаницу, где описан в первом варианте единственный блок
module "ec2_instance" {
После установки и запуска базового примера крайне советую смотреть лист от adv-it, там очень многое рассказано.
Есть штатная дока про включение и виды MFA
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html
Но - там ни слова про включение MFA как требование для всех. Впрочем, легко гуглится заметка их блога
Включить эту информацию, хотя бы ссылкой, они как всегда не осилили.
Если машина - часть ASG и min-max-desired настроены (1-2-1 например, важно что max=min+1, desired=min) то оно само пересоздаст инстансы. Если нужно именно этот же инстанс обновлять, без его пересоздания - надо в сторону ansible смотреть.
Также, есть секция, которая запускается при каждом старте, что-то типа bootcmd, надо доки уточнить. И есть cloud_final_modules
https://aws.amazon.com/ru/premiumsupport/knowledge-center/execute-user-data-ec2/
вот тут про bootcmd есть
https://stackoverflow.com/questions/6475374/how-do-i-make-cloud-init-startup-scripts-run-every-time-my-ec2-instance-boots
В плане, в эти блоки можно поставить ansible. Потому что userdata работает только при создании инстанса.
Изучаем замену для cfn - cdk (AWS Cloud Development Kit)
"это платформа разработки программного обеспечения ... используя привычные языки программирования"
И вот для быстрого старта: https://youtu.be/bz4jTx4v-l8
И пример кода
Если нам нужно выкатывать набор инстансов, то там можно указать DependsOn и сборка будет ждать готовности инстанса. Но в случае с ASG всё не так просто.
Во-первых, DependsOn на ASG - продолжит развёртывание по готовности самого ASG, но не его машин.
Во-вторых, повесить DependsOn на отдельный инстанс группы или их набор - невозможно напрямую.
В третьих, есть механизмы CreationPolicy и UpdatePolicy (которые так же нужно вешать на инстанс, чтобы стек ждал готовности ноды) и через /opt/aws/bin/cfn-signal на ASG выставлять что нода готова.
Можно сделать внешний счётчик через WaitCondition + WaitConditionHandle.
У него есть нюанс. Если в случае *Policy используется формат --resource (ASGName), то в случае WaitCondition - такой формат не работает! Мы должны применять форму cfn-signal -e 0 !Ref OurWaitCondition, ну или использовать curl. У меня ушло много времени, чтобы найти этот "особый" формат. И да, если мы используем runcmd с блоком Sub - то вместо !Ref надо использовать формат ${OurWaitCondition}.
Второй нюанс: Anytime you add a WaitCondition resource during a stack update or update a resource with a wait condition, you must associate the wait condition with a new WaitConditionHandle resource. Do not reuse an old wait condition handle that has already been defined in the template. If you reuse a wait condition handle, the wait condition might evaluate old signals from a previous create or update stack command.
И напоследок: Updates are not supported for this resource.
И ещё линки
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html
Как я понимаю, в отличие от штатного убогого, тут сразу получаем автогенерацию шаблона. В общем, можно поиграться и посмотреть. Но советую использовать такие приложения или для быстрого прототипирования, или для самообразования. Тот случай, когда разобраться в итоговом шаблоне - обязательно.
Одно но: оно платное, хотя есть Developer версия, 1 seat, 1 linked AWS account, 6 active stacks
https://harrisonmilbradt.com/blog/fixing-update_rollback_failed-in-serverless/
Actions > Continue Update Rollback и там есть пропуск сломанных шагов. Также есть консольная версия
aws cloudformation continue-update-rollback --stack-name my-stack --resources-to-skip failed-resource1 failed-resource2
Есть у амазона сервис авторизации Cognito, позволяет настроить авторизацию гугла, oauth и подобным.
Сам по себе сервис достаточно прост: сначала в User pools создаём пул юзеров, причём на старте достаточно "review defaults", потом создаем базу для вошедших юзеров - Identity.
Теперь в самом простом случае - заводим локальных пользователей, создаём группу (по доке выше) - и вот уже сервис можно использовать.
Замечание для kibana: после включения Cognito в настройках, авторизацию запрашивать не будет, нужно нажать в ES - Modify access policy и в Principal заменить * на хитрую строку, подробнее всё в той же доке выше.