AWS Notes
5.59K subscribers
450 photos
42 videos
10 files
2.81K links
AWS Notes — Amazon Web Services Educational and Information Channel

Chat: https://t.iss.one/aws_notes_chat

Contacts: @apple_rom, https://www.linkedin.com/in/roman-siewko/
Download Telegram
S3 Object Ownership — решение проблемы длиной в 15 лет:

https://docs.aws.amazon.com/AmazonS3/latest/dev/enable-object-ownership.html

В чём проблема вообще?

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

»»» Вариант с переключением в роль аккаунта В исправляет проблему, однако это уже другой сценарий, решающий проблему с помощью IAM.
Как было раньше? (с момента создания S3 в 2004-м году)

Для решения этой проблемы использовался ключик bucket-owner-full-control, который добавлял на копируемый объект "Permission": "FULL_CONTROL" для владельца аккаунта бакета.

Скопируем файл из аккаунта А в бакет аккаунта В:

aws --profile=account-A s3 cp file.txt s3://my-bucket-account-B/

Смотрим права сохранённого объекта:

aws --profile=account-A s3api get-object-acl --bucket my-bucket-account-B --key file.txt
{
"Owner": {
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
}
]
}

Файл лежит в бакете аккаунта В, но полный владелец (Owner) лишь у аккаунта А. Владелец В ничего не сможет сделать с файлом (но будет платить за него).

Теперь скопируем файл с ключиком bucket-owner-full-control:

aws --profile=account-A s3 cp file.txt s3://my-bucket-account-B/ --acl bucket-owner-full-control

Теперь права изменились:

{
"Owner": {
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
},
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-B",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Permission": "FULL_CONTROL"
}
]
}

В список Grantee имеющий полный доступ FULL_CONTROL добавился и аккаунт В.

Но владелец Owner по-прежнему аккаунт А!

Чем это плохо? Какая разница — владелец или полные права?

Для аккаунта В без разницы. Но как только вы попытаетесь скачать этот файл из аккаунта С (который также имеет все права на работу с бакетом В) — получите отлуп! И понятно почему — ведь ему владелец файла из аккаунта А не разрешал доступ к объекту, его нет в списке Grantee.

На этом неочевидном, сложном и крайне неприятном косяке сильно валились и валятся многие мульти-аккаунтные проекты. Тонкие вещи с добавлением прав аккаунту С с помощью флажка --grant-full-control это весьма специфичный и редко возможный вариант.

И как теперь?

Теперь, если включить для бакета S3 Object Ownership = bucket owner preferred, то при копировании файла без флажка bucket-owner-full-control ничего не изменится. А вот с ним - произойдёт чудо:

{
"Owner": {
"DisplayName": "account-B",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
    "DisplayName": "account-B",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Permission": "FULL_CONTROL"
}
]
}

Полноправным (и единственным) владельцем (Owner) файла из аккаунта А стал акаунт В! Больше никаких проблем, характерных ранее для #shared_bucket!

Итого

Потому отныне можно рекомендовать всегда включать S3 Object Ownership = bucket owner preferred — логику работы оно не меняет (точней — исправляет), при этом бесплатно и проблем будет меньше.

#S3
1
Forwarded from CloudSec Wine
This media is not supported in your browser
VIEW IN TELEGRAM
🔸iam-policies-cli

A CLI tool for building simple to complex IAM policies based on CloudFormation templates.

https://github.com/mhlabs/iam-policies-cli

#aws
Forwarded from CloudTechRU
Бесплатные имена доменов для опытов с Route53, и load balancers можно зарегать в https://my.freenom.com/
Не благодарите, Ваш капитан )
​​Tagger — инструмент для работы с тэгами:

https://github.com/IT-EXPERTS-AT/tagger

#tags
​​У Slack серьёзные проблемы со вчерашнего дня:

https://www.dailymail.co.uk/sciencetech/article-8807179/Slack-users-unable-send-receive-messages-chat-service.html

Страница статуса:

https://status.slack.com/

Если не работает десктоп-клиент — не забывайте про браузерный вариант, он может работать:

https://app.slack.com/ssb/add

#Slack
Советы по работе с AWS Organizations от производителя:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html

