Аутентификация в Kubernetes с помощью GitHub OAuth и Dex

[zekker6]

Спасибо за статью, как раз возникла необходимость настроить авторизацию используя oauth2.
Возможно задавались вопросом как с помощью dex сделать возможным добавление ingress oauth2 с минимальными затратами?
Решение oauth2_proxy требует деплоя сервиса в каждый namespace(поправьте если не прав), очень не хотелось бы это делать.

[Amet13]

Вам нужна именно авторизация (не аутентификация)?
Аутентификация с помощью oauth2 включается легко для ингресса. А вот авторизацию уже надо реализовывать на уровне приложения или RBAC.

Решение oauth2_proxy требует деплоя сервиса в каждый namespace(поправьте если не прав), очень не хотелось бы это делать.

Да, у нас для внутренних сервисов в кубере включена аутентификация для всех ингрессов (prometheus, grafana, alertmanager, kibana, etc). Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).

[zekker6]

В идеале хотелось бы иметь возможность использования именно авторизации, а конкретно — разграничение доступа по группе пользователя с помощью dex и groups. Немного контекста: занимаюсь настройкой dev площадки, планируется использование kube для динамического создания окружений, плюс там же нужен мониторинг этих окружений. Разграничение которое хотелось бы иметь это возможность давать доступ к мониторингу пользователям из групп dev/devops, к окружениям для тестирования — всем кто прошел авторизацию, но думаю если учесть сложность реализации такого решения и получаемой выгоды необходимость этого выглядит сомнительно.

Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).

Не хотелось этого делать во избежания дублирования одинаковых приложений и экономии ресурсов, но это не принципиально. Для избежания дублирования возможно использовать FQDN сервиса авторизации в аннотации к ingress(решение отсюда) что решает проблему.

[Amet13]

В идеале хотелось бы иметь возможность использования именно авторизации, а конкретно — разграничение доступа по группе пользователя с помощью dex и groups.

Dex это умеет для групп (организации и команды в GitHub, группы в Microsoft accounts), для каждой группы будет своя RBAC-политика. Мы хотели сделать такое с гуглом, но не заработало. Хотели отказаться от basic auth и закрыть все с белым листов айпишников, но нужно в вайтлист добавлять много айпишников и создавать internal LB.

Кейс у Вас в принципе похож с нашим.
По ссылке отличное решение, но у нас немного по-другому, у нас на приложение стоит basic auth, которое конфиг-сниппетом отключается его для офисных адресов и VPN.

[zekker6]

C basic auth и white-list была идея написать небольшой контроллер, который бы дописывал нужные аннотации к dev ingress'ам чтобы избежать опять же ручной работы, но пока это все на стадии идеи:)
Спасибо Вам за советы!

[lbvffvbl]

можно обойтись одним oauth2_proxy и ингрессами с Auth Request. смотрите сюда
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

[Amet13]

Мы используем такую же схему для Dashboard, для kubectl такое сделать не получится.

[lbvffvbl]

почему не получится? у нас сейчас реализовано именно так. oauth2_proxy и dex находятся в одном месте, так же как и dexK8sAuthenticator. Дkя дашбордов ингрессы в один auth2_proxy. на всех кластерах прописан oidc один dex. в dexK8sAuthenticator в configmap добавлены несколько кластеров для генерации всего в одном месте

[Amet13]

Да, я неправильно понял кейс. У Вас же несколько кластеров.

[lbvffvbl]

storage наверное лучше сделать kubernetes а не локальный sqlite

[Amet13]

У нас с local storage не работало, там баг был вроде, а с sqlite заработало.