AWS Notes
Відкрити в Telegram
AWS Notes — Amazon Web Services Educational and Information Channel Chat: https://t.me/aws_notes_chat Contacts: @apple_rom, https://www.linkedin.com/in/roman-siewko/ No ads.
Показати більше5 801
Підписники
+124 години
-27 днів
+330 день
Архів дописів
5 801
Как было раньше? (с момента создания 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 — логику работы оно не меняет (точней — исправляет), при этом бесплатно и проблем будет меньше.
#S35 801
S3 Object Ownership — решение проблемы длиной в 15 лет:
https://docs.aws.amazon.com/AmazonS3/latest/dev/enable-object-ownership.html
В чём проблема вообще?
При копировании файла из аккаунта А в бакет аккаунта В (в котором есть права для работы с ним из аккаунта А) — владельцем файла (объекта) является/остаётся аккаунт А. То есть админ аккаунта В видит, что у него в бакете есть файл, но ни скачать, ни получить какие-то данные он нём не может.
»»» Вариант с переключением в роль аккаунта В исправляет проблему, однако это уже другой сценарий, решающий проблему с помощью IAM.
5 801
Рекомендации по удалённой сдаче AWS сертификации от производителя:
https://aws.amazon.com/blogs/training-and-certification/5-tips-for-a-successful-online-proctored-aws-certification-exam/
Если коротко:
• Во время сдачи есть/перекусить будет нельзя
• Прерывать сдачу (выходить или впускать кого-то в комнату) нельзя
• Общение с экзаменатором лишь на английском или японском
• Стоит протестировать соединение с интернетом
• Бронировать дату-время сдачи заранее
• Не пропустить письмо с подтверждением даты забронированного экзамена
• Присоединиться можно за полчаса до начала экзамена, чтобы решить все вопросы заранее
#AWS_Certification
5 801
Amazon Timestream:
https://aws.amazon.com/blogs/aws/store-and-access-time-series-data-at-any-scale-with-amazon-timestream-now-generally-available/
Timestream — serverless база данных для IoT и других систем с Time Series данными.
#Timestream
5 801
Helm + ECR
Для стандартизации процессов в Kubernetes окружениях, использующих Helm для деплоя сервисов удобно иметь и чарты в виде докер-образов. Такая возможность на текущий момент в Helm доступна лишь в экспериментальном режиме:
export HELM_EXPERIMENTAL_OCI=1
В докер-реестрах других провайдеров такая поддержка уже была раньше, наконец, с сентября 2020-го года она есть и в ECR:
https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html
Настроим переменные:
ECR_AWS_ID=123456789012
ECR_REGION=eu-central-1
CHART_DIR=my-chart
REPO_NAME=helm-repo
IMAGE_TAG=build-1
HELM_REGISTRY=${ECR_AWS_ID}.dkr.ecr.${ECR_REGION}.amazonaws.com
HELM_ECR_ADDRESS=${HELM_REGISTRY}/${REPO_NAME}:${IMAGE_TAG}
Сохраняем чарт:
helm chart save ${CHART_DIR} ${HELM_ECR_ADDRESS}
Логинимся Хелмом в реестр (aws-cli version 2):
aws ecr get-login-password --region ${ECR_REGION} | helm registry login --username AWS --password-stdin ${HELM_REGISTRY}
Пушим чарт в ECR:
helm chart push ${HELM_ECR_ADDRESS}
Спулить чарт из ECR:
helm chart pull ${HELM_ECR_ADDRESS}
Распаковать чарт в текущую папку:
helm chart export ${HELM_ECR_ADDRESS}
Распаковать чарт в нужную папку (останется изначально имеющаяся вложенность):
helm chart export ${HELM_ECR_ADDRESS} --destination some-dir
#ECR #Helm5 801
Теперь можно задать диапазон IP-адресов для EKS кластера:
https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html
#EKS
5 801
SCP и мастер (root) AWS-аккаунт
Стоит помнить, что "всемогущие" политики SCP, которые так удобно можно применять ко всей организации — не применяются к юзерам и ролям мастер аккаунта (root-аккаунта):
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
Потому, если, например, думаете, включать или не включать CloudTrail в регионах, что планируете запретить через SCP — однозначно стоит включать. Уже лишь как раз по причине того, что в мастере SCP не сработает, а две защиты лучше, чем одна (в подаккаунтах).
#SCP #Organizations
5 801
🔸Security Architecture Review Of A Cloud Native Environment
Walkthrough of a cloud security assessment performed on an organisation which had recently moved their infrastructure from an on-prem to a cloud native solution (AWS).
https://notsosecure.com/security-architecture-review-of-a-cloud-native-environment/
#aws
5 801
Продолжение отличной серии по стратегии тэгирования AWS:
https://www.cloudforecast.io/blog/maintain-aws-tags-when-you-fall-behind-part-3/
#tags #best_practices
5 801
Продолжаем тему PHP + Serverless, новый пост опубликован: https://aws.amazon.com/ru/blogs/rus/introducing-the-serverless-lamp-stack-part-2-relational-databases/
5 801
S5Cmd - S3 на стеройдах
Сегодня расскажу про проект S5Cmd - отличный open source инструмент (изначально написанный ребятами из Peak Games) для ускорения и кастомизации процессов между S3 и локальной файловой системой. Три ключевых момента:
- скорость - S5Cmd написан на Go, максимально использует возможности параллельной обработки и transfer acceleration; собственно perfomance тесты есть на странице проекта (и ниже напишу свои результаты)
- привычная работа по маске (wildcard support); без всех этих exclude и include, которыми оперирует aws-cli
- работа в пакетном режиме на основе текстового командного файла либо pipe конвеера, что открывает произвольные варианты интеграции с unix shell
Чтобы не быть голословным, приведу результаты локального теста. Исходные установки: есть бакет, в котором хранятся разбитые по датам данные нескольких проектов. То есть s3://bucket-name/YYYY/MM/DD/prj1..., prj2..., и т.д. Каждый проект состоит из нескольких файлов. Копирую себе данные за один день по одному проекту:
1. В aws-cli это выглядит так:
s3 cp s3://bucket-name/2020/09/27/ ./ --exclude "*" --include "prj1*" --recursive
- минута и 43 секунды. Замечу, что несмотря на плоскую структуру внутри дня, без recursive не обойтись
2. В s5cmd это выглядит лаконичнее:
cp 's3://bucket-name/2020/09/27/prj1*' ./
- 37 секунд - в три раза быстрее
Дополнительно попробовал batch-режим, собрав предварительно с помощью ls и awk файл, где каждая строка - это копирование одного объекта. Здесь получилось 54 секунды за счёт какой-то задержки на старте (видимо файл парсится во внутреннюю структуру для исключения конфликтов, например сочетания команд копирования и удаления). Однако это всё равно довольно хорошо, если использовать командный файл по назначению - как сценарий разнородных действий.
Рекомендую присмотреться, если у вас есть соответствующие задачи (например, работа с данными s3 на серверной стороне за рамками AWS-инфраструктуры). Авторы из Amazon инструмент также хвалят.5 801
Наконец-то вышло обновление AWS Extend Switch Roles для переключения между аккаунтами с исправлением для работы в преобразившейся недавно AWS консоли.
Обратите внимание, что теперь список аккаунтов для переключения располагается не как раньше в менюшке самой AWS консоли, а при нажатии на сам ключик расширения (см. картинку).
5 801
С сегодняшнего для при покупке Savings Plan можно указывать дату в будущем, что удобно чтобы не держать эту дату в голове, когда у вас заканчивается предыдущий Savings Plan - https://aws.amazon.com/about-aws/whats-new/2020/09/queuing-purchases-of-savings-plans/
5 801
Darko Meszaros: "Infrastructure IS Code on AWS":
https://www.youtube.com/watch?v=b7h2G6YidKs&t=567
Видео с DevSecOps конференции, прошедшей 24 сентября 2020-го года.
#video
5 801
🔸Awesome AWS S3 - Security, Tools and Intel
Collection of tools, techniques and useful links concerning security and exposed AWS S3 Buckets
https://github.com/mxm0z/awesome-sec-s3#awesome-aws-s3---security-tools-and-intel
#aws
5 801
T3 инстансы для Amazon Elasticsearch Service:
https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-supported-instance-types.html
В дополнение к дешёвым
t2.micro/small/medium.elasticsearch доступны t3.small.elasticsearch и t3.medium.elasticsearch, которые стоят столько же, но быстрей и позволяют использовать до 100ГБ и 200ГБ места соответственно (в отличие от 35ГБ для всех T2).
#ES
Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
