Продолжая серию видео, чтобы разбить многочасовые оперы по курсам, есть отличный набор коротких (5-10 минут) видео-роликов по архитектуре на амазоне:

https://aws.amazon.com/this-is-my-architecture/

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

#design #video

⁠Отличный источник примеров работы с #CloudFormation #templates (а также #Terraform и #aws_cli) плюс прямые ссылки на документацию, официальные блоги, всяческие безопасности и различные #best_practices:

https://asecure.cloud/

Однозначно в закладки.

#security #info

⁠Появился экспорт #RDS снэпшотов на S3:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html

Аналогично для #Aurora:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html

Можно экспортировать не весь снэпшот, а лишь часть, сохраняется в parquet-формате.

​​Туториал использования SRR (Same-Region Replication) для сбора логов из разных аккаунтов в один бакет:

https://aws.amazon.com/blogs/storage/aggregating-logs-with-s3-same-region-replication/

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

#SRR

⁠AWS Organization Formation = CloudFormation для Organizations

https://github.com/OlafConijn/AwsOrganizationFormation

Утилита реализует IaC (Infrastructure as Code) подход в рамках AWS Organizations, когда описывать аккаунты организации и их характеристики можно (нужно) через привычные по шаблонам CloudFormation yaml-файлы (пример).

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

#Organizations

​​Чтобы расшарить ECR репозиторий (только на чтение - лишь скачать) для всей организации (нужно заменить на свой aws:PrincipalOrgID):

{
 "Version": "2008-10-17",
 "Statement": [
  {
   "Sid": "Organization ReadOnly access",
   "Effect": "Allow",
   "Principal": "*",
   "Action": [
    "ecr:BatchCheckLayerAvailability",
    "ecr:BatchGetImage",
    "ecr:GetDownloadUrlForLayer"
   ],
   "Condition": {
    "StringEquals": {
     "aws:PrincipalOrgID": "o-gs1bsr375"
    }
   }
  }
 ]
}

Данные правила (download only) применяются для других аккаунтов, а для аккаунта, где расположен ECR - регулируется с помощью IAM, которыми можно поставить нужные права (в том числе на upload).

#ECR

Уважаемые москвичи, напоминаю про AWS Meetup 29-го января в 19:00 (случайно совпавший с юбилеем @aws_ru).

Amazon Linux 1 отправлен на пенсию:

https://aws.amazon.com/blogs/aws/update-on-amazon-linux-ami-end-of-life/

10 лет продержался, хватит, пора. Amazon Linux 2 уже два года как правильная замена.

Запись московского AWS митапа:

https://www.youtube.com/embed/UFHCr_rVywQ

SCP для запрета запуска мощных виртуалок

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringNotLike": {
      "ec2:InstanceType": [
        "*.nano",
        "*.micro",
        "*.small",
        "*.medium"
      ]
    }
  }
}

Удобно применять для каких-то sandbox или каких-то личных аккаунтов, чтобы ограничить разработчиков возможностью запускать лишь слабые виртуалки.

#Organizations #SCP #policy

Загадка по IAM

Имеем policy из примера выше про расшаривание ECR репозитория для других аккаунтов.

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

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

Имеются следующие варианты:

1.
{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Resource": "*",
     "Action": [
       "ecr:GetAuthorizationToken"
     ]
   }
 ]
}

2. то же, что 1 плюс GetDownloadUrlForLayer:
{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Resource": "*",
     "Action": [
       "ecr:GetAuthorizationToken",
"ecr:GetDownloadUrlForLayer"
     ]
   }
 ]
}

3. то же, что 2 плюс еще на Batch:
{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Resource": "*",
     "Action": [
       "ecr:GetAuthorizationToken",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage"
     ]
   }
 ]
}

Какой роли минимально достаточно?

#загадка #IAM

Загадка по IAM с одной стороны примитивно простая, а с другой ненормально сложная. Из разряда тех, которыми можно ставить в ступор даже знающих AWS профессионалов. Хороший пример, как и откуда потом берутся утечки информации.

Правильный ответ 1 - по сути, никаких прав IAM роли не нужно (чисто лишь залогиниться на докере GetAuthorizationToken). Кто не верит, может попробовать и убедиться.

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

И правильно учат. Только, как говорится, есть нюансы. И нюанс в том, что управление доступом это не только IAM, но Resource-based политики (JSON, прикреплённый в данном случае к ECR-репозиторию)

В случае мульти-аккаунт схемы для внешних аккаунтов происходит проверка IAM прав юзера (другого аккаунта) и Resource-based policy по очереди. Нет прав IAM - до свидания. Не важно, что там написано в Resource-based policy ресурса.

В случае же одного и того же аккаунта, IAM и Resource-based policy разрешаются одновременно. Т.е. складываем и смотрим. IAM не разрешает (но и не запрещает), а Resource-based policy - разрешает, итого - разрешено!

