Opendistro работает с ad

Ад - там решаемо. Сам эластик - свой и был через nginx+ldap модуль

надо поднять свой сервис, в который юзеры  логинятся, сервис потом сам  любым способом решает, какую роль дать пользователю, дёргает STS AssumeRole, получает токен, как то хитро его подписывает и редиректит юзера на AWS Console  с этим токеном в запросе. всё , юзер залогинен с нужными правами

Спасибо. Я где-то так и обрисовал картинку для себя. Хотел услышать второе мнение, не упускаю ли я чего, может есть эта штука из коробки.
Конфликт в том, что AD тима упирается, говорит много контроля даем моей тиме (AWS SSO SCIM). Предложили изучить вопрос OpenID connect. Ну так тут еще больше контроля, плюс явный колхоз.

Еще раз пишу пусть opendistro глянут

почему много контроля? членство в группах же по SCIM приезжает? т.е. контроль у AD

Спасибо, но я же не по эластику :) то Денису

(сам SCIM ни разу не настраивал, пишу только о том что читал)

Ты не подходишь для оценки этой ситуации. У тебя голова не квадратная :) а там похоже это критерий на собеседовании

Мэп группы на IAM роли делаем мы, но руками в мастер Пеер никто не ходит.

а в SAML, тот что  у вас сейчас, разве они мапят?

Мы мапим :) ну через граф апи, с сервис юзера с фул доступом :)))

и SAML  и в SCIM группы приезжают из AD, мапинг в IAM в обоих случаях на ваше стороне. Чем SCIM с их точки зрения хуже?

сложно понять издалека. выглядит как обычные энтерпрайзные тёрки :)

Так и есть. Чем больше компания, тем больше дуристики. Из моего опыта.

Сделать кастомный триггер на sign-in и там решать какую роль навестить юзеру

есть еще вот такая штука: https://github.com/aws-samples/aws-secure-environment-accelerator

чтобы ррррраз и в дамки

Да модная нынче тема. Меня хантила Ауди через кого-то. Они такую штуку тоже пилят.

Но лично я считаю, единого решения для большого проекта быть не может.

У нас очень злобные рестрикшины. На любых крупных Энтерпрайзах обычно такое. Для этого как нельзя лучше подходит терраформ + сентинел полиси.

AWS Control Tower в  каждом аккаунте конфигурирует SNS топик в центральном Audit аккаунте как AWS Config delivery channel. Разумно. Дальше начинается странное. Тоже в каждом аккаунте еще заводится следующее:

- AWS EventBridge правило , которое матчит "Compliance Change" событие от AWS Config
- target этого правила - местный (внутри аккаунта) SNS топик
- на SNS топик повешана лямба, которая шлёт всё  в  другой SNS топик в центральном Audit аккаунте.

Почему так заковыристо? Ведь:
-  можно просто сделать AWS Config Aggregator внутри организации и получать всё в одном месте без всяких SNS
- ну ОК, если вдруг нельзя, то можно из AWS EventBridge в каждом аккаунте слать в SNS топик напрямую в центральном аккаунте
- ну ОК, если вдруг и это нельзя, то можно из AWS Event Bridge в каждом аккаунте дёргать сразу  лямбду, зачем через локальный SNS топик делать?