62 lines
2.7 KiB
Markdown
62 lines
2.7 KiB
Markdown
|
# 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.
|