Keskitaso

Kubernetes-ympäristön ja verkkopalvelimien toiminnan tuntemus on välttämätöntä. On myös hyödyllistä tietää, miten tunnistautuminen toimii. Tässä ohjeessa käytetään OpenShiftin komentorivityökalua oc

OAuth2 Proxyn käyttöönotto Rahdissa

Selitämme, miten OAuth2 Proxy otetaan käyttöön ja miten sitä käytetään tunnistautumisen hallintaan käyttäen palveluntarjoajia kuten Google, GitHub ja muita.

Tässä ohjeessa katsomme, miten GitHubia käytetään.

Warning

Tämä on yksinkertainen proof of concept. Luonnollisesti sovelluksesi pitäisi pystyä hallitsemaan pääsyä ryhmien, sähköpostin, käyttäjänimen jne. perusteella.

Ota verkkosovelluksesi käyttöön

Ensin otamme käyttöön hyvin yksinkertaisen verkkosovelluksen, tämän flask demon. Seuraa ohjeita GitHub-repositoriosta.

Älä luo Routea, sitä ei tarvita, koska käytämme NGINX:ää käänteisenä välityspalvelimena.

Ota NGINX käyttöön

Voit käyttää NGINX-imagoamme NGINXin ajamiseen Rahdissa (OpenShift 4).

Rahdissa voit rakentaa imagen suoraan. Lisätietoja täällä

Suorita tämä komento:

oc new-app https://github.com/CSCfi/nginx-okd

Kun koonti on valmis, suorita tämä komento Route-resurssin luomiseksi:

oc create route edge flask-demo --service=nginx-okd --hostname=demo-oauth2.2.rahtiapp.fi --insecure-policy='Redirect' --port=8081

Info

Voit asettaa oman --hostname-arvosi. Tässä esimerkissä käytämme Rahdin oletusdomainia 2.rahtiapp.fi.

Voit myös käyttää omaa domainiasi, mutta tässä tapauksessa sinun täytyy luoda Ingress. Lisätietoja täällä

Meidän täytyy luoda erityinen määritys, jotta NGINX toimii käänteisenä välityspalvelimena. Tätä varten käytämme ConfigMapia

Luo uusi configmap.yaml-tiedosto:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-default
data:
  default.conf: |
    server {
      listen 8081; # NGINX service port
      server_name demo-oauth2.2.rahtiapp.fi; # The same as the --hostname created previously in the Route

    location /oauth2/ {
      proxy_pass       http://oauth2-proxy:4180;
      proxy_set_header Host                    $host;
      proxy_set_header X-Real-IP               $remote_addr;
      proxy_set_header X-Auth-Request-Redirect $request_uri;
      # or, if you are handling multiple domains:
      # proxy_set_header X-Auth-Request-Redirect $scheme://$host$request_uri;
    }

    location = /oauth2/auth {
      proxy_pass       http://oauth2-proxy:4180;
      proxy_set_header Host             $host;
      proxy_set_header X-Real-IP        $remote_addr;
      proxy_set_header X-Forwarded-Uri  $request_uri;
      # nginx auth_request includes headers but not body
      proxy_set_header Content-Length   "";
      proxy_pass_request_body           off;
    }

    location / {
      root   /usr/share/nginx/html;
      index  index.html index.htm;
      auth_request /oauth2/auth;
      error_page 401 =403 /oauth2/sign_in;

      # pass information via X-User and X-Email headers to backend,
      # requires running with --set-xauthrequest flag
      auth_request_set $user   $upstream_http_x_auth_request_user;
      auth_request_set $email  $upstream_http_x_auth_request_email;
      proxy_set_header X-User  $user;
      proxy_set_header X-Email $email;
      proxy_set_header Host $http_host;

      # if you enabled --pass-access-token, this will pass the token to the backend
      auth_request_set $token  $upstream_http_x_auth_request_access_token;
      proxy_set_header X-Access-Token $token;

      # if you enabled --cookie-refresh, this is needed for it to work with auth_request
      auth_request_set $auth_cookie $upstream_http_set_cookie;
      add_header Set-Cookie $auth_cookie;

      # When using the --set-authorization-header flag, some provider's cookies can exceed the 4kb
      # limit and so the OAuth2 Proxy splits these into multiple parts.
      # Nginx normally only copies the first `Set-Cookie` header from the auth_request to the response,
      # so if your cookies are larger than 4kb, you will need to extract additional cookies manually.
      auth_request_set $auth_cookie_name_upstream_1 $upstream_cookie_auth_cookie_name_1;

      # Extract the Cookie attributes from the first Set-Cookie header and append them
      # to the second part ($upstream_cookie_* variables only contain the raw cookie content)
      if ($auth_cookie ~* "(; .*)") {
          set $auth_cookie_name_0 $auth_cookie;
          set $auth_cookie_name_1 "auth_cookie_name_1=$auth_cookie_name_upstream_1$1";
      }

      # Send both Set-Cookie headers now if there was a second part
      if ($auth_cookie_name_upstream_1) {
          add_header Set-Cookie $auth_cookie_name_0;
          add_header Set-Cookie $auth_cookie_name_1;
      }

      proxy_pass http://course-flask-demo:8080/; # Set your backend, where you should be redirected. Here, our flask-demo webapp. It is the service name and its port.
    # or "root /path/to/site;" or "fastcgi_pass ..." etc
    }

      error_page   500 502 503 504  /50x.html;
      location = /50x.html {
        root   /usr/share/nginx/html;
      }
    }

Lisätietoja tästä määrityksestä löydät OAuth2 Proxyn verkkosivustolta

Tärkeimmät tässä ConfigMapissa muokattavat arvot ovat:

