Всем привет! Значит, запилили у нас SecOps полиси: все должны ходить в AWS через Okta (identity provider), пользователей в аккаунтах мы забираем.
Реализовали через концепцию hub & spoke: вы логиньтесь в Hub account, а из него через switch role уже идите в нужный. Напряжно, ну ладно, привыкли.
Ну и доку SecOps не написали, как работать с CLI, Terraform, aws cli, etc. И оно в таком состоянии жило, т.к. сразу же кто-то придумал сделать один service account, и через него запускать все cli-тулы.
Получается, что Okta уже заадоптили, а используем сервисный аккаунт. Ну ладно, подумал я, как-то в следующий раз обязательно исправлю (... нет) 🙂
И вот добираюсь я до задачи, которая относится к AWS EKS: пару месяцев назад я сделал selenium grid cluster для QA в AWS EKS, и теперь понадобилось дать туда kubectl доступ для ребят из Support тимы (они нам помогают делать всякие не сложные штуки по инфраструктуре, на смене 24/7).
А там iam authenticator. Пришлось разбираться!
Итого:
1) Сначала пришлось научиться и описать доку, как работать с aws-okta:
https://github.com/segmentio/aws-okta
2) Потом правильно настроить ~/.aws/config (aws_saml_url и source_profile) для каждого из аккаунтов
3) Подконфигурить
aws-auth конфигмапу, и дать доступ для всех кто смог сделать assume spoke role 4) Завелось!
Что же происходит: aws-okta идет в Hub аккаунт, там ее встечает Okta, присылает push notification на смартфон, потом aws-okta делает switch role в Spoke аккаунт, и уже оттуда через IAM получает доступ в kubectl 😳
aws-okta exec okta-elite -- kubectl get pod --all-namespaces 👍Если кто-то совсем не понял о чем заметка, то вот референсы:
🔹 https://segment.com/blog/secure-access-to-100-aws-accounts/ - Как сделать Hub & Spoke архитектуру аккаунтов чтобы удобно было (все равно не удобно 😄)
🔹 https://aws.amazon.com/premiumsupport/knowledge-center/amazon-eks-cluster-access/ - Как добавить пользователей/группы в EKS кластер, и почему по умолчанию доступ есть только у создателя