Retour
Sécuriser un composant avec OAuth2 Proxy : Introduction et mise en place
KubernetesSécuritéDevOps

Sécuriser un composant avec OAuth2 Proxy : Introduction et mise en place

·7 min de lecture

Introduction

La sécurité des applications et des services web est un enjeu critique pour toute entreprise ou organisation. L'authentification est un des premiers leviers pour contrôler l'accès à vos composants sensibles. OAuth Proxy est un outil puissant qui permet d'ajouter une couche d'authentification basée sur le protocole OAuth 2.0, sans avoir à modifier le composant lui-même.

Dans cet article, on verra ce qu'est OAuth Proxy, ses cas d'utilisation, et comment l'implémenter pour protéger notre application, en utilisant un sidecar dans un pod.

Qu'est-ce qu'OAuth Proxy ?

OAuth Proxy, permet de se connecter avec un identity provider tels que Google, GitHub, Keycloak ou Azure AD, et agit comme un intermédiaire entre les utilisateurs et le composant à protéger. Il redirige les utilisateurs non authentifiés vers une page de connexion, vérifie leur identité via le fournisseur OAuth 2.0, puis leur permet d'accéder au service en cas de succès.

Oauth2 Flow

Avantages

  • Sécurité accrue : Protège les composants non sécurisés par une authentification robuste.
  • Simplicité : Pas besoin de modifier le code source du composant.
  • Compatibilité : Fonctionne avec la plupart des applications web et APIs.

Cas d'utilisation

  • Protéger une interface utilisateur ou un tableau de bord d'administration.
  • Restreindre l'accès à une API ou un service backend.
  • Ajouter l'authentification à une application interne sans fonctionnalité de sécurité native.

Prérequis

Avant de commencer, il nous faut :

  1. Un fournisseur OAuth 2.0 (par exemple, Keycloak, Google Cloud, GitHub, ou Azure AD).
  2. Un cluster Kubernetes pour déployer le service, le proxy et l'ingress.
  3. L'image OAuth Proxy : Disponible sur le repo quay quay.io/oauth2-proxy/oauth2-proxy

Mise en place d'OAuth Proxy dans Kubernetes

1. Architecture avec sidecar dans un pod

OAuth Proxy peut être déployé comme un conteneur "sidecar" dans le même pod que le service à protéger. ça garantit que toutes les requêtes passent par le proxy avant d'atteindre le service.

Exemple de définition de pod

Voici un exemple de définition YAML d'un pod avec OAuth Proxy en sidecar :

yaml
1apiVersion: v1
2kind: Pod
3metadata:
4  name: secured-service
5spec:
6  containers:
7  - name: app-container
8    image: my-secured-app:latest
9    ports:
10    - containerPort: 8080
11  - name: oauth-proxy
12    image: quay.io/oauth2-proxy/oauth2-proxy:v7.4.0
13    args:
14        - --upstream=http://127.0.0.1:8080
15        - --provider=keycloak-oidc
16        - --client-id=<keycloak-client-id>
17        - --client-secret=<keycloak-client-secret>
18        - --redirect-url=https://<votre-ingress>/oauth2/callback
19        - --oidc-issuer-url=https://<keycloak-endpoint>/realms/<realm>
20        - --code-challenge-method=S256
21        - --allowed-role=editor # permet de n'autoriser que si le role est présent dans le user Keycloak
22        - --allowed-group=admin # On peut en mettre plusieurs
23        - --email_domains = ["*.example.com"]
24    ports:
25    - containerPort: 4180
26

2. Configurer l'Ingress Controller

Pour que l'appel soit redirigé vers le proxy, on va rajouter des annotations dans la configuration. On utilise le module Auth de nginx dans notre cas.

Exemple de configuration d'Ingress

yaml
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: secured-service-ingress
5  annotations:
6    nginx.ingress.kubernetes.io/auth-url: "https://<votre-domaine>/oauth2/start"
7    nginx.ingress.kubernetes.io/auth-signin: "https://<votre-domaine>/oauth2/start?rd=$request_uri"
8spec:
9  rules:
10  - host: <votre-domaine>
11    http:
12      paths:
13      - path: /
14        pathType: Prefix
15        backend:
16          service:
17            name: secured-service
18            port:
19              number: 4180 # ici c'est le port du proxy
20

3. Intégration avec Keycloak

On doit configurer Keycloak afin de créer un nouveau client OpenID Connect pour l'application OAuth2 Proxy.
Ce prérequis est détaillé dans la documentation officielle de OAuth2 Proxy.

Création d'un client dans Keycloak

  1. Connectez-vous à l'interface Keycloak et sélectionnez votre Realm.

  2. Ajoutez un nouveau client :

    • Client ID : oauth-proxy
    • Access Type : "Confidential"
    • Redirect URI : https://<votre-domaine>/oauth2/callback

  3. Notez le Client Secret généré.

Configuration des scopes

Ajoutez les scopes requis, tels que openid, email, et profile, pour que les informations de l'utilisateur soient accessibles par OAuth Proxy.

Mise à jour d'OAuth Proxy

Dans le fichier YAML de votre pod, mettez à jour les variables du args ou même en variable d'environnement.

Encore plus

Là c'est la facilité, mais quand le nombre de services grossit, on devrait avoir autant de sidecar que de replicas, on peut donc sortir le proxy dans un deployment séparé.

Ce proxy gère également du multi-domaine. C'est pourquoi il est possible de configurer le proxy pour répondre sous plusieurs domaines. Il sera alors nécessaire de lui préciser la liste des domaines sur lesquels il doit poser les cookies.

En parlant de domaine, par défaut, le proxy dépose un cookie, qui peut être trop gros pour le navigateur, on peut configurer un backend Redis à la place et juste un hash côté navigateur en cookie.

Conclusion

On a intégré une solution élégante pour protéger vos services sans modifier leur code source et avec un minimum de maintenance côté opérationnel.

Notez que quand on met en place ce sytème, l'authentification est gardée tant que le cookie est présent, ça va de soit que l'on ne repasse pas par Keycloak à chaque requête. Par contre , on passera quand même par le proxy Oauth à chaque requête.

Commentaires