Кому интересны подробности, то на примере S3 Bucket policy и с разбором исторического подтекста - можно почитать здесь.

#отгадка #IAM

⁠Session Duration Time

Люди, кто мучается при переключении аккаунтов, из-за сессии, подло истекающей через 1 час и сбрасывающей недоделанную в консоли работу в самый неподходящий момент — не мучайтесь, пожалуйста, зайдите и поставьте себе 12 часов session duration time!

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters

Просто дефолтное значение именно 1 час.

Аналогично для SSO:

https://docs.aws.amazon.com/singlesignon/latest/userguide/howtosessionduration.html

Поставь себе 12 часов - и работай спокойно!

#лайфхак #IAM #SSO

Видео с прошедшей 30 января встречи в компании IDT, где попросили выступить с докладом по AWS мульти-аккаунтам, который переделал, чтобы не повторять тот, что был на предыдущем митапе.

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

Самое полезное - это вторые полчаса обсуждения, где было много вопросов. К большому сожалению, самих вопросов, в том числе дискуссии вопрошавших, не слышно.

#video

Инструкция по выбору облака.

#пятничное в понедельник

⁠bare metal инстансы + AWS Console

Когда вы хотите выбрать bare metal инстансы (i3 или или другие *.metal), чтобы, например, соблюсти какие-то жёсткие требования для вашего окружения, то при выборе в консоли по-прежнему обнаружите менюшку Tenancy и Shared по умолчанию.

Ничего такого в реальности нет, никакие Shared неприменимы к bare metal типу инстансов, вы полностью работаете напрямую с железом, без гипервизоров (потому можно запустить свою виртуализацию, что не позволяют другие типы инстансов - на них не получится запустить условный Virtual Box, только на bare metal) и без каких-то "соседей".

Недоработка текущей версии AWS Console.

#AWS_Console #bare_metal #issue

​​Что делать, если утекли ключи:

https://aws.amazon.com/pt/blogs/security/what-to-do-if-you-inadvertently-expose-an-aws-access-key/

Т.е. в общем случае бежим в IAM консоль скомпроментированного аккаунта и деактивируем всё, что деактивируется. Время полного отключения ключей занимает 1-2 минуты (глобально) после нажатия Make inactive.

Предупреждён - значит вооружён.

14 февраля в Минске пройдёт конференция https://delex-conf.com/, где в том числе планировалось, что буду я с докладом, но, к сожалению, у меня в это время не получается. Однако заявленная тема "CI/CD на AWS" не пропадёт и вместо меня её подхватит и расскажет Пётр Сальников, который выступал с докладами на декабрьском AWS митапе в Минске. Так что если вы планировали пойти на delex-конференцию - не пропустите его доклад (15 февраля) про AWS!

Ну, а кто из минчан не хочет ждать и не любит крупные мероприятия, то есть группа AWS Friday, в которой мы договариваемся, где собираться в очередную пятницу, чтобы отдохнуть, поесть и заодно обсудить какую-то тему. Например, в ближайшую будет небольшой доклад и обсудим новые фичи Transit Gateway + Shared VPC и их влияние на пересмотр сетевой архитектуры в AWS.

⁠SSE-S3 (AES 256) - что даёт?

У многих возникает вопрос - что за такое шифрование, которое просто галку поставил и всё типа зашифровано. В чём его смысл, если ничего не нужно делать и все запросы автоматически отдаются, если есть к бакету доступ?

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

Не ленитесь поставить - полезно, несложно, на халяву да и сразу же даёт хоть какое-то ощущение безопасности.

#S3 #security

SCP для запрещения обновления CloudFormation стэков

Если вы деплоите всё с помощью CloudFormation и используете мульти-аккаунт схему, то очень удобно в конце отработки процесса создания/обновления для требующих защиты окружений (читай - prod) накладывать на аккаунт следующее SCP:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": [
       "cloudformation:CreateChangeSet",
       "cloudformation:CreateStack",
       "cloudformation:CreateStackInstances",
       "cloudformation:CreateStackSet",
       "cloudformation:CreateUploadBucket",
       "cloudformation:DeleteChangeSet",
       "cloudformation:DeleteStack",
       "cloudformation:DeleteStackInstances",
       "cloudformation:DeleteStackSet",
       "cloudformation:ExecuteChangeSet",
       "cloudformation:SetStackPolicy",
       "cloudformation:UpdateStack",
       "cloudformation:UpdateStackInstances",
       "cloudformation:UpdateStackSet",
       "cloudformation:UpdateTerminationProtection"
     ],
     "Resource": [
       "*"
     ]
   }
 ]
}

В списке запрещены именно изменяющие действия, просто запретить cloudformation:* неудобно, т.к. тогда не получится зайдя в этот аккаунт посмотреть текущее состояние CloudFormation стэков. А так внешне ничего не меняется, только CI/CD утилиты получат отказ при случайном (или намерянном) запуске - прод в безопасности.

#SCP