хранения пользователей заюзать какой-нибудь ldap, а стыковать его со всем остальным через OIDC типа keycloak. Вопрос: как правильно с этой т.з. организовать машинный доступ к сервисам? Хотелось бы какую-нибудь единую точку входа типа облачного 169.254.169.254, к которому можно было бы аттачить некоторые роли (ну и уже на них навешивать правила).
как это правильно делается в приличных домах?
т.е. хотелось бы какую-нибудь выдавалку токенов, которые потом сможет съесть любой другой сервис (прикрученный к проверялке токенов, да)
SSO с PUM, сиемом, 2fa дансгардианом, радиусом, макацлами, блекджеком и шлюхами (насколько паранои хватит). На внутренний домен вешается просто редиректилка на авторизацю которая при заходе отдает что то неавторизованному клиенту и потом в зависимости от роли (можно в том же лдапе побить) отдает токен и после авторизации пускает туда куда роутит правило конкретной политики ролей (хош во влан, хош по-локейшну, можно чего угодно прикрутить).
угу угу, ну тут всё приблизительно понятно. Вопрос скорее в сторону того, как аутентифицировать и авторизовать сервисы друг с другом. Условно говоря есть внутренний s3 и хотелось бы пускать конкретные сервисы в конкретные бакеты, при этом не запихивая в деплойменты секреты, а чтобы они генерились на лету. Т.е. такой знаешь STS на минималках (если я правильно понимаю для себя сущность STS)
Токены одноразовые в голову приходят, погляди на pam модуль google 2fa
ну pam это опять-таки пользовательская аутентификация, а мне нужны короткоживущие токены для сервисов, чтобы сервис при старте мог сходить куда-нибудь по хттп и получить свои доступы (в идеале вообще никак себя не идентифицируя). Т.е. крутится эта система в кубе, прилетел ей запрос, оно там посмотрело из какого пода прилетел запрос, сопоставило под с ролью и выдало ровно те привилегии, которые сконфигурированы для этого деплоймента
апишка тебе нужна с одноразами с хранением их в редиске какой нибудь
мне кажется, что мы сейчас изобретём что-то, чем полмира уже пользуется :)
Обсуждают сегодня