​​Наконец-то вышло обновление AWS Extend Switch Roles для переключения между аккаунтами с исправлением для работы в преобразившейся недавно AWS консоли.

Обратите внимание, что теперь список аккаунтов для переключения располагается не как раньше в менюшке самой AWS консоли, а при нажатии на сам ключик расширения (см. картинку).

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 инструмент также хвалят.

Продолжаем тему PHP + Serverless, новый пост опубликован: https://aws.amazon.com/ru/blogs/rus/introducing-the-serverless-lamp-stack-part-2-relational-databases/

Солидному человеку — солидная ссылка:

AWS Ambassadors - Epam

​​Продолжение отличной серии по стратегии тэгирования AWS:

https://www.cloudforecast.io/blog/maintain-aws-tags-when-you-fall-behind-part-3/

#tags #best_practices

🔸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

​​SCP и мастер (root) AWS-аккаунт

Стоит помнить, что "всемогущие" политики SCP, которые так удобно можно применять ко всей организации — не применяются к юзерам и ролям мастер аккаунта (root-аккаунта):

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

Потому, если, например, думаете, включать или не включать CloudTrail в регионах, что планируете запретить через SCP — однозначно стоит включать. Уже лишь как раз по причине того, что в мастере SCP не сработает, а две защиты лучше, чем одна (в подаккаунтах).

#SCP #Organizations

​​Теперь можно задать диапазон IP-адресов для EKS кластера:

https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html

#EKS

Напомню, что сегодня CDK day. Начало в 17:00 по Киеву/Минску/Москве.

Кто не в курсе, CDK — возможность описывать инфраструктуру для AWS, Kubernetes или Terraform с помощью привычного языка программирования. Стоит посетить, чтобы просто ознакомиться с возможностями.

CDK day в прямом эфире:

https://www.youtube.com/watch?v=qJutZqXMdgM

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 #Helm

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

Рекомендации по удалённой сдаче AWS сертификации от производителя:

https://aws.amazon.com/blogs/training-and-certification/5-tips-for-a-successful-online-proctored-aws-certification-exam/

Если коротко:

• Во время сдачи есть/перекусить будет нельзя
• Прерывать сдачу (выходить или впускать кого-то в комнату) нельзя
• Общение с экзаменатором лишь на английском или японском
• Стоит протестировать соединение с интернетом
• Бронировать дату-время сдачи заранее
• Не пропустить письмо с подтверждением даты забронированного экзамена
• Присоединиться можно за полчаса до начала экзамена, чтобы решить все вопросы заранее

#AWS_Certification

Terraform → CDKtf конвертер:

https://github.com/iann0036/hcl2cdktf

#CDK #Terraform

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

🔸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

Бесплатные имена доменов для опытов с 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