Ресурсы, которые можно тэгировать

В дополнение к Tag-Based Access Control - апишка для работы с тэгами:

https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/Welcome.html

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

#tags #ABAC

⁠ ABAC + AD FS

Опять в продолжение Tag-Based access control (или официально ABAC - Attribute-Based Access Control) - очередные подробности, как и говорилось, о гибкой работе данной схемы с AD:

https://aws.amazon.com/blogs/security/attribute-based-access-control-ad-fs-simplify-iam-permissions-management/

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

#ABAC #AD

⁠Политики тэгирования - Tag Policies

Tag-Based access control (ABAC) продожает расширяться с взрывной скоростью.

То, чего так не хватало желающим заставить своих девелоперов проставлять нужные тэги там где нужно или просто везде, теперь получите и распишитесь:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html

Т.е. теперь незачем постоянно менять ключи доступа в наказание за непростановку стандартных тэгов для создаваемых EC2-инстансов, а можно прописать политики тэгирования на уровне организации:

{
 "tags": {
  "env": {
    "tag_value": {
      "@@assign": [
        "dev",
        "test",
        "stage",
        "prod"
      ]
    }
  },
  "project": {
    "tag_value": {
      "@@assign": [
        "project1",
        "project2"
      ]
    }
  }
 }
}

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

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

#tags #ABAC #Organizations

Видео по #IAM, #ABAC, #SCP и прочим Access Management тонкостям.

Высокий уровень сложности (Level 400 - Expert, т.е. максимальный по шкале Амазона). Но кому-то это, может, и в плюс - ABAC стратегия описывается весьма детально (обычно лишь общие фразы) и с примерами.

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

#video

EC2 Instance Connect теперь работает через ABAC. Это значит, что для того, чтобы зайти по SSH на виртуалку, теперь достаточно прописать на ней правильные тэги:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-set-up.html#ec2-instance-connect-configure-IAM-role

{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ec2-instance-connect:SendSSHPublicKey",
"Resource": "arn:aws:ec2:eu-west-1:123456789012:instance/*",
"Condition":{
"StringEquals":{
"aws:ResourceTag/my-tag":"my-value"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
}
]
}

Вы всё ещё кипятите Bastion host? Тогда мы идём к вам!

#EC2 #SSH #ABAC

​​ABAC+SSO:

https://aws.amazon.com/blogs/aws/new-attributes-based-access-control-with-aws-single-sign-on/

Прошёл ровно год с появления ABAC (Attribute-Based Access Control) или Tag-Based Access Control. И вот теперь при наличии SSO давать доступ к ресурсам стало ещё проще и удобней.

Включаем ABAC на страничке настроек SSO (на картинке), как заработает, добавляем нужные атрибуты, которые будут пробрасываться. Например, банально username (на картинке). Теперь добавив к любому ресурсу в политики доступа условие:

"Condition": {
 "StringEquals": {
  "ec2:ResourceTag/username": "${aws:PrincipalTag/username}"
 }
}

Можно будет просто зайти в тэги, например, RDS базы данных, и добавить тэг username со значением Karen . В результате пользователь Karen, залогинившись через SSO, автоматически получит доступ к этой базе.

#ABAC #SSO