В прошлом году под Рождество выкатили AWS SSO, в этот раз таким подарком для меня может оказаться AWS Client VPN.

В частности, про #SSO — небольшая утилитка на Go для аутентификации с использованием #Shibboleth Identity Provider.

https://github.com/CUBoulder-OIT/aws-shib

Список всех AWS сервисов, имеющих #SLA:

https://aws.amazon.com/legal/service-level-agreements/

Отличный онлайн-хелпер по #aws_cli:

https://awsclibuilder.com/home

Локальный хелпер по #aws_cli:

https://github.com/awslabs/aws-shell

Использование секции #Rules в #CloudFormation #templates для дополнительной валидации входных параметров (например, чтобы проверить, что один параметр равен другому).

https://www.cloudar.be/awsblog/undocumented-feature-using-template-constraint-rules-in-cloudformation/

Rules:
  ValidateEqual:
    Assertions:
      - AssertDescription: Both parameters must be the same
        Assert:
          "Fn::Equals":
            - !Ref CanBeAnything
            - !Ref MustBeTheSame

Работает лишь в консоли, но для случаев её использования может быть крайне удобным.

Если вы шарите в контейнерах (но при этом вы не бомж), то хронологию новостей по теме #containers можно отслеживать тут:

https://aws.amazon.com/containers/new/

Бывает нужно найти "похожий сервис" в разных облаках. Соответствие сервисов #AWS и #Azure - официальный список от последней:

https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services

Получить объём #s3 бакета:

aws s3api list-objects --bucket my-analytics-logs --output json --query "[sum(Contents[].Size), length(Contents[])]"

[
136474715550,
24283
]
Первое число - объём в байтах, второе - количество файлов.

Посмотреть с помощью #aws_cli объекты в папке s3 бакета и узнать её объём:

aws s3 ls --summarize --human-readable --recursive s3://my-analytics-logs/indices/

Чтобы прокинуть #IAM роль (инстанса) внутрь докера (актуально, например, при запуске тестов в докере на #CodeBuild), нужно использовать переменную AWS_CONTAINER_CREDENTIALS_RELATIVE_URI:

docker-compose run --name MS -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI app bash -c "python manage.py test -v --junit-report=/report.xml"

→ https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html#troubleshooting-versions
→ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html

В дефолтной #aws_cli #s3 cp нет возможности скопировать несколько файлов или указать *-wildcard для источника. Для этого используем sync, где можно добавить маски:

aws s3 sync --exclude=* --include=some_files* . s3://mybucket/

При монтировании #EFS через #VPC_peering нужно учитывать, что не все инстансы это позволяют, а лишь современные:
· T3
· C5
· C5d
· I3.metal
· M5
· M5d
· R5
· R5d
· z1d

Иначе (как я последние два дня с T2) получаем ошибку по таймауту: mount.nfs4: Connection timed out.

https://docs.aws.amazon.com/efs/latest/ug/manage-fs-access-vpc-peering.html

Как говорится, «запомните этот пост» — открывается первый фронт будущей широкомасштабной войны. AWS добавил в #SMS поддержку миграции виртуалок с #Azure.

https://aws.amazon.com/about-aws/whats-new/2019/04/announcing_azure_awsmigration_servermigrationservice/

#cloud_war

Чтобы следить за утечкой в общий доступ важных параметров (например, AWS ID) — можно использовать Google Alerts, настроив слежение за свежепроидексированным Google на эти значения.

Узнавать постфактум не лучшая практика, конечно, но лучше уж позже и вы, чем раньше и враги.

#security

Если свежесозданный #CloudFront отдаёт #error 307 при доступе в (также свежесозданный) бакет, находящийся не в дефолтном регионе (N.Virginia), то не стоит искать ошибку в вашем шаблоне — это лаг самого Амазона на создание DNS бакета в своём в регионе и тут придётся просто ждать (5-45 минут, в зависимости от текущего здоровья Амазона).
Когда он разродится, ошибка исчезнет сама (чтобы это увидеть быстрей - потребуется инвалидация кэша).

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

По умолчанию доступ к биллингу аккаунта имеет лишь root-юзер. Добавление другому юзеру (даже с админскими правами) в #IAM политики #Billing не даст доступ к биллингу.

Для этого нужно предварительно активировать IAM User and Role Access to Billing Information (залогившись под рутом). После этого политика Billing будет работать как положено для любого юзера/роли.

https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_billing.html?icmpid=docs_iam_console#tutorial-billing-step2

Спасительный флажок bucket-owner-full-control, решающий вопросы доступа в #s3 бакет для двух аккаунтов, не поможет для ситуации с тремя и более аккаунтами. Это когда файл копируется из аккаунта A в бакет аккаунта B, а после нужно расшарить это для аккаунта C (также имеющего доступ в бакет аккаунта B).
Использование --acl bucket-owner-full-control не поможет и получим #error:

An error occurred (AccessDenied) when calling the GetObjectAcl operation: Access Denied

Хотя точно у всех есть нужные #IAM #permissions и прописаны правильные #bucket_policy в #shared_bucket.

