</details>

### Configuration de la base de données

Kviklet a besoin de sa propre base de données postgres (ou au moins d'un schéma) pour enregistrer les métadonnées relatives aux requêtes, connexions, approbations, etc.
Vous pouvez trouver leur image officielle ici : https://hub.docker.com/_/postgres, ou utiliser une version hébergée dans le cloud par le fournisseur de cloud de votre choix.

Lors du démarrage du conteneur kviklet, vous devrez alors définir ces trois variables d'environnement en conséquence :```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]

Nous publions nos conteneurs sur GitHub packages pour l'instant, donc avec tout ceci configuré, vous pouvez exécuter `ghcr.io/kviklet/kviklet:main`, n'oubliez pas de mapper le port `8080` qui est le port par défaut sur lequel Kviklet démarre.

Un exemple de docker run pourrait ressembler à ceci :```
docker run \
-e SPRING_DATASOURCE_PASSWORD=postgres \
-e SPRING_DATASOURCE_USERNAME=postgres \
-e SPRING_DATASOURCE_URL=jdbc:postgresql://localhost:5432/Kviklet \
-e [email protected] \
-e INITIAL_USER_PASSWORD=someverysecurepassword \
--network host \
ghcr.io/kviklet/kviklet:main

The google client id and secret you can easily get by following google instructions here:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid

For valid redirect URIs, you should configure: https://[kviklet_host]/api/login/oauth2/code/google
For Allowed Origins, simply your hosted kviklet url.

After setting those environment variables everyone in your organization can login with the sign in with google button. But they wont have any permissions by default, you will have to assign them a role after they log in once.

#### Keycloak

If you want to setup SSO with Keycloak instead you need to set these 4 environment variables:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]

Créez une GitHub OAuth App sur https://github.com/settings/developers et configurez :

- Authorization callback URL : `https://[kviklet_host]/api/login/oauth2/code/github`
- Homepage URL : l'URL de votre instance Kviklet hébergée

`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` est **obligatoire** (Kviklet refuse de démarrer sans). Les GitHub OAuth Apps ne peuvent pas restreindre qui termine le flux OAuth, donc Kviklet appelle `/user/orgs` après l'authentification et rejette les utilisateurs qui ne sont pas membres d'au moins une organisation autorisée (insensible à la casse, les 100 premières organisations sont vérifiées).

Pour que la vérification d'organisation puisse voir l'appartenance d'un utilisateur, celui-ci doit cliquer sur **Grant** (ou **Request**) à côté de chaque organisation autorisée sur l'écran de consentement OAuth. Si l'organisation a activé « Restrict third-party OAuth applications », un propriétaire de l'organisation doit également approuver l'application OAuth une fois avant que l'appartenance d'un membre ne devienne visible.

Kviklet demande les scopes `read:user`, `user:email` et `read:org`. Les e-mails sont toujours lus depuis `/user/emails` et seule une entrée `primary && verified` est acceptée, donc les utilisateurs avec des adresses e-mail privées peuvent quand même se connecter avec succès.

#### Autres fournisseurs OIDC

Les autres fournisseurs compatibles OIDC (GitLab, Auth0, Okta, etc.) devraient fonctionner de manière similaire à Keycloak. Notez que l'`redirect URI` changera selon le type que vous choisissez, donc si vous choisissez `gitlab` ce sera `https://[kviklet_host]/api/login/oauth2/code/gitlab`.
Si vous rencontrez des problèmes, n'hésitez pas à créer une issue, nous n'avons pas essayé tous les fournisseurs OIDC existants (pas encore) et il pourrait y avoir de légères différences dans l'implémentation qui pourraient nécessiter des mises à jour du côté de Kviklet.

### LDAP

Kviklet prend en charge l'authentification LDAP. Pour activer et configurer LDAP, vous pouvez surcharger les variables d'environnement suivantes :```
LDAP_ENABLED=true
LDAP_URL=ldap://your-ldap-server:389
LDAP_BASE=dc=your,dc=domain,dc=com
LDAP_PRINCIPAL=cn=admin,dc=your,dc=domain,dc=com
LDAP_PASSWORD=your-admin-password
LDAP_UNIQUE_IDENTIFIER_ATTRIBUTE=uid
LDAP_EMAIL_ATTRIBUTE=mail
LDAP_FULL_NAME_ATTRIBUTE=cn
LDAP_USER_OU=people
LDAP_SEARCH_BASE=ou=people

Détails de configuration :

- `SAML_ENABLED` : Défini sur `true` pour activer l'authentification SAML
- `SAML_ENTITYID` : L'ID d'entité de votre fournisseur d'identité SAML
- `SAML_SSOSERVICELOCATION` : L'URL du service SSO de votre fournisseur d'identité
- `SAML_VERIFICATIONCERTIFICATE` : Le certificat X.509 utilisé pour vérifier les réponses SAML (incluez les lignes BEGIN/END CERTIFICATE)

Vous pouvez éventuellement personnaliser les mappages d'attributs SAML :```
SAML_USERATTRIBUTES_EMAILATTRIBUTE=email
SAML_USERATTRIBUTES_NAMEATTRIBUTE=name
SAML_USERATTRIBUTES_IDATTRIBUTE=nameID

## Configuration

### Connexions

Après avoir démarré Kviklet, vous devez d'abord configurer une connexion à une base de données. Allez dans Settings -> Databases -> Add Connection.

![Add Connection](https://assets.kitploit.com/production/public/readmes/7140/3ded2a0b23e5d2f02feb21a854263c91dedea25a789fb75ab8342384c4e39b52.png)
![Add Connection](https://assets.kitploit.com/production/public/readmes/7140/585238c9eddad8ed4e2440096ce0616445a6696e1042f58676a1d0b038edde7f.png)

Ici, vous pouvez configurer les exigences de révision et les limites d'exécution pour chaque connexion. Voir [Review Gates](#review-gates) pour plus de détails.

#### AWS IAM AUTH

Kviklet prend en charge l'utilisation d'IAM Auth pour les connexions aux bases de données Postgres, MySQL et MariaDB ; pour cela, choisissez IAM Auth lors de la création d'une nouvelle connexion.

![IAM Auth](https://assets.kitploit.com/production/public/readmes/7140/14ed42bd639eb9b0ba81b22850e277703f2da9495dd101f68066f95fc51f291c.png)
![IAM Auth](https://assets.kitploit.com/production/public/readmes/7140/5a60a3a9ae527e11679f3c33c787caba4c80b379ddc463db1f871288408517e1.png)

Cela supprimera l'option de définir un mot de passe et utilisera à la place les identifiants AWS pour se connecter à la base de données.

Kviklet utilise le `DefaultCredentialsProvider` d'AWS pour trouver les identifiants et générer le token pour la connexion. Cela signifie que tous les emplacements typiques devraient fonctionner (variables d'environnement ou rôles d'instance associés) ; l'ordre exact est documenté ici : https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html

De plus, vous pouvez fournir un ARN de rôle AWS que Kviklet assumera, et utiliser ces identifiants pour créer le token temporaire de la base de données. Cela est particulièrement utile pour se connecter à des bases de données qui ne se trouvent pas dans le même compte AWS que Kviklet. Pour utiliser cette fonctionnalité, saisissez simplement l'ARN du rôle dans le champ prévu lors de la création ou de la modification d'une connexion IAM Auth. Laisser le champ vide utilisera le fournisseur d'identifiants par défaut (aucune assumption de rôle).

La région AWS à utiliser lors de la génération du token est déduite de votre URL de connexion, il n'y a donc pas d'option pour la définir.

Pour apprendre à configurer IAM Auth pour votre base de données, suivez la documentation officielle AWS : https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
Les deux points principaux sont :

- Créer un utilisateur de base de données avec l'option IAM auth et les permissions correctes
- Créer une politique IAM qui permet à l'entité AWS de générer des tokens pour cet utilisateur

### Review Gates

Par défaut, Kviklet permet une configuration simple du nombre de révisions. Vous pouvez configurer combien d'approbations les demandes sur une connexion spécifique nécessitent avant de pouvoir être exécutées.

Le statut d'approbation d'une demande est calculé en fonction de la dernière action de chaque réviseur. Si un réviseur approuve puis demande ensuite des modifications, seule la demande de modification compte — son approbation antérieure est supprimée. La modification d'une demande réinitialise toujours toutes les approbations précédentes, garantissant qu'aucune modification ne peut être exécutée sans avoir été révisée au préalable. De même, si une exécution échoue (par exemple en raison d'une erreur de syntaxe SQL), les approbations sont réinitialisées afin que la demande puisse être corrigée et approuvée à nouveau sans avoir à en créer une nouvelle.

Vous pouvez également configurer une limite de **max executions** par connexion pour contrôler la fréquence à laquelle une demande approuvée peut être exécutée. La valeur par défaut est 1. La définir à 0 permet des exécutions illimitées. Les exécutions échouées ne comptent pas dans cette limite.

#### Exigences de révision basées sur les rôles (Enterprise)

Avec une licence Kviklet Enterprise, vous pouvez configurer des connexions individuelles pour exiger des approbations d'utilisateurs ayant des rôles spécifiques. Cela vous permet, par exemple, d'exiger l'approbation de l'équipe qui maintient une base de données donnée ou de conditionner les connexions sensibles à des approbations DBA ou de la direction.

**Comment cela fonctionne :**

Chaque connexion a un nombre **total de révisions requises** (`numTotalRequired`) qui agit comme un plancher — le nombre minimum d'approbations distinctes nécessaires, indépendamment des rôles. En plus de cela, vous pouvez ajouter des **exigences de rôle** qui spécifient combien d'approbations doivent provenir d'utilisateurs ayant un rôle particulier (par exemple, « 1 de DBA, 1 de Security »).

Une demande n'est approuvée que lorsque **les deux** conditions sont remplies :

- Le nombre total d'approbations distinctes atteint `numTotalRequired`
- Chaque exigence de rôle est individuellement satisfaite

Si un utilisateur appartient à plusieurs rôles, une seule approbation de cet utilisateur compte pour toutes les exigences de rôle correspondantes. Cependant, elle ne compte toujours que comme une seule approbation dans le total.

**Exemple :** Une connexion nécessite 3 approbations au total, dont 1 d'un DBA et 1 de Security. Un utilisateur qui possède à la fois le rôle DBA et le rôle Security approuve — cela satisfait les deux exigences de rôle mais ne compte que comme 1 des 3 approbations totales nécessaires. Deux approbations supplémentaires de n'importe quels utilisateurs sont encore requises.

Si votre licence enterprise expire, les exigences de révision basées sur les rôles existantes restent appliquées mais ne peuvent plus être modifiées. Vous pouvez uniquement les supprimer pour revenir à la configuration simple du nombre total de révisions.

### Rôles

Kviklet est livré avec 3 rôles : Default, Admins et Developers.

- Le rôle default fournit un accès en lecture à toutes les connexions et aux Requests. Ce rôle est attribué à chaque utilisateur et ne peut pas être supprimé. Vous pouvez toutefois modifier les permissions de ce rôle comme vous le souhaitez.
- Les Admins ont la permission de créer et modifier des connexions, ainsi que d'ajouter de nouveaux utilisateurs et de définir leurs permissions.
- Les Developers peuvent créer des Requests ainsi que les approuver et les commenter, et bien sûr exécuter les instructions réelles.

Vous pouvez personnaliser les rôles et, par exemple, donner à un rôle uniquement l'accès à une connexion spécifique ou à un groupe de connexions de bases de données.
Cela est utile, par exemple, si vous avez différentes équipes avec différentes bases de données et souhaitez contrôler l'accès à celles-ci de manière plus granulaire.

#### Création d'un nouveau rôle

La création d'un nouveau rôle fonctionne comme suit. Allez dans Settings -> Roles -> Add Role.

![Add Role](https://assets.kitploit.com/production/public/readmes/7140/a91b79287c0b3130b83bdde1c059f49b89c5d43a1c0deae33b211ea427956f8e.png)
![Add Role](https://assets.kitploit.com/production/public/readmes/7140/c535ac152759bb21bea04a0968ce43fa7bf946c7699feca23c71f9eaba41ceaf.png)

Les paramètres par défaut ne sont pas très pertinents pour la plupart des rôles et vous pouvez simplement donner l'accès User Read et RoleView et en rester là.
Plus intéressant est l'ajout de permissions individuelles pour les connexions. Ici, vous ajoutez d'abord un sélecteur pour sélectionner des connexions spécifiques. Cela peut être soit un id spécifique, soit vous utilisez des wildcards avec `*` pour correspondre à plusieurs connexions. Par exemple, si vous voulez avoir un rôle qui a accès à toutes les bases de données de dev (au cas où vous géreriez aussi l'accès à celles-ci avec kviklet), vous utiliseriez un sélecteur comme `dev-*` et vous vous assureriez que les ids des connexions sont correctement définis.

Vous pouvez bien sûr aussi concevoir un système que vous utilisez pour vos différentes équipes au sein de votre organisation.

### Role Sync (Enterprise)

Synchronisez automatiquement les rôles des utilisateurs à partir des groupes de votre fournisseur d'identité. Cette fonctionnalité nécessite une licence enterprise.

**La configuration** se fait dans Settings > Role Sync :

- **Enable Role Sync** : Activer/désactiver la synchronisation
- **Sync Mode** :
  - **Full Sync** - Les rôles des utilisateurs correspondent exactement à leurs mappages de groupes IdP (plus le rôle par défaut)
  - **Additive** - Les groupes IdP ajoutent des rôles mais ne suppriment pas ceux existants
  - **First Login Only** - Les rôles sont synchronisés uniquement lors de la première connexion, les modifications manuelles sont préservées par la suite
- **Groups Attribute** : L'attribut IdP contenant les appartenances aux groupes (par défaut : `groups`)
- **Role Mappings** : Mapper les noms de groupes IdP (par exemple, `engineering`) aux rôles Kviklet

#### Configuration OIDC

Configurez votre fournisseur OIDC pour inclure une claim `groups` dans le token d'ID :

- **Keycloak** :

  Keycloak n'inclut pas les groupes dans les tokens par défaut, vous devrez donc ajouter un mapper au client.
  1. Naviguez vers **Clients** dans le menu de gauche
  2. Sélectionnez votre client Kviklet
  3. Allez dans l'onglet **Client scopes**
  4. Cliquez sur le scope dédié (par exemple, `kviklet-dedicated`)
  5. Allez dans l'onglet **Mappers**
  6. Cliquez sur **Add mapper** → **By configuration**
  7. Sélectionnez **Group Membership**
  8. Configurez le mapper :

  | Setting             | Value    |
  | ------------------- | -------- |
  | Name                | `groups` |
  | Token Claim Name    | `groups` |
  | Full group path     | **OFF**  |
  | Add to ID token     | **ON**   |
  | Add to access token | **ON**   |
  | Add to userinfo     | **ON**   |
  9. Cliquez sur **Save**

  > **Important :** Le « Token Claim Name » doit correspondre au « Groups Attribute » configuré dans les paramètres Role Sync de Kviklet (par défaut : `groups`).

- **Autres fournisseurs OIDC** : Ajoutez un mapper/claim de groupes qui inclut les appartenances aux groupes de l'utilisateur dans le token d'ID. Cela se fait généralement dans l'interface d'administration du fournisseur.

  Si vous rencontrez des problèmes, n'hésitez pas à créer une issue ; nous n'avons pas encore essayé tous les fournisseurs OIDC existants (pas encore) et il pourrait y avoir de légères différences dans l'implémentation qui pourraient nécessiter des mises à jour du côté de Kviklet.

#### Configuration LDAP

La synchronisation des rôles LDAP utilise l'attribut `memberOf` :

1. Assurez-vous que votre serveur LDAP a l'overlay `memberOf` activé
2. Définissez **Groups Attribute** sur `memberOf` dans Kviklet
3. Les noms de groupes sont ensuite extraits de l'attribut `memberOf` dans les attributs des utilisateurs.

#### Configuration SAML

Configurez votre IdP SAML pour inclure les groupes dans l'assertion :

1. Ajoutez une déclaration d'attribut qui mappe les appartenances aux groupes des utilisateurs
2. Définissez le **Groups Attribute** dans Kviklet pour correspondre au nom de votre attribut SAML
3. Les noms de groupes sont ensuite extraits de l'attribut SAML dans les attributs des utilisateurs.

### Notifications

Vous pouvez configurer Kviklet pour envoyer des notifications vers un canal dans Slack ou Teams. Cela est utile pour informer votre équipe des nouvelles demandes qui doivent être révisées. Vous pouvez configurer cela dans Settings -> General -> Notification Settings.

#### Slack

Pour configurer les notifications Slack, vous devez créer une Slack App et activer les webhooks pour celle-ci. Vous pouvez suivre les instructions ici : https://api.slack.com/messaging/webhooks

#### Teams

Les notifications Teams utilisent un webhook **Workflow** Power Automate. Kviklet envoie une Adaptive Card, que le modèle de webhook publie dans votre canal.

**Recommandé : utiliser le modèle de workflow**

1. Dans Teams, ouvrez le canal dans lequel vous souhaitez recevoir les notifications, cliquez sur **...** à côté du nom du canal et choisissez **Workflows** (ou ajoutez l'application **Workflows**).
2. Recherchez et créez le modèle **« Send webhook alerts to a channel »**.
3. Connectez-vous lorsque cela vous est demandé, puis sélectionnez l'équipe et le canal cibles et créez le workflow.
4. Ouvrez l'étape de déclenchement et copiez l'**HTTP POST URL** générée.
5. Collez l'URL dans Kviklet sous Settings -> General -> Notification Settings et cliquez sur save.

**Alternative : construire le workflow manuellement**

Si vous préférez construire le flux vous-même (ou si le modèle n'est pas disponible) :

1. Canal **...** -> **Workflows** -> créez un flux avec le déclencheur **« When a Teams webhook request is received »**.
2. Ajoutez l'action **Microsoft Teams -> « Post card in a chat or channel »**.
3. Définissez le champ **Adaptive Card** de l'action sur l'expression `string(triggerBody())` afin qu'elle publie la carte envoyée par Kviklet.
4. Sélectionnez l'équipe et le canal cibles, **Save**, puis copiez l'**HTTP POST URL** depuis l'étape de déclenchement.

Actuellement, il existe des notifications pour :

- Les nouvelles Requests, qui nécessitent des approbations
- Les nouvelles approbations sur les demandes

#### Configuration de l'URL de base

Lorsque Kviklet est exécuté derrière un reverse proxy ou un Ingress Kubernetes, les liens de notification peuvent utiliser l'adresse IP interne au lieu de votre domaine public. Kviklet essaie de suivre l'URL correcte en examinant les requêtes entrantes, mais certains reverse proxies ne définissent pas correctement les en-têtes Forwarded. Pour corriger cela, définissez explicitement l'URL de base :```
KVIKLET_BASE_URL=https://kviklet.example.com

Kviklet journalise une ligne au démarrage indiquant si la télémétrie est activée.

**Ce qui est envoyé.** Chaque événement porte un identifiant d'instance aléatoire (généré une fois et stocké dans la
base de données de Kviklet), l'URL de base à laquelle Kviklet est accessible (voir ci-dessus ; souvent un nom d'hôte interne), et la version de Kviklet. Les utilisateurs sont identifiés uniquement par un identifiant opaque limité à l'instance, ce qui permet de compter les utilisateurs uniques, mais aucune adresse e-mail ni aucun nom n'est jamais envoyé. Les événements exacts et leurs propriétés sont définis dans `backend/src/main/kotlin/dev/kviklet/kviklet/telemetry/TelemetryEvent.kt`.

**Ce qui n'est jamais envoyé.** Requêtes, instructions, résultats, sortie de commande, messages d'erreur, noms de connexion, noms d'hôte, identifiants, titres ou descriptions de requêtes, commentaires, et noms d'utilisateurs ou de rôles.

### Journalisation

Par défaut, Kviklet écrit des journaux lisibles par l'humain (pretty) sur stdout, ce qui est pratique
lorsqu'on les lit directement ou via `docker logs`.

Si vous exportez les journaux vers un système centralisé (Elasticsearch, Loki, Datadog, CloudWatch, …), vous
pouvez passer à des **journaux JSON** structurés, plus faciles à indexer et à interroger. Définissez
le format via une variable d'environnement :```
# One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs

Kviklet chiffrera toutes vos informations d'identification existantes au démarrage, et utilisera le secret pour les futures connexions que vous créez.

### Rotation de clé

Si vous souhaitez faire tourner la clé, vous pouvez simplement ajouter une autre variable pour la clé précédente et modifier la clé actuelle :```
ENCRYPTION_KEY_PREVIOUS=some-secret
ENCRYPTION_KEY_CURRENT=another-secret

Les clés API héritent des permissions de l'utilisateur qui les crée. Actuellement, seuls les administrateurs peuvent gérer les clés API et toutes les actions effectuées avec une clé API sont attribuées à l'utilisateur qui a créé la clé.

Une documentation API rudimentaire est disponible à l'adresse `[kviklet_host]/api/swagger-ui/index.html`. Mais gardez à l'esprit qu'il s'agit d'un travail en cours et que l'API pourrait changer dans les versions futures.

Au final, la vérité se trouve dans le code, vous pouvez donc toujours consulter le contrôleur pour voir comment l'API est définie. Si vous avez des questions, n'hésitez pas à ouvrir une issue.

## Fonctionnalités expérimentales

Il existe actuellement deux fonctionnalités expérimentales. Elles ont été développées principalement à partir des retours de la communauté. N'hésitez pas à les essayer et à nous faire part de vos commentaires. Nous espérons les développer davantage à l'avenir et les faire fonctionner correctement avec le flux d'approbation principal.

### Kubernetes Exec

Si vous souhaitez utiliser la fonctionnalité Kubernetes Exec, vous devez créer une connexion Kubernetes distincte. Kviklet utilisera l'utilisateur du pod déployé pour exécuter la commande. Assurez-vous donc que cet utilisateur dispose des permissions nécessaires pour exécuter des commandes sur les pods auxquels vous souhaitez accéder.

Kviklet utilise également /bin/sh pour exécuter la commande, vous devrez donc vous assurer que vos pods disposent d'un shell ou au moins d'un lien symbolique dans /bin/sh. Si cela vous pose problème, n'hésitez pas à ouvrir une issue, nous pourrons potentiellement rendre cela configurable ou trouver une autre solution.

Les commandes Kubernetes n'attendent que 5 secondes pour la sortie ; si la commande prend plus de temps, Kviklet attendra jusqu'à une heure avant d'expirer la commande. Il s'agit d'une solution provisoire, nous étudions les websockets pour rendre cela plus réactif et potentiellement permettre des sessions terminal.

### Proxy - Postgres, MariaDB, MySQL (Enterprise)

Si vous créez des demandes d'accès temporaire, vous pouvez - au lieu d'utiliser l'interface web - exécuter vos requêtes via un proxy géré par kviklet et utiliser le client de base de données de votre choix.
Le proxy est une fonctionnalité enterprise : il nécessite une licence valide, et un administrateur doit en plus l'activer dans Settings -> General -> Database Proxy.
Pour cela, le conteneur écoute sur des ports stables (5432 et 3306 par défaut, configurables via `kviklet.proxy.postgres.port` et `kviklet.proxy.mysql.port`), vous devez donc exposer ces ports.
Les utilisateurs peuvent ensuite créer une demande d'accès temporaire et cliquer sur « Start Proxy » une fois celle-ci approuvée. Chaque demande obtient un nom d'utilisateur et un mot de passe temporaires ; Kviklet route chaque connexion vers sa demande en fonction du nom d'utilisateur. Avec ceux-ci, ils peuvent se connecter à la base de données. Kviklet valide l'utilisateur temporaire et le mot de passe et proxyfie toutes les requêtes vers l'utilisateur sous-jacent sur la base de données. Toutes les instructions exécutées sont enregistrées dans le journal d'audit comme si elles avaient été exécutées via l'interface web.

Remarque : le proxy ne prend actuellement pas en charge le suivi des résultats. Ainsi, les instructions exécutées sont enregistrées mais pas les résultats ni si une instruction réussit ou échoue.

![Postgres Proxy](https://assets.kitploit.com/production/public/readmes/7140/153b5b3e85c492079f01f1ffda490a53df2be01cfd808553abc511eb90fc1731.png)
![Postgres Proxy](https://assets.kitploit.com/production/public/readmes/7140/2c886b3cb184b13bbee9120ca5f1cdd9f45dd7743c5cf7a01fe8d5f7474d507a.png)

#### Proxy - TLS

Kviklet termine la connexion TLS vers la base de données. Cela signifie que par défaut, tout trafic depuis et vers le proxy lui-même n'est pas chiffré.  
Si vous souhaitez que kviklet rechiffre le trafic, vous pouvez fournir à Kviklet un certificat TLS et une clé pour le proxy en définissant les variables d'environnement suivantes :```
PROXY_TLS_CERTIFICATE_SOURCE=env
PROXY_TLS_CERTIFICATE_CERT=your-certificate
PROXY_TLS_CERTIFICATE_KEY=your-key

Dans les deux cas, le certificat et la clé doivent être stockés au [format pem](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail).

## Questions ? Contributions ?

Si vous avez des questions, souhaitez donner votre avis ou avez besoin d'aide pour la configuration, rejoignez notre [communauté Discord](https://discord.gg/7SmPJfeP6e). Vous pouvez également créer une [issue GitHub](https://github.com/kviklet/kviklet/issues) pour signaler des bugs et demander des fonctionnalités.

Si vous souhaitez contribuer, n'hésitez pas à forker et à créer des PR pour de petites choses. Si vous prévoyez des fonctionnalités plus importantes, j'apprécierais une discussion en amont dans une issue GitHub ou sur Discord.

Vous pouvez également me contacter à [email protected].