</details>

### Configurazione del DB

Kviklet necessita di un proprio database postgres (o almeno di uno schema) per salvare i metadati relativi a query, connessioni, approvazioni, ecc.
Puoi trovare la loro immagine ufficiale qui: https://hub.docker.com/_/postgres, oppure utilizzare una versione ospitata nel cloud dal provider cloud di tua scelta.

All'avvio del container kviklet dovrai quindi impostare queste tre variabili d'ambiente di conseguenza:```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]

Pubblichiamo i nostri container su GitHub packages per ora, quindi con tutto questo configurato puoi eseguire `ghcr.io/kviklet/kviklet:main` non dimenticare di mappare la porta `8080` che è la porta predefinita su cui Kviklet si avvia.

Un esempio di docker run potrebbe essere questo:```
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

Il client id e il secret di Google puoi ottenerli facilmente seguendo le istruzioni di Google qui:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid

Per gli URI di reindirizzamento validi, dovresti configurare: https://[kviklet_host]/api/login/oauth2/code/google
Per le Origini consentite, semplicemente il tuo URL kviklet ospitato.

Dopo aver impostato queste variabili d'ambiente, tutti nella tua organizzazione potranno accedere con il pulsante sign in with google. Ma non avranno alcun permesso per impostazione predefinita, dovrai assegnare loro un ruolo dopo che hanno effettuato l'accesso una volta.

#### Keycloak

Se vuoi configurare l'SSO con Keycloak invece, devi impostare queste 4 variabili d'ambiente:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]

Crea una GitHub OAuth App su https://github.com/settings/developers e configura:

- Authorization callback URL: `https://[kviklet_host]/api/login/oauth2/code/github`
- Homepage URL: il tuo URL Kviklet ospitato

`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` è **obbligatorio** (Kviklet rifiuta di avviarsi senza di esso). Le GitHub OAuth App non possono limitare chi completa il flusso OAuth, quindi Kviklet chiama `/user/orgs` dopo l'autenticazione e rifiuta gli utenti che non sono membri di almeno una delle organizzazioni in allowlist (senza distinzione tra maiuscole e minuscole, vengono controllate le prime 100 organizzazioni).

Affinché il controllo dell'organizzazione possa vedere l'appartenenza di un utente, l'utente deve fare clic su **Grant** (o **Request**) accanto a ciascuna organizzazione in allowlist nella schermata di consenso OAuth. Se l'organizzazione ha abilitato "Restrict third-party OAuth applications", anche un proprietario dell'organizzazione deve approvare l'app OAuth una volta prima che l'appartenenza di qualsiasi membro diventi visibile.

Kviklet richiede gli scope `read:user`, `user:email` e `read:org`. Le email vengono sempre lette da `/user/emails` e viene accettata solo una voce `primary && verified`, quindi gli utenti con indirizzi email privati riescono comunque ad accedere.

#### Altri provider OIDC

Altri provider conformi a OIDC (GitLab, Auth0, Okta, ecc.) dovrebbero funzionare in modo simile a Keycloak. Tieni presente che il `redirect URI` cambierà a seconda del tipo scelto, quindi se scegli `gitlab` sarà `https://[kviklet_host]/api/login/oauth2/code/gitlab`.
Se riscontri problemi, sentiti libero di aprire una issue, non abbiamo ancora provato tutti i provider OIDC esistenti (per ora) e potrebbero esserci lievi differenze nell'implementazione che potrebbero richiedere aggiornamenti da parte di Kviklet.

### LDAP

Kviklet supporta l'autenticazione LDAP. Per abilitare e configurare LDAP, puoi sovrascrivere le seguenti variabili d'ambiente:```
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

Dettagli di configurazione:

- `SAML_ENABLED`: Impostare su `true` per abilitare l'autenticazione SAML
- `SAML_ENTITYID`: L'entity ID del tuo provider di identità SAML
- `SAML_SSOSERVICELOCATION`: L'URL del servizio SSO del tuo provider di identità
- `SAML_VERIFICATIONCERTIFICATE`: Il certificato X.509 utilizzato per verificare le risposte SAML (includere le righe BEGIN/END CERTIFICATE)

È possibile personalizzare opzionalmente le mappature degli attributi SAML:```
SAML_USERATTRIBUTES_EMAILATTRIBUTE=email
SAML_USERATTRIBUTES_NAMEATTRIBUTE=name
SAML_USERATTRIBUTES_IDATTRIBUTE=nameID

## Configurazione

### Connessioni

Dopo aver avviato Kviklet devi prima configurare una connessione al database. Vai su Impostazioni -> Database -> Aggiungi connessione.

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