Дело в тех же owner-ах, как и для "двух-аккаунтной" схемы, только решается много сложней. Объекты в shared-bucket имеют лишь права для этих двух аккаутов A и B, аккаунт C имеет доступ в бакет, но его нет среди owner-ов объектов, потому ничего с ними сделать не может.

Решается ситуация лишь из аккаута owner-а, т.е. из аккаунта A — при копировании нужно добавить в список owner-ов сразу все аккаунты (т.е. в т.ч. C). Обычная #aws_cli команда s3 cp так не умеет — нужно использовать #s3api:

aws --region=us-east-1 s3api put-object --bucket my-shared-bucket --key my-bucket-dir/conf.tar.gz --body my-local-dir/conf.tar.gz --grant-full-control id=d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058,id=1208ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb11a9338a60609ee5f9,id=780e8bdf2b68d6cc2da2cfcaa6192fac4f437190322277db24ce81ce9aa698f9

Очень непростая и плохо документированная, но рабочая конструкция.
my-shared-bucket — бакет в аккаунте B
--key — путь к файлу в этом бакете
--body — локальный путь к файлу (на виртуалке)
--grant-full-control id=s3-canonical-A,id=s3-canonical-B,id=s3-canonical-C — #s3_canonical аккаунтов A, B и C (именно в таком виде - через запятую без пробела, чего нет в доке, враги)

Не нужно путать S3 Сanonical ID с тем, что используется для CloudFront при доступе в непубличный бакет (S3 canonical user ID). Это уникальный ID для аккаунта, который идёт в паре с AWS ID и может быть получен с помощью aws s3api list-buckets
{
"Owner": {
"DisplayName": "my-account-A",
"ID": "d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058"
},
"Buckets": []
...

Это ID значение получаем для каждого аккаунта, который должен иметь доступ к данному файлу в shared-bucket. Если потребуется расшарить к новому аккаунту - придётся повторить процедуру для каждого файла (объекта).

Потому если нужно раздавать (непубличные) файлы для переменного количества аккаунтов, то #s3 не лучший способ при таком сценарии. В рекомендациях от Амазона это решается с помощью роли в аккаунте A или B, в которую должен переключиться юзер из аккаунта C для получения файла, однако такое (переключение в роль) не всегда возможно сделать в уже имеющемся ПО и библиотеках.

Лучшие из известных мне мест для обсуждения темы #AWS (по условному личному рейтингу предпочтения):

===

og-aws (Slack) — инвайт можно получить на https://og-aws-slack.lexikon.io/

Хорошие каналы:
#announcements
#awsannoyances
#cloudformation
#ecs
#general
#mistakes
#security
и другие (#terraform #kubernetes и т.д.)

===

Reddit - https://www.reddit.com

Хорошие комьюнити:
https://www.reddit.com/r/AWS_cloud/
https://www.reddit.com/r/aws/
https://www.reddit.com/r/AWS_Certified_Experts/

===

hangops (Slack) — инвайт можно получить на https://signup.hangops.com/

Хорошие каналы:
#aws
плюс также, конечно, #kubernetes, #terraform, #docker и т.д.

===
===

Русскоязычные:
AWS_ru
AWS Minsk Community

Ну, и данный канал aws_notes (срочно подписываемся, если ещё нет), который веду я, Roman Sevko — пытаясь каталогизировать собственные заметки по Амазону, чтобы и самому не забыть, и другим полезно.

#info

Если у вас активно используется #AWS_Organizations, то стоит задуматься над тем, чтобы прописать пароли у root-юзеров в созданных суб-аккаунтах (что не часто делается, особенно если они создаются автоматически).

Указание фейковой почты для #root_user уязвимо с точки зрения безопасности. Лучшей практикой является установка пароля для рута и включение #MFA на какое-то условно защищённое устройство (и, к примеру, помещённое в сейф).

Кроме того не стоит забывать, что Амазон шлёт некоторые важные (в т.ч. критические - взлом и т.п.) #notifications на почту root-юзера. Это можно в некоторой мере решить, указав Alternate Contacts в настройках аккаунта, однако некоторые сервисы (если не ошибаюсь, #SES), могут слать notifications лишь на рут-почту.

#security #best_practices

В продолжение темы защиты #root_user — для особо опасливых можно посоветовать накрыть всё это дело сверху #SCP политикой для #AWS_Organizations, запрещающей работу из-под рута.

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:root"
    }
  }
}

Правда некоторые сервисы под капотом используют (требуют) рута, потому стоит протестировать на чём-то неважном (возможно разбанить нужные сервисы, требующие root).

#paranoid #security

Чтобы узнать (убедиться) какую #IAM роль имеет виртуалка, на которой вы сейчас что-то делаете — используем команду #aws_cli #sts для получения её #ARN #iam_role:

aws sts get-caller-identity

{
    "Account": "123456789012",
    "UserId": "AROAJDDFOVZHPIQJWHGGG:i-012cf7e6be9a23bec",
    "Arn": "arn:aws:sts::123456789012:assumed-role/main-roleEc2-12DC86Q5A4VNV/i-012cf7e6be9a23bec"
}

Тут же и #AWS_ID аккаунта.