• listen 8081: tämä vastaa NGINX-palvelun porttia
• server_name: sama kuin aiemmin Routessa luotu --hostname
• proxy_pass: aseta taustapalvelusi, johon sinut pitäisi ohjata. Tässä tapauksessa flask-demo-verkkosovelluksemme. Se on palvelun nimi ja sen portti.

Ota ConfigMap-määritys käyttöön:

oc apply -f configmap.yaml

Luo GitHub OAuth Apps -sovelluksesi

Sinun täytyy mennä kohtaan GitHub > OAuth Apps

Napsauta kohtaa New OAuth App

Täytä eri kentät:

• Application Name: anna nimi GitHub OAuth -sovelluksellesi
• Homepage URL: verkkosovelluksesi etusivu. Tässä esimerkissä se on NGINX-käänteisen välityspalvelimen Route (https://demo-oauth2.2.rahtiapp.fi)
• Authorization callback URL: sovelluksesi callback-URL. Tässä esimerkissä se on muotoa https://demo-oauth2.2.rahtiapp.fi/oauth2/callback

Ota OAuth2 Proxy käyttöön

OAuth2 Proxyn käyttöönottoon käytämme .yaml-tiedostoa. Luo uusi tiedosto nimeltä oauth2.yaml ja kopioi tämä:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: oauth2-proxy
  template:
    metadata:
      labels:
        k8s-app: oauth2-proxy
    spec:
      containers:
      - args:
        - --provider=github
        - --client-id=<CLIENT_ID_FROM_GITHUB>
        - --client-secret=<CLIENT_SECRET_FROM_GITHUB>
        - --redirect-url=https://demo-oauth2.2.rahtiapp.fi/oauth2/callback
        - --email-domain=*
        - --reverse-proxy=true
        - --upstream=static://200
        - --http-address=0.0.0.0:4180
        - --set-authorization-header=true
        - --set-xauthrequest=true
        - --pass-access-token=true
        - --pass-authorization-header=true
        - --pass-user-headers=true
        - --pass-host-header=true
        - --cookie-secret=<YOUR_COOKIE_SECRET>
        image: quay.io/oauth2-proxy/oauth2-proxy:latest
        imagePullPolicy: Always
        name: oauth2-proxy
        ports:
        - containerPort: 4180
          protocol: TCP
        resources: {}

---

apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
spec:
  ports:
  - name: http
    port: 4180
    protocol: TCP
    targetPort: 4180
  selector:
    k8s-app: oauth2-proxy

Tärkeimmät asiat ovat:

• --provider=github
• --client-id= kopioi aiemmin luoduista GitHub OAuth Apps -sovelluksista
• --client-secret= kopioi aiemmin luoduista GitHub OAuth Apps -sovelluksista
• --cookied-secret= voit luoda sellaisen suorittamalla tämän komennon: docker run -ti --rm python:3-alpine python -c 'import secrets,base64; print(base64.b64encode(base64.b64encode(secrets.token_bytes(16))));'

Kun tämä on tehty, ota määritys käyttöön:

oc apply -f oauth2.yaml

Melkein valmista

Nyt kun meillä on:

1. verkkosovelluksemme
2. NGINX käänteisenä välityspalvelimena
3. GitHub OAuth App
4. OAuth2 Proxy käyttöönotettuna

Meidän täytyy kertoa NGINXille, että sen tulee kommunikoida OAuth2 Proxymme kanssa, joka ottaa yhteyden GitHubiin, jotta voimme käyttää verkkosovellustamme.

Tässä on kaavio:

Muistatko, että loimme aiemmin ConfigMapin? Mikä sen tarkoitus on? Siitä tulee NGINXin uusi oletusmääritystiedosto.

Luo patch-configmap.yaml-tiedosto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-okd
spec:
  template:
    spec:
      containers:
        - name: nginx-okd
          volumeMounts:
            - mountPath: /etc/nginx/conf.d/
              name: nginx-default
      volumes:
        - configMap:
            name: nginx-default
            defaultMode: 420
          name: nginx-default

Paikkaa deploymentisi:

oc patch deploy/nginx-okd --patch-file=patch-configmap.yaml

Tämä käynnistää automaattisesti uuden NGINX-podin käyttöönoton.

Kun podi on valmis, voit kokeilla uutta määritystäsi. Avaa verkkosovelluksesi sivusto (sen pitäisi olla NGINXin käyttöönoton aikana luotu Route, eli tässä esimerkissä https://demo-oauth2.2.rahtiapp.fi).

Sinun pitäisi nähdä OAuth2 Proxyn etusivu ja Sign in with GitHub -painike.

Jatka

Kun olet vahvistanut tunnistetietosi ja antanut GitHubille pääsyn dataasi, sinut pitäisi ohjata verkkosovellukseen:

Muutama huomio

Onneksi olkoon! Onnistuit ottamaan OAuth2 Proxyn käyttöön verkkosivustollesi pääsyä varten.

Pidä mielessä, että tämä esimerkki ei hallitse nimeä, käyttäjänimeä tai sähköpostia. Hyvän sovelluksen täytyy pystyä tarkistamaan esimerkiksi sähköposti ja sallimaan tai estämään käyttäjän pääsy sovelluksiin sen perusteella.

Tässä on esimerkki OAuth2 Proxysta yhdessä Kubernetes-Dashboardin kanssa: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/#example-oauth2-proxy-kubernetes-dashboard

Tässä esimerkissä on mahdollista antaa pääsy klusteriin hallitsemalla käyttäjän sähköpostia kubernetes RBACin avulla

Onko tämä sivu hyödyllinen?

Kyllä

Kiitos palautteestasi!

Ei

Kiitos! Arvostamme palautettasi.

Kerro meille miten voisimme parantaa tätä sivua ottamalla meihin yhteyttä.