Utilisation d'oauth2 avec NGinx, oauth2-proxy, Azure AD pour donner un accès sécurisé à une application web.

Publié le 02/04/2023

par Hervé Leclerc

dans kubernetes

⭠ Retour à la liste des articles

Utilisation d'oauth2 avec NGinx,oauth2-proxy, Azure AD pour donner l'accès à une application web

Ce que l'on cherche à faire :

Pré-requis

Un cluster kubernetes (https://azure.microsoft.com/fr-fr/free/)
Un ingress controller basé sur nginx (https://kubernetes.github.io/ingress-nginx)
Un cert-manager pour sécuriser les flux des ingress et générer des certificats ssl (https://cert-manager.io/docs/installation/)
Une souscription Azure avec un compte administrateur pouvant créer des applications et leurs permissions (https://azure.microsoft.com/fr-fr/free/)
les outils classiques pour interagir avec kubernetes (kubectl, krew, kustomize)
Un domaine DNS que vous pouvez manager
Notre application aura pour fqdn demo-site.caas.fr sont url sera https://demo-site.caas.fr
Notre application permettant de gérer l'accès de l'utilisateur aura pour fqdm : auth.caas.fr Ce sera notre oauth2-proxy qui permettra de déléguer l'authentification depuis nginx vers MS Azure.

Principe et processus de l'authentification oauth2

L'authentification OAuth2 permet à une application tierce d'accéder aux données d'un utilisateur sur un service tiers de manière sécurisée et sans avoir besoin de connaître les identifiants de l'utilisateur.

        +--------+                                    +---------------+
        |        |--(A)- Authorization Request ->     |               |
        |        |         Authorization Server       |               |
        |        |                                    |  Utilisateur  |
        |        |<-(B)-- Authorization Grant ------- |               |
        | Client |                                    |               |
        |        |--(C)-- Authorization Grant ------->|               |
        |        |          Resource Server           |               |
        |        |                                    |               |
        |        |<-(D)------ Access Token -----------|               |
        |        |                                    |               |
        |        |--(E)------ Access Token----------->|               |
        |        |            Protected Resource      |               |
        |        |                                    |               |
        |        |<-(F)------- Ressource demandée-----|               |
        |        |                                    |               |
        |        |--(G)------- Ressource demandée---->|               |
        |        |            Utilisateur             |               |
        +--------+                                    +---------------+

L'application tierce demande l'autorisation d'accéder aux données de l'utilisateur en envoyant une requête d'autorisation au service tiers.
Le service tiers redirige l'utilisateur vers sa page d'authentification où il doit entrer ses identifiants et autoriser l'application tierce.
Si l'utilisateur autorise l'application tierce, le service tiers génère un jeton d'accès et le renvoie à l'application tierce.
L'application tierce utilise le jeton d'accès pour accéder aux données de l'utilisateur auprès du service tiers.

Pour configurer l'authentification OAuth2 avec Microsoft AD, l'administrateur doit créer une application Azure AD, configurer les autorisations requises et fournir à l'application cliente les identifiants de l'application (ID client et clé secrète). L'application cliente peut ensuite utiliser ces identifiants pour demander des jetons d'accès OAuth2 au serveur d'autorisation.

L'authentification OAuth2 avec Azure AD offre plusieurs avantages, notamment :

La sécurité : l'utilisateur n'a pas besoin de fournir ses identifiants de connexion à l'application tierce, ce qui réduit le risque de compromettre ses informations d'identification.
La simplicité : l'application tierce n'a pas besoin de stocker les informations d'identification de l'utilisateur, ce qui simplifie la gestion des informations d'identification.
L'évolutivité : l'authentification OAuth2 peut être utilisée pour autoriser l'accès à plusieurs applications tierces, ce qui permet une évolutivité facile et une gestion centralisée des autorisations.

Pour NGinx, nous allons déléguer l'authentification à oauth2-proxy qui fera tout le travail 😏

Proxy oauth2

Un proxy OAuth2 est un serveur intermédiaire qui permet à une application d'obtenir un jeton d'accès OAuth2 pour accéder à une ressource protégée par un fournisseur d'identité OAuth2.

Plus précisément, lorsqu'une application souhaite accéder à une API ou à une ressource protégée, elle doit obtenir un jeton d'accès valide auprès du fournisseur d'identité OAuth2. Le processus d'obtention d'un jeton d'accès peut être complexe et nécessite une communication entre l'application, le fournisseur d'identité et l'utilisateur final.

Le proxy OAuth2 agit comme un intermédiaire entre l'application et le fournisseur d'identité OAuth2, en gérant le processus d'authentification et d'autorisation à la place de l'application. En conséquence, l'application peut simplement envoyer une requête au proxy OAuth2 pour obtenir un jeton d'accès valide sans avoir à gérer le processus d'authentification complexe.

Le projet oauth2-proxy

https://github.com/oauth2-proxy/oauth2-proxy

Le projet OAuth2 Proxy prend en charge plusieurs fournisseurs d'identité OAuth2 tels que Google, GitHub, Okta, Keycloak, Azure Active Directory, etc. Il offre également la possibilité de personnaliser l'apparence et le comportement du proxy en utilisant des fichiers de configuration. En résumé : OAuth2-Proxy est un projet open-source qui fournit une solution facile à utiliser pour sécuriser les ressources web avec l'authentification et l'autorisation basées sur OAuth2.

En outre, le projet OAuth2 Proxy offre des fonctionnalités de gestion des sessions, de gestion des cookies, de réécriture des URL et de journalisation des événements.

Il est aisé à déployer, extensible et peut être utilisé avec n'importe quelle application web qui prend en charge le protocole OAuth2.

La démo

Je vais présenter les manifestes de manière unitaire - Vous pouvez retrouver les sources du projet ici :

https://github.com/alterway/oauth2-azure-ad-nginx

Le projet est construit autour de kustomize ce qui simplifie grandement sa gestion.

Veuillez créer un répertoire demo-oauth2
Puis dans ce répertoire l'arborescence de répertoires suivants :

demo-oauth)
├── base
│   ├── application
│   └── oauth2-proxy
└── demo
    ├── demo-site
    └── oauth2-proxy
        └── secrets

Nous mettrons les manifestes du site de démo dans le répertoire base/application Les manifestes de notre oauth2-proxy dans le répertoire base/oauth2-proxy

Le répertoire demo : nous permettra de lancer les 2 applications dans des namespace différents avec simplement la commande suivante :

kubectl apply -k demo

1. Notre application web

Nous allons utiliser un simple pod que nous exposerons via un service l'application sera accessible via un ingress

Dans répertoire base/application créer les fichiers suivants.

1.1 Pod : podinfo

# podinfo-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: podinfo
  name: podinfo

spec:
  containers:
    - image: ghcr.io/stefanprodan/podinfo:6.3.5
      imagePullPolicy: Always
      name: podinfo
      ports:
        - name: http
          containerPort: 9898
          protocol: TCP
        - name: http-metrics
          containerPort: 9797
          protocol: TCP
        - name: grpc
          containerPort: 9999
          protocol: TCP

1.2 Service : podinfo-svc

# podinfo-svc.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: podinfo-svc

spec:
  ports:
    - name: http
      port: 9898
      protocol: TCP
      targetPort: http
  selector:
    app: podinfo
  sessionAffinity: None
  type: ClusterIP

1.3 Ingress - podinfo-ing-no-oauth

Dans un premier temps, nous allons simplement déployer l'application sans la protéger par oauth2

Une annotation pour demander à notre cert-manager de générer un certificat pour notre site demo-site.caas.fr.
3 annotations pour configurer notre upstream au niveau de nginx.

# podinfo-ing-with-no-auth.yaml
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: podinfo-ing

  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
    nginx.ingress.kubernetes.io/proxy-buffer-size: "32k"
    nginx.ingress.kubernetes.io/proxy-buffers-number: "4"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  labels:
    app: demo-site
    app.kubernetes.io/name: demo-site
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - demo-site.caas.fr
      secretName: demo-site.caas.fr-tls
  rules:
    - host: demo-site.caas.fr
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: podinfo-svc
                port:
                  number: 9898

1.4 un fichier de kustomization nous permettant de référencer les composants qu'on souhaite déployer.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - podinfo-pod.yaml
  - podinfo-svc.yaml
  - podinfo-ing-with-no-auth.yaml
#- podinfo-ing-with-auth.yaml

Nous inverserons les commentaires par la suite.

Vous devez avoir dans le répertoire base/application les fichiers suivants

tree -a base/application
base/application
├── kustomization.yaml
├── podinfo-ing-with-no-auth.yaml
├── podinfo-pod.yaml
└── podinfo-svc.yaml

1 directory, 4 files

1.5 test de l'application sans authentification

Lancer la commande suivante :

kubectl create namespace demo-site
kubectl apply -k base/application -n demo-site

Vérifiez que vous avez un nouveau namespace de créé
Vérifiez que votre application s'execute correctement

kubectl get po,svc,ing -n demo-site

❯ kubectl get po,svc,ing -n demo-site
NAME          READY   STATUS    RESTARTS   AGE
pod/podinfo   1/1     Running   0          100m

NAME                  TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service/podinfo-svc   ClusterIP   10.0.73.123   <none>        9898/TCP   100m

NAME                                    CLASS   HOSTS               ADDRESS          PORTS     AGE
ingress.networking.k8s.io/podinfo-ing   nginx   demo-site.caas.fr   5x.10x.14x.21x   80, 443   100m

Notre application fonctionne correctement, elle est accessible sur l'url : https://demo-site.caas.fr

Il est temps maintenant de protéger notre application avec oauth2

2. Configuration de MS Azure Active Directory

Azure Active Directory (Azure AD) : est un service d'annuaire basé sur le cloud qui offre une authentification et une autorisation sécurisées pour les applications. Il prend en charge OAuth2 pour l'authentification et l'autorisation.

L'utilisation d'OAuth2 dans Azure AD permet à des applications tierces d'accéder aux ressources protégées, en obtenant un jeton d'accès valide pour l'utilisateur ou l'application qui a été authentifié. Pour utiliser OAuth2 avec Azure AD, vous devez configurer votre application en tant que client OAuth2 dans Azure AD. Cela implique de créer une application dans Azure AD et de définir les autorisations nécessaires pour accéder aux ressources protégées.

2.1 Création de l'application au niveau du portail azure

Il est bien sûr possible de créer tous ces objets en ligne de commande avec azure-cli (az). Par simplicité, nous allons le faire par le portail.

Voici la référence si vous souhaitez le faire en ligne de commande. https://learn.microsoft.com/en-us/azure/healthcare-apis/register-application-cli-rest

Sur le portail Azure choisissez : "Azure Active Directory", puis "App registration"

Entrez le nom de l'application, puis choisissez "web", donnez l'adresse du callback en fonction du domaine que vous avez choisi. L'adresse, pour moi, sera https://auth.caas.fr/oauth2/callback, ensuite cliquez sur "Register"

Notez l'url /oauth2/callback, nous la retrouverons au niveau de la configuration du proxy oautht2.

🖍️ Notez dans un fichier l'ID de l'application (client-id), et l'id du tenant Azure AD (tenant-id)
Cliquez sur "Add a certificate or secret"

Sur l'écran de création du secret, choisissez " + New client secret"

Donnez un nom à votre secret, puis choisissez la durée de vie de ce secret, puis cliqez sur "Add"

🖍️ Copiez et sauvegardez dans le fichier ou vous avez notez le client-id et tenant-id la valeur du secret.

Il faut maintenant que vous donniez des permissions à votre application. Nous allons simplement lui donner la possibilité de lire les informations relatives à l'utilisateur (User.Read). Si vous oubliez de donner ces permissions, quand l'oauth2-proxy tentera de récupérer les données de l'utilisateur, vous aurez ce genre de message dans les logs du oauth2-proxy:

 Error while parsing OAuth2 callback: invalid_client
10.224.1.160:49210 - 79cf068c5933876d7e0e16cd80faa593 - - [2023/04/02 13:25:47] demo-oauth2.caas.fr GET - "/oauth2/callback?error=invalid_client&
error_description=AADSTS650056%3a+Misconfigured+application.+This+could+be+due+to+one+of+the+following%3a+the+client+has+not+listed+any+permissions+for
+%27Microsoft+Graph%27+in+the+requested+permissions+in+the+client%27s+application+registration.+Or%2c+the+admin+has+not+consented+in+the+tenant.+Or%2c+check
+the+application+identifier+in+the+request+to+ensure+it+matches+the+configured+client+application+identifier.+Or%2c+check+the+certificate+in+the+request+to
+ensure+it%27s+valid.+Please+contact+your+admin+to+fix+the+configuration+or+consent+on+behalf+of+the+tenant.+Client+app+ID%3a
+a9cdb590-f8bb-4605-b665-04e83c2413aa.%0d%0aTrace+ID%3a+ac9c3636-effe-4afa-86dc-2472c01a9000%0d%0aCorrelation+ID%3a
+72c835db-8aef-4b49-b2de-702fba75f61c%0d%0aTimestamp%3a+2023-04-02+13%3a25%3a47Z&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d650056&
state=pIb1cF54Jc9YDbeC4uhTGTry6mseMG6YIFhCwEYYFik%3ahttps%3a%2f%2fdemo-site.caas.fr%2f" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)

AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 Edg/110.0.1587.63" 403 2808 0.005

Cliquez sur "API Permissions", choisissez "Microsoft Graph"

Il se peut que vous ayez déjà des permissions de posées par défaut. Veuillez vérifier que vous avez a minima la permission "User.Read"

Si ce n'est pas le cas, Choisissez "Delegated permissions", puis filtrer la lister en saisissant "user.read" dans le champ de saisie, Cochez la permission "User.Read", Cliquez sur "Add permission"

Vous aurez certainement à donner "Un Grant Admin Consent" pour cette application et ses permissions. Cliquez sur le bouton vous permettant de donner ce consentement.

Voilà tout est configuré, vous devez avoir un écran semblable à celui-la :

3 Préparation des répertoires pour la demo

3.1 Création du répertoire oauth2-proxy dans le répertoire base

Créer un répertoire oauth2-proxy dans le répertoire base. Si ca n'a pas déjà été fait.

tree -a -d base
base
├── application
└── oauth2-proxy

3 directories

Créer au même niveau que base un réperoire demo
Créer le répertoire demo-site sous demo
Créer le répertoire oauth2-proxy sous demo
Créer le répertoire oauth2-proxy sous le répertoire oauth2-proxy

Vous devez avoir une arborescence identique à celle-ci :

❯ tree -a -d .
.
├── base
│   ├── application
│   └── oauth2-proxy
└── demo
    ├── demo-site
    └── oauth2-proxy
        └── secrets

4. Configuration du oauth2-proxy

J'ai choisi de le faire de manière classique (mode manifeste), Pour bien voir les paramètres utilisés.

Un chart helm existe si vous préférez. https://github.com/oauth2-proxy/manifests/tree/main/helm/oauth2-proxy

4.1 Les secrets

Le secret du cookie :

dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64 | tr -d -- '\n' | tr -- '+/' '-_'; echo

🖍️ Notez la valeur

J'utilise la fonction de "secret generator" de kustomize pour me simplifier la vie.

Mais vous pouvez le faire en ligne de commande ou en manifeste "yaml", si vous préférez.

Par exemple :

kubectl create secret generic oauth2-proxy-secrets \
    --from-literal=oauth2_proxy_cookie_secret=cookie-secret-généré \
    --from-literal=oauth2_proxy_client_id=la-valeur-que-vous-avez-noté-précédemment-pour-le-client-id \
    --from-literal=oauth2_proxy_cookie_secret=la-valeur-que-vous-avez-noté-précédemment-pour-le-secret \
    --from-literal=oauth2_proxy_tenant_id=la-valeur-que-vous-avez-noté-précédement-pour-le-tenant-id

Ou en yaml, Notez que j'utilise stringData pour ne pas à avoir à faire des base64.

❗️ Ne commitez jaimais ce genre de manifestes.

apiVersion: v1
stringData:
  oauth2_proxy_client_id: valeur-que-vous-avez-noté-précédemment-pour-le-client-is
  oauth2_proxy_client_secret: la-valeur-que-vous-avez-noté-précédemment-pour-le-secret
  oauth2_proxy_cookie_secret: cookie-secret-généré
  oauth2_proxy_tenant_id: la-valeur-que-vous-avez-noté-précédement-pour-le-tenant-id
kind: Secret
metadata:
  labels:
    made-by: hl
  name: oauth2-proxy-secrets
type: Opaque

Ou alors créez un fichier oauth2-proxy-secrets dans le répertoire demo/oauth2-proxy/secrets avec le contenu suivant :

Nou verrons plus tard son utilisation avec kustomize

oauth2_proxy_client_id=valeur-que-vous-avez-noté-précédemment-pour-le-client-is
oauth2_proxy_client_secret=la-valeur-que-vous-avez-noté-précédemment-pour-le-secret
oauth2_proxy_cookie_secret=cookie-secret-généré
oauth2_proxy_tenant_id=la-valeur-que-vous-avez-noté-précédement-pour-le-tenant-id

4.2 Les manifestes pour oauth2-proxy

Dans le répertoire base/oauth2-proxy ajoutez les manifestes suivants :

Un déploiement

# oauth2-proxy-deploy.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    application: oauth2-proxy
  name: oauth2-proxy-deployment

spec:
  replicas: 1
  selector:
    matchLabels:
      application: oauth2-proxy
  template:
    metadata:
      labels:
        application: oauth2-proxy
    spec:
      containers:
        # - --pass-access-token=true
        # - --cookie-name=_proxycookie
        # pour azure --session-cookie-minimal  et
        - args:
            - --provider=azure
            - --azure-tenant=<TENANT-ID>
            - --cookie-domain="caas.fr"
            - --email-domain=*
            - --http-address=0.0.0.0:4180
            - --oidc-issuer-url=https://login.microsoftonline.com/<TENANT-ID>/v2.0
            - --whitelist-domain=.caas.fr
            - --skip-provider-button=true
            - --upstream=file:///dev/null
            #- --set-authorization-header=true
            - --session-cookie-minimal=true
          name: oauth2-proxy
          image: quay.io/oauth2-proxy/oauth2-proxy:latest
          imagePullPolicy: Always
          env:
            - name: OAUTH2_PROXY_CLIENT_ID
              valueFrom:
                secretKeyRef:
                  name: oauth2-proxy-secrets
                  key: oauth2_proxy_client_id
            - name: OAUTH2_PROXY_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  name: oauth2-proxy-secrets
                  key: oauth2_proxy_client_secret
            - name: OAUTH2_PROXY_COOKIE_SECRET
              valueFrom:
                secretKeyRef:
                  name: oauth2-proxy-secrets
                  key: oauth2_proxy_cookie_secret
          ports:
            - containerPort: 4180
              protocol: TCP
          resources:
            limits:
              cpu: 100m
              memory: 128Mi
            requests:
              cpu: 100m
              memory: 128Mi

Nous configurons le proxy pour utiliser le "provider" Azure (--provider=azure), les paramètres :

(--azure-tenant) L'id du tenant "en dur" (--azure-tenant=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx)
(--cookie-domain) Le domaine du cookie (doit correspondre à la racine de votre site)
(--email-domain) Pas de restriction sur le domaine de l'email
(--http-address) Adresse du oauth proxy
(--oidc-issuer-url) L'url fournisseur d'accès (Émetteur OpenID Connect) (Changez la valeur de ❗️TENANT-ID !)
(--whitelist-domain) Domaines autorisés pour la redirection après authentification. Préfixez le domaine avec un . ou un . pour autoriser les sous-domaines (par exemple, .caas.fr, .caas.fr)
(--skip-provider-button) Ignorera la page de connexion pour accéder directement à l'étape suivante : oauth/start
(--upstream=) Pas d'upstream pour pour les resources statiques (on aurait pu mettre )
(--session-cookie-minimal) Évite les erreurs notamment d'Azure concernant la taille des cookies.
❗️ Notez les références aux différentes entrées du secret oauth2-proxy-secrets
Le service associé

# oauth2-proxy-svc
---
apiVersion: v1
kind: Service
metadata:
  labels:
    application: oauth2-proxy
  name: oauth2-proxy-svc

spec:
  ports:
    - name: http
      port: 4180
      protocol: TCP
      targetPort: 4180
  selector:
    application: oauth2-proxy

Un ingress pour que l'application consomme l'url de l'oauth2-proxy

# oauth2-proxy-ing.yaml
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: letsencrypt
    nginx.ingress.kubernetes.io/proxy-buffer-size: "32k"
    nginx.ingress.kubernetes.io/proxy-buffers-number: "4"
  name: oauth2-proxy-ing

spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - auth.caas.fr
      secretName: auth.caas.fr-tls
  rules:
    - host: auth.caas.fr
      http:
        paths:
          - path: /oauth2
            pathType: Prefix
            backend:
              service:
                name: oauth2-proxy-svc
                port:
                  number: 4180

Un fichier de kustomization pour recenser les manifestes à déployer de base

# kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - oauth2-proxy-deploy.yaml
  - oauth2-proxy-ing.yaml
  - oauth2-proxy-svc.yaml

4.3 test de l'application oauth2-proxy

Lancer la commande suivante :

kubectl create namespace  oauth2-proxy
kubectl apply -k base/oauth2-proxy -n oauth2-proxy

4.4 Modification de l'ingress de notre application

Modifiez ou créez l'ingress pour l'application pour la protéger avec oauth2

# podinfo-ing-with-auth.yaml
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: podinfo-ing

  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
    nginx.ingress.kubernetes.io/proxy-buffer-size: "32k"
    nginx.ingress.kubernetes.io/proxy-buffers-number: "4"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

    # cache > noflood
    nginx.ingress.kubernetes.io/auth-cache-key: "$cookie__oauth2_proxy"
    nginx.ingress.kubernetes.io/auth-cache-duration: "200 202 10m"
    #

    # Ajoutez ca :) pour déléguer l'authentification et l'autorisation le reste reste identique
    nginx.ingress.kubernetes.io/auth-url: "https://auth.caas.fr/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://auth.caas.fr/oauth2/start?rd=https%3A%2F%2F$host$request_uri"
    nginx.ingress.kubernetes.io/auth-response-headers: "x-auth-request-user, x-auth-request-email, x-auth-request-access-token"
    #
  labels:
    app: demo-site
    app.kubernetes.io/name: demo-site
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - demo-site.caas.fr
      secretName: demo-site.caas.fr-tls
  rules:
    - host: demo-site.caas.fr
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: podinfo-svc
                port:
                  number: 9898

❗️N'oubliez pas de modifier le fichier kustomization.yaml du répertoire base/application si vous avez créé un nouveau fichier

Appliquez le changement : Maintenant l'accès à l'url est protégée par oauth2 - vous pouvez utiliser vos crédences Azure

5 : Bonus : Utiliser kustomize pour déployer le proxy et l'application en une line de commande

5.1 Pour l'application

Dans le répertoire demo/demo-site

un fichier kustomization.yaml

#kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - demo-site-ns.yaml
  - ../../base/application
namespace: demo-site

Une resource de type namespace

# demo-site-ns.yaml
---
apiVersion: v1
kind: Namespace
metadata:
  name: demo-site

5.2 Pour l'oauth2-proxy

Dans le répertoire demo/oauth2-proxy