Рекомендации для мастер-аккаунта и для подаккаунтов.
Основные:
▪️ не используйте публичные почтовые сервисы (бо̀льшая вероятность взлома)
▪️ обязательно включайте MFA
▪️ блокируйте root-юзеров в подаккаунтах с помощью SCP
▪️ периодически проверяйте процесс восстановления доступа к аккаунту (чтобы проверить, что всё нужное для этого есть у нужных людей)
▪️ создайте/обновляйте документацию по процессу восстановления доступа

#best_practices #Organizations
CloudFormation умер, да здравствует CDK!

https://aws.amazon.com/blogs/developer/migrating-cloudformation-templates-to-the-aws-cloud-development-kit/

Как было раньше?

Чтобы подцепить в CDK какой-то имеющийся свой CloudFormation шаблон, который невозможно, сложно или просто лень было переписывать на CDK, то можно было использовать CfnInclude:

https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_core.CfnInclude.html

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

Как теперь?

Начиная с версии CDK 1.63 (т.е. с сентября 2020-го) можно существующий шаблон подцепить к CDK и рулить им уже полностью через него!

То есть, к примеру, имеем работающий (задеплоенный) CloudFormation стэк, который создаёт VPC. Идём в консольку, копируем его шаблон в my-vpc-template.json, и прописываем это имя templateFile (ниже пример для TypeScript):

const cfnInclude = new cfn_inc.CfnInclude(this, 'Template', {templateFile: 'my-vpc-template.json' });

И теперь полностью рулим стэком из CDK и можно работать с подцеплёнными ресурсами отдельно. То есть, например, нужно поменять какую-то подсетку в VPC. Цепляем её по имени ресурса, используемого в шаблоне (в моём случае это имя subnetVpc4DmzA):

const subnetA = cfnInclude.getResource('subnetVpc4DmzA') as ec2.CfnSubnet;

И меняем её параметры:

subnetA.mapPublicIpOnLaunch = false;

Делаем cdk deploy и CloudFormation стэк изменён! В него добавились CDKMetadata параметры и дальше уже нужен только CDK, никакого CloudFormation!

#CDK
Forwarded from El Ruso
классная библиотека для тех у кого много лямбд https://awslabs.github.io/aws-lambda-powertools-python/
есть java версия https://github.com/awslabs/aws-lambda-powertools-java
Ваше воскресное чтиво - первая ступень в нашем глубоком погружении в Amazon DynamoDB.

Что есть DynamoDB, в чем ее отличие от других NoSQL СУБД, как создать таблицу и что-то в нее записать - в этом обзорном материале.

Для смелых духом и опытных амазонщиков этот пост покажется излишне легким, но вам остается лишь чуть-чуть подождать.

Дальше будет гораздо сложнее и больше.
Forwarded from CloudSec Wine
🔸A visual introduction to AWS Lambda permissions

Article explaining with visual examples the AWS Lambda permission model, focusing on cross-account access and the principle of least privilege.

https://dev.to/harprit/a-visual-introduction-to-aws-lambda-permissions-1k87

#aws
​​Kubernetes 1.18 для EKS:

https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html

Спустя официального релиза 1.18 прошло чуть более полугода.

Сделанный в прошлый раз прогноз на эту версию был неточен на неделю. С учётом этого можно предположить, что версия 1.19 на Амазоне появится прямо в подарок 8 марта.

#EKS
 AWS Budgets Actions:

https://aws.amazon.com/blogs/aws-cost-management/get-started-with-aws-budgets-actions/

Когда есть особые требования или просто чтоб случайно не ошибиться и в цикле миллионы раз произвести какую-то дорогую операцию, то можно добавить действие на превышение бюджета, чтобы с помощью SCP её автоматически заблокировать.

В простом случае это может быть, напримре, SCP на запрет запуска виртуалок.

#Budgets
Git для начинающих.

Кто удачно разобрался сам или успешно научил других — посоветуйте, пожалуйста, ресурсы, которые вам помогли разобраться с Git (и/или GitHub). Ибо по данной теме находится много, но зная предмет сложно оценить, насколько это подойдёт для тех, кто (совсем) не знает.

Желательно на русском, можно в личку или в комментарии.