Прикручиваем ActiveDirectory авторизацию к Kubernetes c помощью Keycloak

[iavael]

По инструкции видно, что автор многое делает наобум (причем, некоторые вещи в ущерб безопасности):

• Много лишних 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 без скрипта

[remez]

Помогите советом, как реализовать конфигурацию:
1. класть пользовательскую группу из LDAP в токен при его выдаче
2. извлекать группу из токена гэйткипером
3. проверяли groups или audience для реализации RBAC на уровне доступа до POD в k8s

[iavael]

1. Нужно в настройках клиента во вкладке client scopes добавить groups в Assigned Default Client Scopes
2. про использование групп в 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
   
3. • 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-а)