Comments 11
Спасибо за статью, как раз возникла необходимость настроить авторизацию используя oauth2.
Возможно задавались вопросом как с помощью dex сделать возможным добавление ingress oauth2 с минимальными затратами?
Решение oauth2_proxy требует деплоя сервиса в каждый namespace(поправьте если не прав), очень не хотелось бы это делать.
Возможно задавались вопросом как с помощью dex сделать возможным добавление ingress oauth2 с минимальными затратами?
Решение oauth2_proxy требует деплоя сервиса в каждый namespace(поправьте если не прав), очень не хотелось бы это делать.
Вам нужна именно авторизация (не аутентификация)?
Аутентификация с помощью oauth2 включается легко для ингресса. А вот авторизацию уже надо реализовывать на уровне приложения или RBAC.
Да, у нас для внутренних сервисов в кубере включена аутентификация для всех ингрессов (prometheus, grafana, alertmanager, kibana, etc). Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).
Аутентификация с помощью oauth2 включается легко для ингресса. А вот авторизацию уже надо реализовывать на уровне приложения или RBAC.
Решение oauth2_proxy требует деплоя сервиса в каждый namespace(поправьте если не прав), очень не хотелось бы это делать.
Да, у нас для внутренних сервисов в кубере включена аутентификация для всех ингрессов (prometheus, grafana, alertmanager, kibana, etc). Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).
В идеале хотелось бы иметь возможность использования именно авторизации, а конкретно — разграничение доступа по группе пользователя с помощью dex и groups. Немного контекста: занимаюсь настройкой dev площадки, планируется использование kube для динамического создания окружений, плюс там же нужен мониторинг этих окружений. Разграничение которое хотелось бы иметь это возможность давать доступ к мониторингу пользователям из групп dev/devops, к окружениям для тестирования — всем кто прошел авторизацию, но думаю если учесть сложность реализации такого решения и получаемой выгоды необходимость этого выглядит сомнительно.
Не хотелось этого делать во избежания дублирования одинаковых приложений и экономии ресурсов, но это не принципиально. Для избежания дублирования возможно использовать FQDN сервиса авторизации в аннотации к ingress(решение отсюда) что решает проблему.
Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).
Не хотелось этого делать во избежания дублирования одинаковых приложений и экономии ресурсов, но это не принципиально. Для избежания дублирования возможно использовать FQDN сервиса авторизации в аннотации к ingress(решение отсюда) что решает проблему.
В идеале хотелось бы иметь возможность использования именно авторизации, а конкретно — разграничение доступа по группе пользователя с помощью dex и groups.
Dex это умеет для групп (организации и команды в GitHub, группы в Microsoft accounts), для каждой группы будет своя RBAC-политика. Мы хотели сделать такое с гуглом, но не заработало. Хотели отказаться от basic auth и закрыть все с белым листов айпишников, но нужно в вайтлист добавлять много айпишников и создавать internal LB.
Кейс у Вас в принципе похож с нашим.
По ссылке отличное решение, но у нас немного по-другому, у нас на приложение стоит basic auth, которое конфиг-сниппетом отключается его для офисных адресов и VPN.
можно обойтись одним oauth2_proxy и ингрессами с Auth Request. смотрите сюда
thenewstack.io/single-sign-on-for-kubernetes-dashboard-experience
github.com/pusher/oauth2_proxy/tree/whitelist-domains
пример ингресса:
со стороны oauth2_proxy:
правда я смержил whitelist-domains с мастером и сбилдил свой имэдж что бы были и --pass-authorization-header с --set-authorization-header и --whitelist-domain
thenewstack.io/single-sign-on-for-kubernetes-dashboard-experience
github.com/pusher/oauth2_proxy/tree/whitelist-domains
пример ингресса:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-url: "https://OAUTH2_PROXY_ADDRESS/oauth2/auth"
nginx.ingress.kubernetes.io/auth-signin: "https://OAUTH2_PROXY_ADDRESS/oauth2/start?rd=https://$host$request_uri$is_args$args"
nginx.ingress.kubernetes.io/configuration-snippet: |
auth_request_set $token $upstream_http_authorization;
proxy_set_header Authorization $token;
name: dashboard
namespace: kube-system
spec:
rules:
- host: ADDRESS
http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 80
path: /
tls:
- secretName: SECRET
hosts:
- ADDRESSсо стороны oauth2_proxy:
args:
- --email-domain=example.com
- --upstream=file:///dev/null
- --http-address=0.0.0.0:8080
- --redirect-url=https://OAUTH2_PROXY_ADDRESS/oauth2/callback
- --provider=oidc
- --oidc-issuer-url=https://DEX_ADDRESS
- --cookie-domain=.example.com
- --whitelist-domain=.example.com
- --pass-authorization-header=true
- --set-authorization-header=true
- --pass-basic-auth=false
- --pass-access-token=false
правда я смержил whitelist-domains с мастером и сбилдил свой имэдж что бы были и --pass-authorization-header с --set-authorization-header и --whitelist-domain
Мы используем такую же схему для Dashboard, для kubectl такое сделать не получится.
почему не получится? у нас сейчас реализовано именно так. oauth2_proxy и dex находятся в одном месте, так же как и dexK8sAuthenticator. Дkя дашбордов ингрессы в один auth2_proxy. на всех кластерах прописан oidc один dex. в dexK8sAuthenticator в configmap добавлены несколько кластеров для генерации всего в одном месте
storage наверное лучше сделать kubernetes а не локальный sqlite
Sign up to leave a comment.
Аутентификация в Kubernetes с помощью GitHub OAuth и Dex