Comments 5
Если быть точным, то аутентификация а не авторизация (простите)
Кроме oauth-proxy есть еще gogatekeeper.
КК 19 версии уже староват, берите лучше для тестов самый свежий 23, плюс используйте Statefulset.
Если используете KC_HOSTNAME_STRICT=false, то переменная KC_HOSTNAME_URL не нужна.
Если вывешиваете КК через Ingress, то надо брать сервис ClusterIP а не LoadBalancer.
А как вы в само приложение данные аутентифицированного пользователя пробрасываете? (Сорри если вопрос ламерский - я пока в кубах плаваю совсем)
oauth2-proxy прокитывает дальше в приложение jwt access token в заголовке Authorization, который прилетает из браузера. oauth2-proxy выступает как реверс-прокси перед приложением.
В ingress севисе прописываю в анноцютации
nginx.ingress.kubernetes.io/auth-response-headers: "x-auth-request-user, x-auth-request-email, authorization"
А в oauth2-proxy проставляю параметр
--set-authorization-header=true
Тогда в ее ответе будут нужные хэдеры, которые подставятся в реквест. В случае с кейклоком в хэдере x-auth-request-user будет id пользователя, как будет с гитхабом-не проверял.
Авторизация для приложения в облаке