Kubernetes nginx ingress + тайм-аут внешней аутентификации oauth2
Я пытаюсь защитить страницу состояния службы с помощью oauth2_proxy, используя Azure AD в качестве внешнего поставщика проверки подлинности. В настоящее время, если я перехожу к общедоступному URL-адресу приложения (https://sub.domain.com/service/hangfire), я получаю тайм-аут 504 шлюза, где он должен направлять меня на аутентификацию.
Я в основном следил за этим руководством для справки: https://msazure.club/protect-kubernetes-webapps-with-azure-active-directory-aad-authentication/
Если я отключу аннотации, направляющие аутентификацию, я смогу без проблем попасть на общедоступную страницу статуса. Если я перехожу к https://sub.domain.com/oauth2, я получаю запрос на аутентификацию у моего провайдера, чего я и ожидал. Я не уверен, где проблема заключается в конфигурации входа, но мне не удалось найти подобные случаи в Интернете, stackoverflow или иным образом.
В этом случае все (развертывание oauth, служба и правила входа) находится в пространстве имен «dev», за исключением фактического развертывания входа, которое находится в своем собственном пространстве имен. Я не подозреваю, что это имеет значение, но завершение SSL обрабатывается шлюзом за пределами кластера.
развертывание oauth2:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: oauth2-proxy
spec:
replicas: 1
selector:
matchLabels:
app: oauth2-proxy
template:
metadata:
labels:
app: oauth2-proxy
spec:
containers:
- name: oauth2-proxy
image: quay.io/pusher/oauth2_proxy:v3.2.0
imagePullPolicy: IfNotPresent
args:
- --provider=azure
- --email-domain=domain.com
- --upstream=http://servicename
- --http-address=0.0.0.0:4180
- --azure-tenant=id
- --client-id=id
- --client-secret=number
env:
- name: OAUTH2_PROXY_COOKIE_SECRET
value: secret
ports:
- containerPort: 4180
protocol : TCP
---
apiVersion: v1
kind: Service
metadata:
labels:
app: oauth2-proxy
name: oauth2-proxy
spec:
ports:
- name: http
port: 4180
protocol: TCP
targetPort: 4180
selector:
app: oauth2-proxy
Правила входа:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: service-ingress1
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/auth-url: https://sub.domain.com/oauth2/auth"
nginx.ingress.kubernetes.io/auth-signin: https://sub.domain.com/oauth2/start?rd=$https://sub.domain.com/service/hangfire"
spec:
rules:
- host: sub.domain.com
http:
paths:
- path: /service/hangfire
backend:
serviceName: service
servicePort: 80
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: service-oauth2-proxy
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: sub.domain.com
http:
paths:
- path: /oauth2
backend:
serviceName: oauth2-proxy
servicePort: 4180
Я получаю 504 ошибки при переходе по URL-адресу, но я не вижу никаких ошибок во входных модулях.
У меня есть полное доменное имя хоста входящего трафика. Поэтому, если бы я выполнял этот вход для google.com, я бы поместил его в восходящий поток.
Спасибо. Это то, что я понял, но я не мог заставить его работать. В конце концов, для меня проблема заключалась в том, что файлы cookie, передаваемые Azure AD, были слишком большими для обработки Nginx, что приводило к сбою перенаправления. Единственное реальное решение — запустить сервер Redis для управления файлами cookie. Было довольно сложно отладить эту проблему, поэтому, если кто-то еще столкнется с этим, посмотрите: github.com/oauth2-proxy/oauth2-proxy/issues/866
Ответы 3
Вот что я делал с моим прокси-сервером oAuth для Azure AD:
annotations:
kubernetes.io/ingress.class: "nginx"
ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"
nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"
И я использовал этот прокси-сервер oAuth:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: oauth2-proxy
namespace: kube-system
spec:
replicas: 1
selector:
matchLabels:
app: oauth2-proxy
template:
metadata:
labels:
app: oauth2-proxy
spec:
containers:
- env:
- name: OAUTH2_PROXY_PROVIDER
value: azure
- name: OAUTH2_PROXY_AZURE_TENANT
value: xxx
- name: OAUTH2_PROXY_CLIENT_ID
value: yyy
- name: OAUTH2_PROXY_CLIENT_SECRET
value: zzz
- name: OAUTH2_PROXY_COOKIE_SECRET
value: anyrandomstring
- name: OAUTH2_PROXY_HTTP_ADDRESS
value: "0.0.0.0:4180"
- name: OAUTH2_PROXY_UPSTREAM
value: "http://where_to_redirect_to:443"
image: machinedata/oauth2_proxy:latest
imagePullPolicy: IfNotPresent
name: oauth2-proxy
ports:
- containerPort: 4180
protocol: TCP
Это выглядит почти так же, как у меня. Не могли бы вы опубликовать больше входных данных службы? К сожалению, я просто получаю эти 504 ошибки на входе без реальных ошибок. Единственное, в чем я не уверен, так это в «OAUTH2_PROXY_UPSTREAM», это должна быть конечная точка внутренней службы или внешний URL-адрес?
он должен быть там, где вы перенаправляете после авторизации (для меня это внутренняя служба), конечно, он выглядит похоже, но это не то же самое, так что вам лучше попробовать этот, потому что у меня он работает без проблем
Не могли бы вы уточнить, что именно должно быть http://where_to_redirect_to:443? У меня проблемы с этим. IP-адрес «service-ingress1» (как определено рассматриваемым OP)? ClusterIP службы за входом?
поднимите новый вопрос, вместо того, чтобы задавать вопросы в комментариях
вверх по течению может быть конечной точкой службы kubernetes
Моя установка аналогична 4c74356b41.
развертывание прокси-сервера oauth2
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: oauth2-proxy
name: oauth2-proxy
namespace: monitoring
spec:
replicas: 1
selector:
matchLabels:
app: oauth2-proxy
template:
metadata:
labels:
app: oauth2-proxy
spec:
containers:
- args:
- --azure-tenant=TENANT-GUID
- --email-domain=company.com
- --http-address=0.0.0.0:4180
- --provider=azure
- --upstream=file:///dev/null
env:
- name: OAUTH2_PROXY_CLIENT_ID
valueFrom:
secretKeyRef:
key: client-id
name: oauth2-proxy
- name: OAUTH2_PROXY_CLIENT_SECRET
valueFrom:
secretKeyRef:
key: client-secret
name: oauth2-proxy
- name: OAUTH2_PROXY_COOKIE_SECRET
valueFrom:
secretKeyRef:
key: cookie-secret
name: oauth2-proxy
image: quay.io/pusher/oauth2_proxy:v3.1.0
name: oauth2-proxy
oauth2-прокси-сервис
apiVersion: v1
kind: Service
metadata:
labels:
app: oauth2-proxy
name: oauth2-proxy
namespace: monitoring
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: http
selector:
app: oauth2-proxy
type: ClusterIP
oauth2-прокси-вход
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
labels:
app: oauth2-proxy
name: oauth2-proxy
namespace: monitoring
spec:
rules:
- host: myapp.hostname.net
http:
paths:
- backend:
serviceName: oauth2-proxy
servicePort: 80
path: /oauth2
конфигурация oauth2-прокси
apiVersion: v1
kind: Secret
metadata:
labels:
app: oauth2-proxy
name: oauth2-proxy
namespace: monitoring
data:
# Values below are fake
client-id: AAD_CLIENT_ID
client-secret: AAD_CLIENT_SECRET
cookie-secret: COOKIE_SECRET
Приложение, использующее AAD Ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=$request_uri
nginx.ingress.kubernetes.io/auth-url: https://$host/oauth2/auth
labels:
app: myapp
name: myapp
namespace: monitoring
spec:
rules:
- host: myapp.hostname.net
http:
paths:
- backend:
serviceName: myapp
servicePort: 80
path: /
tls:
- hosts:
- myapp.hostname.net
Дополнительным шагом, который необходимо выполнить, является добавление URI перенаправления в регистрацию приложения AAD. Перейдите к регистрации приложения AAD на портале Azure > Аутентификация > Добавить https://myapp.hostname.net/oauth2/callback в URI перенаправления > Сохранить.
Спасибо за публикацию, ваша конфигурация очень похожа на мою. Странно, что я получаю 504 тайм-аута, и в журналах nginx ничего не отображается, похоже, что аннотации аутентификации просто нарушают для меня входную конфигурацию. Есть ли у вас какие-либо другие изменения конфигурации nginx? Насколько я знаю, я использую стандартную конфигурацию, но я не видел никаких особых изменений конфигурации, упомянутых при ее реализации.
В итоге я нашел разрешение здесь: https://github.com/helm/charts/issues/5958
Мне пришлось использовать адрес внутренней службы для URL-адреса авторизации, о котором я больше нигде не упоминал.
nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.development.svc.cluster.local:4180/oauth2/auth
Что у вас здесь как
-upstream=http://servicenameименно? Я не могу понять, что здесь ожидается.