IAM

Описание

IAM - Identity and Access Management - сервис авторизации и предоставления доступа. Сервис позволяет пользователям, авторизованным при помощи MultiPass, получить доступ к ресурсам NWS, сервисам и API партнеров и к закрытым ресурсам. Результат работы сервиса - контролированный администратором при помощи кода доступ к любым ресурсам и сервисам NWS.

IAM реализует следующие концепции управления доступом:

Access Control List ACL
Resource Based Access Control RBAC
Attribute Based Access Control, также известна как Policy Based Access Controll ABAC/PBAC

Пример

❓ Задача: Разрешить доступ к корпоративному Docker/OCI репозиторию сервиса ECR по адресу https://ecr.nws.neurodyne.pro/v2/my-corp/backend пользователю c ID = 11111 для таких действий:

Просмотр доступных образов - ecr:ListImages
Просмотр доступных тагов для каждого образа - ecr:ListImageTags
Скачать образ - ecr:PullImage

Все остальные пользователи не должны иметь возможность никакого доступа к корпоративному репозитарию, даже для read-only. Как реализовать 🤔 ?

На вскидку, нужно минимум две вещи:

Авторизовать каждый запрос к API репозитария через token
Для каждого пользователя нужен механизм, который позволяет заранее и безопасно указать набор методов, которые может вызывать пользователь.

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

Любой DevOps инженер или опытный менеджер понимает, что написать, протестировать, интергрировать, задеплоить и потоянно поддерживать, тестировать и обновлять 1M+ политик - дело необычайно трудоемкое и дорогостоящее. Поэтому нужно эффективное решение!

Решение

NWS предлагает IAM Policy, которая решает эту задачу

{
  "Version": "2012-10-17",
  "ID": "w02y5kcu",
  "Statement": [
    {
      "Sid": "Stmt1711799459820",
      "Action": ["ecr:ListImages", "ecr:ListImageTags", "ecr:PullImage"],
      "Effect": "Allow",
      "Resource": "nrn:nws:ecr:ru-msk-0a:${IAM_ACCOUNT_ID}:/v2/my-corp"
    }
  ]
}

В описанной выше политике, ресурс однозначно определяется при помощи Neurodyne Resource Number (NRN), определяемого в формате:

NRN = <tag>:<segment>:<service>:<region>:<account_ID>:<resource_ID>

В нашем примере, NRN выглядит так: nrn:nws:ecr::${IAM_ACCOUNT_ID}:/v2/my-corp.

Далее, действие однозначно определяется при помощи сервиса и назавания API метода:

Action = <service>:<API method name>

В нашем примере, Action выглядит так: Action = ecr:ListImages.

Идентификатор NRN

NRN - Neurodyne Resource Number. Это уникальный идентификатор ресурса в NWS, который однозначно определяет ресурс в любом Region и Availability Zone. Это аналог AWS ARN.

Формат NRN: prefix:segment:service:region:account_id:resource_id, где

prefix: nws
segment: nws
service: ваш сервис, напр. ecr, friends или elb
region: ru-msk-0a
account_id: значение из self
resource_id: /v1/friends например API route для friends

Типы политик

IAM User Policy - политика прикрепляется к конкретному IAM юзеру по ID
IAM Group Policy - политика, которая прикрепляется к группе IAM пользователей
Resource Based Policy - политика прикрепляется к конкретному ресурсу по ID

IAM User Policy

Данный тип политик выглядит примерно так. Данная политика пишется абстрактно и прикрепляется ко множеству отдельных пользователей, за счет чего реализуется эффективный reuse.

{
  "Version": "2012-10-17",
  "ID": "yrkneemq",
  "Statement": [
    {
      "Sid": "Stmt1711651077557",
      "Action": ["grafana:CreateWorkspace", "grafana:DeleteWorkspace"],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:grafana:${Region}:1111:/foo/bar",
        "arn:aws:grafana:${Region}:2222:/${ResourceType}/${ResourceId}"
      ]
    }
  ]
}

IAM Group Policy

Данный тип политик технически не отличается от IAM User Policy, но прикрепляется уже не к отдельному пользователю, а к группе. В результате, все пользователи в группе унаследуют данную политику.

Resource Based Policy

Данный тип политик кардинально отличается от первых двух. Тут политика определяется для конкретного ресурса напр, S3 bucket, и сама же политика определяет, КТО может ее применять. Механизм указания разрешенных пользователей реализуется через концепцию Principal.

{
  "Version": "2012-10-17",
  "ID": "gwzn4to4",
  "Statement": [
    {
      "Sid": "ListAllBucket",
      "Action": ["s3:ListAllMyBuckets", "s3:ListBucket"],
      "Effect": "Allow",
      "Principal": ["$(IAM_ACCOUNT_ID)", "$(IAM_GROUP_ID)"],
      "Resource": ["arn:aws:s3:::*"]
    },
    {
      "Sid": "AllObjectActionsMyBuckets",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Effect": "Allow",
      "Principal": "*",
      "Resource": ["arn:aws:s3:::test", "arn:aws:s3:::test/*"]
    }
  ]
}

В примере выше у нас 2 вложенных statements внутри политики - ListAllBucket и AllObjectActionsMyBuckets.

Для ListAllBucket, Principal задается конкретными IAM_ACCOUNT_ID и IAM_GROUP_ID. Это значит, что только эти ID могут применять эту политику. Для всех остальных применение этой политики запрещено.

Для AllObjectActionsMyBuckets, Principal задается в виде *, что означает, что политика применяется для ВСЕХ пользователей NWS.

Вычисление политик

На практике в production будет задаваться множество политик, как для пользователя, так и для группы. Например, IAM Account ID 1234567 унаследует часть политик от группы My-Corp/Admin, а часть политик будет наложена в на него лично. При этом, политики могут противоречить друг другу, например групповая политика будет иметь "Effect": "Allow", а личная будет "Effect": "Deny". В этом случае, политики будут вычисляться по правилам ниже

Личная политика имеет приоритет над групповой
Deny имеет приоритет над Allow

Дополнительные ресурсы

NWS IAM реализует множество концепций от Amazon Web Services IAM, поэтому для дополнительной информации можно обратится к ресурсам AWS

Описание​

Пример​

Решение​

Идентификатор NRN​

Типы политик​

IAM User Policy​

IAM Group Policy​

Resource Based Policy​

Вычисление политик​

Дополнительные ресурсы​