Комментарии 3
По инструкции видно, что автор многое делает наобум (причем, некоторые вещи в ущерб безопасности):
- Много лишних flow у клиента (хотя, по сути, нужен только standard code flow), и при этом включены ненужные service account и authorization
- Groups claim зачем-то засовывается в access_token, хотя нужен только в id_token и только для kubectl
- Без причины юзается общий клиент для kubectl и для gatekeeper-а, что позволяет скомпрометировать всю конфигурацию replay-атакой. Правильнее было бы завести отдельный public client для kubectl с обязательным pkce-s256
- Костыль c audience mapper можно было сделать просто статическим через Audience mapper без скрипта
Помогите советом, как реализовать конфигурацию:
1. класть пользовательскую группу из LDAP в токен при его выдаче
2. извлекать группу из токена гэйткипером
3. проверяли groups или audience для реализации RBAC на уровне доступа до POD в k8s
1. класть пользовательскую группу из LDAP в токен при его выдаче
2. извлекать группу из токена гэйткипером
3. проверяли groups или audience для реализации RBAC на уровне доступа до POD в k8s
- Нужно в настройках клиента во вкладке client scopes добавить groups в Assigned Default Client Scopes
- про использование групп в gatekeeper, в общем-то, неплохо написано в документации:
Тут про ограничения на уровне самого гейткипера по членству в группах
github.com/louketo/louketo-proxy/blob/master/docs/user-guide.md#group-claims
Тут про проброс в заголовки, чтобы группы из токена мог использовать бэкенд
github.com/louketo/louketo-proxy/blob/master/docs/user-guide.md#upstream-headers
- a) audience проверяет сам kubernetes-apiserver, и только на предмет того, что токен был выписан для аутентификации именно в apiserver-е, там нет особых опций, надо просто сделать так, чтобы client-id в keycloak и в параметрах apiserver-а совпадали
- b) просто настраиваете по мануалу kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens и у вас при аутентификации в kubectl (или напрямую в kubeapi) через keycloak у юзера oidc:username появляется членство в группах oidc:group1, oidc:group2 и т.д. (префиксы у юзеров и групп, в данном случае я привел «oidc:», задаются через параметры apiserver-а), ну а дальше уже задаете юзеров/группы в ролебиндингах (что уже относится к управлению доступами на уровне самого kubernetes-а)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прикручиваем ActiveDirectory авторизацию к Kubernetes c помощью Keycloak