# Intégration avec Kubernetes

Dans le cadre du déploiement de Bouncer dans un environnement Kubernetes, il est possible d'activer un mode d'intégration permettant à Bouncer d'exposer des jetons d'authentification directement sous forme de [`Secret`](https://kubernetes.io/fr/docs/concepts/configuration/secret/).

L'activation et configuration de l'intégration Kubernetes s'effectue dans le fichier de configuration du serveur d'administration via la section `integrations.kubernetes`:

```yaml
# Section de configuration des intégrations
# avec des produits externes
integrations:
  # Intégration avec Kubernetes
  kubernetes:
    # Activer/désactiver l'intégration Kubernetes
    enabled: true
    # Créer/mettre à jour un Secret automatiquement avec un jeton d'authentification
    # avec le rôle "writer".
    # Désactivé si l'attribut est vide ou absent.
    writerTokenSecret: my-bouncer-admin-writer-token
    # Namespace de destination du Secret pour le jeton d'authentification
    # avec le rôle "reader".
    # Utilise par défaut le namespace courant si absent ou vide.
    writerTokenSecretNamespace: "my-namespace"
    # Créer/mettre à jour un Secret automatiquement avec un jeton d'authentification
    # avec le rôle "reader".
    # Désactivé si l'attribut est vide ou absent.
    readerTokenSecret: my-bouncer-admin-reader-token
    # Namespace de destination du Secret pour le jeton d'authentification
    # avec le rôle "reader".
    # Utilise par défaut le namespace courant si absent ou vide.
    readerTokenSecretNamespace: "my-namespace"
    # Délai maximum alloué au verrou distribué pour la mise à jour
    # des secrets.
    lockTimeout: 30s
```

Vous devrez également définir un `ServiceAccount` pour votre `Pod` avec un `Role` équivalent au suivant (dans le cas nominal où le `Pod` créait les `Secrets` dans son même namespace):

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: bouncer-admin
rules:
  - apiGroups:
      - ""
      - v1
    resources:
      - secrets
    verbs:
      - create
      - get
      - update
```

> **Note**
>
> La génération des jetons d'authentification s'effectue à chaque démarrage du serveur d'administration. Un verrou partagé permet d'éviter que plusieurs instances fonctionnant en parallèle essayent de mettre à jour les ressources Kubernetes au même moment.
>
> De plus, les jetons seront laissés en l'état si la clé de génération n'a pas été modifiée pour éviter de changer les jetons à chaque redémarrage d'un `Pod` (voir l'annotation `bouncer.cadoles.com/public-key` sur les `Secrets` créés.).

Un exemple fonctionnel de déploiement Kubernetes est disponible dans le répertoire `misc/k8s` du projet.