ReadOnly #bucket_policy для доступа к файлам/бакету из других аккаунтов ("расширенная версия" - не забываем добавлять ListBucket для возможности копировать с профиксом/рекурсией, а также GetBucketLocation для определения региона бакета):

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Access to files/* for accounts: dev1, dev2",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111111111111:root",
"arn:aws:iam::222222222222:root"
]
},
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::shared-bucket/files/*",
"arn:aws:s3:::shared-bucket"
]
}
]
}

#s3 #cross_account #access

В официальной документации по #cross_account #s3_replication ошибки - пример указан с неполными правами в #bucket_policy для аккаунта источника:
...

"Action":["s3:ReplicateObject", "s3:ReplicateDelete"],

...
Полные указаны в примере предыдущего поста. Их нужно добавить и для роли источника, особенно с учётом, если нужно менять владельца.
Потому, для простоты, можно сразу давать полные s3:* - т.е. в приведённой ссылке на документацию по #cross_region #s3 #replication будет работать, если сделать так:
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "Full access for other account",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "s3:*" ,
"Resource": [
"arn:aws:s3:::replication-bucket",
"arn:aws:s3:::replication-bucket/*"
]
}
]
}
Аналогично сделать и в роли аккаунта источника:
- Effect: Allow
Action: 's3:*'
Resource: ## destination bucket
- 'arn:aws:s3:::replication-bucket'
- 'arn:aws:s3:::replication-bucket/*'

Для доступа к #s3 можно использовать #iam, #bucket_policy и #bucket_acl - что же лучше использовать?
Если коротко, то всегда лучше выбирать #IAM.
Когда не получается или нужен как раз #resource_based подход - выбираем #bucket_policy (без него не обойтись для случаев #cross_account).
Использовать ACL не стоит ни разу - это и старое и неудобное.

При использовании #cross_account #s3_replication нужно учитывать, что destination #s3 бакет должен:
- существовать на момент отработки #CloudFormation #templates
- иметь #versioning (обязательно требуется для #replication)
- быть в другом #region

Пример кода - cross-account cross-region s3 bucket replication.

Также стоит обратить внимание, что роль на репликацию создаётся в аккаунте источника (которая указывается в ReplicationConfiguration бакета), а не в аккаунте репликации, как может показаться логичным. Мы даём доступ внешнему аккаунту (с бакетом источника) к себе в аккаунте репликации.

⁠О дефолтных ключах шифрования (AWS managed keys)

Предположим, вы решили учинить разгул безопасности по всему своему проекту. Не стану отговаривать вас от этого безрассудного поступка (в следующий раз), просто предположу, что главным оружием преступления станут дефолтные ключи шифрования, мирно пасущиеся в каждом, умеющих их использовать, сервисе.

Использовать их, действительно, наиболее просто. Однако если (а скорей когда) вам потребуется расшарить зашифрованное дефолтными ключами в другой аккаунт, то будет очень больно узнать, что придётся всё переделывать.

Как правило, в первую очередь речь заходит о базах данных, т.е. #RDS #Snapshot, где в конце концов вы таки прочитаете эти печальные слова:

You can't share a snapshot that has been encrypted using the default AWS KMS encryption key of the AWS account that shared the snapshot.

Дефолтные ключи шифрования можно использовать лишь внутри одного аккаунта. Их по доброте душевной итак уже сделал Амазон, за что, видимо, нужно быть благодарным (хотя у меня, вот, тогда не получилось). А для всех #cross_account операций нужны свои ключи - Customer managed keys - которые шарятся для использования в других аккаунтах.

===

Итого, совет. Если вы никогда не планируете и не будете использовать #multi_account_strategy (мои соболезнования), то #AWS_managed_keys - реально отличное решение, стильно-модно-безопасно.

В противном случае (который является рекомендуемым) - лучше сразу закладываться на свои ключи #Customer_managed_keys. С ними будет муторней и сложней, это правда. Но с ними можно всё.

#KMS #security #encryption

⁠CloudWatch dashboards + cross-region & cross-account

Теперь простой ответ "ну, понятно - Prometheus+Grafana" придётся давать с оговоркой "или настроить CloudWatch - он уже может кросс-аккаунт-кросс-регион". Не прошло и... А, нет, прошло. И ещё не раз прошло.

Однако теперь это возможно - в одном месте можно настроить полезные CloudWatch дашборды, где можно увидеть метрики из ваших Dev-Test-Stage-etc аккаунтов и/или разбросанных по разным регионам:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html

В CloudWatch консоли в разделе Settings добавляете нужные аккаунты, в которые добавляете роль CloudWatch-CrossAccountSharingRole (можно сделать самому в каждом аккаунте или с помощью Cloudformation шаблона, который там сразу предлагается запустить - в нём только создание роли) с нужным вариантом политик доступа.

Вместо перечисления в трастовых всех аккаунтов организации (речь о Trust relationships), можно использовать, как указано в документации, конструкцию типа:

"Condition": {
 "StringEquals": {
   "aws:PrincipalOrgID": "org-id"
 }
}

Лишь напомню, что org-id это не айдишник аккаунта вида 123456789012, а организации типа o-dtj1bor777, как было здесь.

#cross_account #cross_region #CloudWatch