Site Tools


IAM

Сервис, призванный осуществлять AAA на просторах всего Amazon. Здесь мы можем производить множество различных настроек для ограничения или наоборот расширения доступа пользователей. Как сказано в связанной статье стоит учитывать, что настройки биллинга для учётных записей, созданных через IAM будут доступны только после поворота определённой ручки в настройках Root аккаунта.

Полиси

Перед тем как начинать что-то делать стоит немного разобраться с тем каким образом в AWS IAM можно объявить доступ к тем или иным ресурсам. Amazon предоставляет огромное количество заранне подготовленных полисей практически на все случаи жизнь, но это не повод отказываться от удовольствия понять как это работает и зачем нужно. Конечно же есть длинная статья на этот счёт, как и на многие другие, но кто мы такие, чтобы её читать. Будем вот тут вот разбираться вместе. Итак, полиси, которая описывает разрешения для доступа к объектам внутри Amazon представляет из себя весьма заурядный JSON. Возьмём за пример TranslateFullAccess:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "translate:*",
                "comprehend:DetectDominantLanguage",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics",
                "s3:ListAllMyBuckets",
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "iam:ListRoles",
                "iam:GetRole"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

Собственно в привере выше представлены основные поля и объекты, которые позволяют настроить доступы и разрешения к тем или иным ресурсам:

  • Version - поле обязательное, как по мне отражает версию схемы внутри JSON< чтобы AWS понял какие поля искать, типичный анкор для версионирования API
  • Statement - массив из непосредственно правил, разрешающих и/или запрещающих
    • Объект правила
      • Action - набор сервисов и методов, при вызове которых будет применяться данная полиси, поддерживаются Wildcard
      • Resource - ARN1) с которыми можно работать, поддерживает Wildcard
      • Effect - очевидно что произойдёт при совпадении Action и Resource, проще говоря разрешить или запретить пользователю выполнять эти действия

Правил может быть великое множество на все случаи жизни, интересный вопрос как будут работать несколько правил где в одном что-то запрещается, а во втором это что-то разрешается, но я думаю там всё просто и выполняется слияние всех правил в одну security-схему, где кто последний, тот и папа, однако утверждать это я не берусь и есть конечно же инструкция, в которой всё описано2)

Группы

Следующий уровень абстракции это группы пользователей. Тут всё достаточно просто - группа это просто связка между набором полисей и пользователями, позволяет объединять людей, например, по отделам, чтобы впоследствии было проще рулить их доступами. В общем и целом ресурс достаточно очевидный и сложно что-то ещё добавить про него.

Роли

А вот это интересный ресурс, который на первый взгляд выглядит так же, как и группа, но является совершенно иным способом выдачи прав. Начнём с того, что роли напрямую не связаны с пользователями и служат скорее для того, чтобы внутри AWS иметь возможность раздать ресурсам и сервисам доступ к други частям AWS. Например мы можем создать роль, которая позволит EC2 инстансам напрямую работать с S3 через API через так называемые Short Term Credentials без создания отдельной учётной записи в IAM. Наглядный пример:

  1. Создаём роль, которая позволит нам иметь доступ к API s3
    1. Выбираем сервис которому разрешить
    2. Теперь выбираем для этого сервиса полиси, которое опишет права доступа
    3. Ну и конечно же вводим название новой роли
  2. Теперь идём в EC2 и покупаем бесплатную виртуалку
    1. Переходим в EC2 и нажимаем большую рыжую кнопку “Launch instance”
    2. Выбираем нужный образ
    3. Выбираем нужные ресурсы (в нашем случае Free tier чтобы денежку не тратить) и нажимаем на Configure Instance Details
    4. И вот здесь в IAM Role выбираем нашу роль
    5. Жмякаем Review and Launch, нам предложат выбрать или создать SSH ключ для доступа внутрь. Я уже добавил свой, так что буду использовать его
  3. Виртуалка запустилась, мы в неё провалились и теперь та самая магия, о которой я говорил ранее - получаем временные ключи доступа в соответствии с нашей ролью
    1. Смотрим какие роли нам доступны через
      curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

    2. И запрашиваем веременные ключи, добавив в конец запроса имя роли
      curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2ROAccessToS3

    3. Берём AccessKeyId, SecretAccessKey, подсовываем их в aws-cli и пользуемся благами API в рамках дозволенных нам доступов

Пользователи

Ну и наконец самое важное, центральная, можно сказать, точка IAM - пользователи. Есть два типа доступов с помощью IAM:

  • Management console access - доступ через вебморду к сервисам Amazon (через имя организации, пользователя и пароль)
  • Programmatic access - доступ через API (используя секретный ключ и токен)

Добавление достаточно тривиально, заходим в блок Users и нажимаем рыжую кнопку New User. Попадаем на страничку для ввода имени пользователя и типов доступа

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

Я создам группу, чтобы вопследствии было удобнее и навешу на неё полисю

Полиси для группы выглядит следующим образом

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::*/*",
                "arn:aws:s3:::pldslv"
            ]
        }
    ]
}

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

Теперь настраиваем aws-cli и попробуем посмотреть все бакеты в s3

В соответствии с нашей полиси нам это не удастся, а вот если мы посмотрим конкретный бакет - всё получится (правда пока у нас там пусто)

Чтобы там не было пусто попробуем загрузить нашу статику

И у нас это успешно получается, теперь попробуем посмотреть то, что в бакете, а после что-нибудь удалить

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

1)
Amazon Resource Name - проще говоря уникальный идентификатор ресурса внутри Amazon
2)
ну или ты можешь сам потыкать и разобраться, почему нет