Qui puoi configurare i requisiti di revisione e i limiti di esecuzione per ogni connessione. Vedi [Review Gates](#review-gates) per i dettagli.

#### AWS IAM AUTH

Kviklet supporta l'uso di IAM Auth per le connessioni ai database Postgres, MySQL e MariaDB; per farlo scegli IAM Auth quando crei una nuova connessione.

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

Questo rimuoverà l'opzione per impostare una password e userà invece le credenziali AWS per connettersi al database.

Kviklet usa il `DefaultCredentialsProvider` di AWS per trovare le credenziali e generare il token per la connessione. Questo significa che tutti i posti tipici dovrebbero funzionare (variabili d'ambiente o ruoli istanza associati); l'ordine esatto è documentato qui: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html

Inoltre, puoi fornire un ARN di un ruolo AWS che Kviklet assumerà, e usare quelle credenziali per creare il token temporaneo del DB. Questo è particolarmente utile per connettersi a database che non si trovano nello stesso account AWS di Kviklet. Per usare questa funzionalità, inserisci semplicemente l'ARN del ruolo nel campo designato quando crei o modifichi una connessione IAM Auth. Lasciare il campo vuoto userà il provider di credenziali predefinito (nessuna assunzione di ruolo).

La regione AWS da usare durante la generazione del token viene dedotta dall'URL della tua connessione, quindi non c'è un'opzione per impostarla.

Per imparare come configurare IAM Auth per il tuo database segui la documentazione ufficiale AWS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
I due punti principali sono:

- Crea un utente DB con l'opzione IAM auth e i permessi corretti
- Crea una policy IAM che consenta all'entità AWS di generare token per questo utente

### Review Gates

Per impostazione predefinita Kviklet consente una semplice configurazione del numero di revisioni. Puoi configurare quante approvazioni richiedono le richieste su una specifica connessione prima di poter essere eseguite.

Lo stato di approvazione di una richiesta viene calcolato in base all'ultima azione di ciascun revisore. Se un revisore approva e successivamente richiede modifiche, conta solo la richiesta di modifica — la sua approvazione precedente viene rimossa. Modificare una richiesta azzera sempre tutte le approvazioni precedenti, assicurando che nessuna modifica possa essere eseguita senza essere prima revisionata. Allo stesso modo, se un'esecuzione fallisce (ad es. a causa di un errore di sintassi SQL), le approvazioni vengono azzerate così la richiesta può essere corretta e ri-approvata senza doverne creare una nuova.

Puoi anche configurare un limite di **esecuzioni massime** per connessione per controllare quante volte una singola richiesta approvata può essere eseguita. Il valore predefinito è 1. Impostandolo a 0 si consentono esecuzioni illimitate. Le esecuzioni fallite non contano ai fini di questo limite.

#### Requisiti di revisione basati sui ruoli (Enterprise)

Con una licenza Kviklet Enterprise puoi configurare singole connessioni per richiedere approvazioni da utenti con ruoli specifici. Questo ti permette ad es. di richiedere l'approvazione del team che mantiene un dato database o di vincolare connessioni sensibili ad approvazioni DBA o manageriali.

**Come funziona:**

Ogni connessione ha un conteggio **totale revisioni richieste** (`numTotalRequired`) che funge da soglia minima — il numero minimo di approvazioni distinte necessarie indipendentemente dai ruoli. Oltre a questo puoi aggiungere **requisiti di ruolo** che specificano quante approvazioni devono provenire da utenti con un particolare ruolo (ad es. "1 da DBA, 1 da Security").

Una richiesta viene approvata solo quando **entrambe** le condizioni sono soddisfatte:

- Il numero totale di approvazioni distinte raggiunge `numTotalRequired`
- Ogni requisito di ruolo è individualmente soddisfatto

Se un utente appartiene a più ruoli, una singola approvazione da quell'utente conta per tutti i requisiti di ruolo corrispondenti. Tuttavia, conta comunque solo come una approvazione ai fini del conteggio totale.

**Esempio:** Una connessione richiede 3 approvazioni totali incluse 1 da un DBA e 1 da Security. Un utente che ha sia il ruolo DBA che Security approva — questo soddisfa entrambi i requisiti di ruolo ma conta solo come 1 delle 3 approvazioni totali necessarie. Sono ancora necessarie altre due approvazioni da qualsiasi utente.

Se la tua licenza enterprise scade, i requisiti di revisione basati sui ruoli esistenti rimangono applicati ma non possono più essere modificati. Puoi solo rimuoverli per tornare alla semplice configurazione del totale revisioni.

### Ruoli

Kviklet viene fornito con 3 ruoli: Default, Admins e Developers.

- Il ruolo predefinito fornisce accesso in lettura a tutte le connessioni e alle Richieste. Questo ruolo è assegnato a ogni utente e non può essere rimosso. Puoi comunque modificare i permessi di questo ruolo come preferisci.
- Gli Admins hanno il permesso di creare e modificare connessioni, oltre ad aggiungere nuovi Utenti e impostare i loro permessi.
- Gli Developers possono creare Richieste, approvarle e commentarle e naturalmente eseguire le istruzioni effettive.

Puoi personalizzare i Ruoli e ad es. dare a un ruolo accesso solo a una specifica connessione o a un gruppo di connessioni DB.
Questo è utile ad es. se hai team diversi con database diversi e vuoi controllare l'accesso a questi in modo più granulare.

#### Creare un nuovo Ruolo

Creare un nuovo ruolo funziona come segue. Vai su Impostazioni -> Ruoli -> Aggiungi Ruolo.

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

Le impostazioni predefinite non sono rilevanti per la maggior parte dei ruoli e puoi semplicemente dare all'utente accesso Read e RoleView e lasciare così.
Più interessante è l'aggiunta di permessi individuali per le Connessioni. Qui aggiungi prima un selettore per selezionare connessioni specifiche. Questo può essere un id specifico oppure puoi usare wildcard con `*` per corrispondere a più connessioni. Ad es. se vuoi avere un ruolo che ha accesso a tutti i database di sviluppo (nel caso in cui gestisci anche l'accesso a quelli con kviklet) useresti un selettore come `dev-*` e ti assicureresti che gli id delle connessioni siano impostati correttamente.

Puoi naturalmente anche inventare un sistema che usi per i tuoi diversi team all'interno della tua organizzazione.

### Sincronizzazione dei ruoli (Enterprise)

Sincronizza automaticamente i ruoli utente dai gruppi del tuo identity provider. Questa funzionalità richiede una licenza enterprise.

**La configurazione** si effettua in Impostazioni > Sincronizzazione Ruoli:

- **Abilita Sincronizzazione Ruoli**: Attiva/disattiva la sincronizzazione
- **Modalità di sincronizzazione**:
  - **Full Sync** - I ruoli utente corrispondono esattamente alle loro mappature dei gruppi IdP (più il ruolo predefinito)
  - **Additive** - I gruppi IdP aggiungono ruoli ma non rimuovono quelli esistenti
  - **First Login Only** - I ruoli si sincronizzano solo al primo login, le modifiche manuali vengono preservate in seguito
- **Attributo Gruppi**: L'attributo IdP contenente le appartenenze ai gruppi (predefinito: `groups`)
- **Mappature Ruoli**: Mappa i nomi dei gruppi IdP (ad es. `engineering`) ai ruoli Kviklet

#### Configurazione OIDC

Configura il tuo provider OIDC per includere un claim `groups` nell'ID token:

- **Keycloak**:

  Keycloak non include i gruppi nei token per impostazione predefinita, quindi dovrai aggiungere un mapper al client.
  1. Vai su **Clients** nel menu a sinistra
  2. Seleziona il tuo client Kviklet
  3. Vai alla scheda **Client scopes**
  4. Clicca sullo scope dedicato (ad es. `kviklet-dedicated`)
  5. Vai alla scheda **Mappers**
  6. Clicca **Add mapper** → **By configuration**
  7. Seleziona **Group Membership**
  8. Configura il mapper:

  | Impostazione        | Valore   |
  | ------------------- | -------- |
  | 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. Clicca **Save**

  > **Importante:** Il "Token Claim Name" deve corrispondere all'"Attributo Gruppi" configurato nelle impostazioni di Sincronizzazione Ruoli di Kviklet (predefinito: `groups`).

- **Altri provider OIDC**: Aggiungi un mapper/claim dei gruppi che includa le appartenenze ai gruppi dell'utente nell'ID token. Questo viene tipicamente fatto nell'interfaccia di amministrazione del provider.

  Se riscontri problemi sentiti libero di creare una issue, non abbiamo provato ogni singolo provider OIDC esistente (ancora) e potrebbero esserci lievi differenze nell'implementazione che potrebbero richiedere aggiornamenti da parte di Kviklet.

#### Configurazione LDAP

La sincronizzazione dei ruoli LDAP usa l'attributo `memberOf`:

1. Assicurati che il tuo server LDAP abbia l'overlay `memberOf` abilitato
2. Imposta **Attributo Gruppi** su `memberOf` in Kviklet
3. I nomi dei gruppi vengono quindi estratti dall'attributo `memberOf` negli attributi dell'utente.

#### Configurazione SAML

Configura il tuo IdP SAML per includere i gruppi nell'asserzione:

1. Aggiungi un attribute statement che mappa le appartenenze ai gruppi dell'utente
2. Imposta l'**Attributo Gruppi** in Kviklet per corrispondere al nome del tuo attributo SAML
3. I nomi dei gruppi vengono quindi estratti dall'attributo SAML negli attributi dell'utente.

### Notifiche

Puoi configurare Kviklet per inviare notifiche a un canale in Slack o Teams. Questo è utile per notificare al tuo team le nuove richieste che necessitano di revisione. Puoi configurarlo in Impostazioni -> Generali -> Impostazioni Notifiche.

#### Slack

Per configurare le notifiche Slack devi creare una Slack App e abilitare i webhook per essa. Puoi seguire le istruzioni qui: https://api.slack.com/messaging/webhooks

#### Teams

Le notifiche Teams usano un webhook **Workflow** di Power Automate. Kviklet invia una Adaptive Card, che il template del webhook pubblica nel tuo canale.

**Consigliato: usa il template del workflow**

1. In Teams, apri il canale in cui vuoi le notifiche, clicca sui **...** accanto al nome del canale e scegli **Workflows** (oppure aggiungi l'app **Workflows**).
2. Cerca e crea il template **"Send webhook alerts to a channel"**.
3. Accedi quando richiesto, poi seleziona il Team e il Canale di destinazione e crea il workflow.
4. Apri lo step del trigger e copia l'**HTTP POST URL** generato.
5. Incolla l'URL in Kviklet sotto Impostazioni -> Generali -> Impostazioni Notifiche e clicca salva.

**Alternativa: costruisci il workflow manualmente**

Se preferisci costruire il flow da solo (o il template non è disponibile):

1. Canale **...** -> **Workflows** -> crea un flow con il trigger **"When a Teams webhook request is received"**.
2. Aggiungi l'azione **Microsoft Teams -> "Post card in a chat or channel"**.
3. Imposta il campo **Adaptive Card** dell'azione all'espressione `string(triggerBody())` così pubblica la card che Kviklet invia.
4. Seleziona il Team e il Canale di destinazione, **Salva**, poi copia l'**HTTP POST URL** dallo step del trigger.

Attualmente ci sono notifiche per:

- Nuove Richieste, che necessitano di approvazioni
- Nuove approvazioni sulle richieste

#### Configurazione Base URL

Quando esegui Kviklet dietro un reverse proxy o un Kubernetes Ingress, i link delle notifiche potrebbero usare l'indirizzo IP interno invece del tuo dominio pubblico. Kviklet cerca di tracciare l'URL corretto osservando le richieste in arrivo ma alcuni reverse proxy non impostano correttamente gli header Forwarded. Per risolvere questo, imposta esplicitamente il base URL:```
KVIKLET_BASE_URL=https://kviklet.example.com

Kviklet registra una riga all'avvio che indica se la telemetria è attiva.

**Cosa viene inviato.** Ogni evento porta un id di istanza casuale (generato una volta e memorizzato nel
database di Kviklet), l'URL di base su cui Kviklet è raggiungibile (vedi sopra; spesso un hostname interno) e la versione
di Kviklet. Gli utenti sono identificati solo da un id opaco con ambito limitato all'istanza, così gli utenti unici possono essere
contati, ma nessun indirizzo email o nome viene mai inviato. Gli eventi esatti e le loro proprietà sono
definiti in `backend/src/main/kotlin/dev/kviklet/kviklet/telemetry/TelemetryEvent.kt`.

**Cosa non viene mai inviato.** Query, statement, risultati, output dei comandi, messaggi di errore, nomi delle
connessioni, hostname, credenziali, titoli o descrizioni delle richieste, commenti e nomi di utenti o ruoli.

### Logging

Per impostazione predefinita Kviklet scrive log leggibili dall'uomo (pretty) su stdout, il che è comodo
quando li si legge direttamente o tramite `docker logs`.

Se si inviano i log a un sistema centralizzato (Elasticsearch, Loki, Datadog, CloudWatch, …) è possibile
passare invece a **log JSON** strutturati, che sono più facili da indicizzare e interrogare. Impostare
il formato tramite una variabile d'ambiente:```
# One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs

Kviklet cifrerà tutte le credenziali esistenti all'avvio e utilizzerà il segreto per le connessioni future che crei.

### Rotazione della chiave

Se desideri ruotare la chiave, puoi semplicemente aggiungere un'altra variabile per la chiave precedente e modificare quella corrente:```
ENCRYPTION_KEY_PREVIOUS=some-secret
ENCRYPTION_KEY_CURRENT=another-secret

Le chiavi API ereditano i permessi dell'utente che le crea. Attualmente solo gli amministratori possono gestire le chiavi API e tutte le azioni eseguite con una chiave API sono attribuite all'utente che ha creato la chiave.

Una documentazione API rudimentale è disponibile all'indirizzo `[kviklet_host]/api/swagger-ui/index.html`. Tieni però presente che si tratta di un lavoro in corso e che l'API potrebbe cambiare nelle versioni future.

Alla fine la verità è nel codice, quindi puoi sempre consultare il controller per vedere come è definita l'API. Se hai domande, sentiti libero di aprire una issue.

## Funzionalità sperimentali

Attualmente ci sono due funzionalità sperimentali. Sono state sviluppate principalmente in base al feedback della community. Sentiti libero di provarle e di lasciare qualsiasi suggerimento tu abbia. Speriamo di svilupparle ulteriormente in futuro e di farle funzionare bene con il flusso di approvazione principale.

### Kubernetes Exec

Se vuoi utilizzare la funzionalità Kubernetes Exec devi creare una connessione Kubernetes separata. Kviklet utilizzerà l'utente del pod distribuito per eseguire il comando. Quindi assicurati che l'utente abbia i permessi necessari per eseguire comandi sui pod a cui vuoi accedere.

Kviklet utilizza anche /bin/sh per eseguire il comando, quindi dovrai assicurarti che i tuoi pod abbiano una shell o almeno un symlink in /bin/sh. Se questo ti crea problemi, sentiti libero di aprire una issue, potremmo potenzialmente rendere questo configurabile o trovare un'altra soluzione.

I comandi Kubernetes attendono l'output solo per 5 secondi; se il comando impiega più tempo, Kviklet attenderà fino a un'ora prima di andare in timeout. Questa è una soluzione provvisoria, stiamo valutando l'uso dei websocket per rendere il tutto più reattivo e potenzialmente abilitare sessioni terminale.

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

Se crei richieste per l'accesso temporaneo, puoi - invece di usare l'interfaccia web - eseguire le tue query attraverso un proxy gestito da kviklet e utilizzare il client DB che preferisci.
Il proxy è una funzionalità enterprise: richiede una licenza valida e un amministratore deve inoltre attivarlo in Impostazioni -> Generale -> Database Proxy.
Per questo il container ascolta su porte stabili (5432 e 3306 per impostazione predefinita, configurabili tramite `kviklet.proxy.postgres.port` e `kviklet.proxy.mysql.port`), quindi devi esporre quelle porte.
Gli utenti possono quindi creare una richiesta di accesso temporaneo e cliccare "Start Proxy" una volta che è stata approvata. Ogni richiesta ottiene un nome utente e una password temporanei; Kviklet instrada ogni connessione alla sua richiesta tramite il nome utente. Con questi possono connettersi al database. Kviklet convalida l'utente temporaneo e la password e inoltra tutte le richieste all'utente sottostante sul database. Qualsiasi istruzione eseguita viene registrata nel registro di audit come se fosse stata eseguita tramite l'interfaccia web.

Nota: il proxy attualmente non supporta il tracciamento dei risultati. Quindi le istruzioni eseguite vengono registrate ma non i risultati né se un'istruzione ha successo o fallisce.

![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 termina la connessione TLS verso il database. Ciò significa che per impostazione predefinita qualsiasi traffico da e verso il proxy stesso non è crittografato.  
Se vuoi che kviklet ricrittografi il traffico puoi fornire a Kviklet un certificato TLS e una chiave per il proxy impostando le seguenti variabili d'ambiente:```
PROXY_TLS_CERTIFICATE_SOURCE=env
PROXY_TLS_CERTIFICATE_CERT=your-certificate
PROXY_TLS_CERTIFICATE_KEY=your-key

In ogni caso, il certificato e la chiave devono essere memorizzati in [formato pem](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail).

## Domande? Contributi?

Se hai domande, vuoi fornire un feedback o hai bisogno di aiuto con la configurazione, unisciti alla nostra [community Discord](https://discord.gg/7SmPJfeP6e). Puoi anche creare una [issue su GitHub](https://github.com/kviklet/kviklet/issues) per segnalazioni di bug e richieste di funzionalità.

Se vuoi contribuire, sentiti libero di fare un fork e creare PR per piccole cose. Se pianifichi funzionalità più grandi, apprezzerei una discussione preliminare in una issue su GitHub o su Discord.

Puoi anche contattarmi all'indirizzo [email protected].