</details>

### DB-Einrichtung

Kviklet benötigt eine eigene Postgres-Datenbank (oder zumindest ein Schema), um Metadaten über Abfragen, Verbindungen, Genehmigungen usw. zu speichern.
Das offizielle Image finden Sie hier: https://hub.docker.com/_/postgres, oder verwenden Sie eine cloud-gehostete Version Ihres bevorzugten Cloud-Anbieters.

Beim Starten des Kviklet-Containers müssen Sie dann diese drei Umgebungsvariablen entsprechend setzen:```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]

Wir veröffentlichen unsere Container vorerst auf GitHub Packages. Mit all dem eingerichtet kannst du `ghcr.io/kviklet/kviklet:main` ausführen. Vergiss nicht, Port `8080` zuzuordnen, welcher der Standardport ist, auf dem Kviklet startet.

Ein Beispiel für einen Docker-Run könnte so aussehen:```
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

Die Google-Client-ID und das Secret erhältst du ganz einfach, indem du die Google-Anweisungen hier befolgst:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid

Für gültige Redirect-URIs solltest du konfigurieren: https://[kviklet_host]/api/login/oauth2/code/google
Für Allowed Origins einfach deine gehostete Kviklet-URL.

Nachdem du diese Umgebungsvariablen gesetzt hast, kann sich jeder in deiner Organisation mit dem „Sign in with Google“-Button anmelden. Standardmäßig haben sie jedoch keine Berechtigungen; du musst ihnen eine Rolle zuweisen, nachdem sie sich einmal angemeldet haben.

#### Keycloak

Wenn du stattdessen SSO mit Keycloak einrichten möchtest, musst du diese 4 Umgebungsvariablen setzen:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]

Erstelle eine GitHub OAuth App unter https://github.com/settings/developers und konfiguriere:

- Authorization callback URL: `https://[kviklet_host]/api/login/oauth2/code/github`
- Homepage URL: deine gehostete Kviklet-URL

`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` ist **erforderlich** (Kviklet verweigert den Start ohne diese Variable). GitHub OAuth Apps können nicht einschränken, wer den OAuth-Flow abschließt, daher ruft Kviklet nach der Authentifizierung `/user/orgs` auf und lehnt Benutzer ab, die nicht Mitglied mindestens einer allowlisteten Organisation sind (Groß-/Kleinschreibung wird nicht unterschieden, die ersten 100 Organisationen werden geprüft).

Damit die Organisationsprüfung die Mitgliedschaft eines Benutzers sehen kann, muss der Benutzer auf dem OAuth-Zustimmungsbildschirm neben jeder allowlisteten Organisation auf **Grant** (oder **Request**) klicken. Wenn für die Organisation "Restrict third-party OAuth applications" aktiviert ist, muss ein Organisationsbesitzer die OAuth-App außerdem einmal genehmigen, bevor die Mitgliedschaft eines Mitglieds sichtbar wird.

Kviklet fordert die Scopes `read:user`, `user:email` und `read:org` an. E-Mail-Adressen werden immer aus `/user/emails` gelesen und nur ein `primary && verified`-Eintrag wird akzeptiert, sodass Benutzer mit privaten E-Mail-Adressen sich trotzdem erfolgreich anmelden können.

#### Andere OIDC-Anbieter

Andere OIDC-konforme Anbieter (GitLab, Auth0, Okta usw.) sollten ähnlich wie Keycloak funktionieren. Beachte, dass sich die `redirect URI` je nach gewähltem Typ ändert. Wenn du also `gitlab` wählst, lautet sie `https://[kviklet_host]/api/login/oauth2/code/gitlab`.
Wenn du auf Probleme stößt, kannst du gerne ein Issue erstellen. Wir haben noch nicht jeden einzelnen OIDC-Anbieter ausprobiert (noch nicht) und es könnte geringfügige Unterschiede in der Implementierung geben, die Anpassungen auf Kviklets Seite erfordern könnten.

### LDAP

Kviklet unterstützt LDAP-Authentifizierung. Um LDAP zu aktivieren und zu konfigurieren, kannst du die folgenden Umgebungsvariablen überschreiben:```
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

Konfigurationsdetails:

- `SAML_ENABLED`: Auf `true` setzen, um die SAML-Authentifizierung zu aktivieren
- `SAML_ENTITYID`: Die Entity-ID Ihres SAML-Identity-Providers
- `SAML_SSOSERVICELOCATION`: Die SSO-Service-URL Ihres Identity-Providers
- `SAML_VERIFICATIONCERTIFICATE`: Das X.509-Zertifikat, das zur Überprüfung von SAML-Antworten verwendet wird (einschließlich der BEGIN/END CERTIFICATE-Zeilen)

Optional können Sie die SAML-Attributzuordnungen anpassen:```
SAML_USERATTRIBUTES_EMAILATTRIBUTE=email
SAML_USERATTRIBUTES_NAMEATTRIBUTE=name
SAML_USERATTRIBUTES_IDATTRIBUTE=nameID

## Konfiguration

### Verbindungen

Nach dem Start von Kviklet müssen Sie zunächst eine Datenbankverbindung konfigurieren. Gehen Sie zu Einstellungen -> Datenbanken -> Verbindung hinzufügen.

![Verbindung hinzufügen](https://assets.kitploit.com/production/public/readmes/7140/3ded2a0b23e5d2f02feb21a854263c91dedea25a789fb75ab8342384c4e39b52.png)
![Verbindung hinzufügen](https://assets.kitploit.com/production/public/readmes/7140/585238c9eddad8ed4e2440096ce0616445a6696e1042f58676a1d0b038edde7f.png)

Hier können Sie Überprüfungsanforderungen und Ausführungslimits für jede Verbindung konfigurieren. Siehe [Review Gates](#review-gates) für Details.

#### AWS IAM AUTH

Kviklet unterstützt die Verwendung von IAM Auth für Postgres-, MySQL- und MariaDB-Datenbankverbindungen. Wählen Sie hierfür IAM Auth beim Erstellen einer neuen Verbindung.

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

Dadurch wird die Option zum Festlegen eines Passworts entfernt und stattdessen werden AWS-Anmeldeinformationen verwendet, um eine Verbindung zur Datenbank herzustellen.

Kviklet verwendet den `DefaultCredentialsProvider` von AWS, um Anmeldeinformationen zu finden und das Token für die Verbindung zu generieren. Das bedeutet, dass alle üblichen Orte funktionieren sollten (Umgebungsvariablen oder zugeordnete Instanzrollen). Die genaue Reihenfolge ist hier dokumentiert: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html

Zusätzlich können Sie eine AWS-Rollen-ARN angeben, die Kviklet übernehmen soll, und diese Anmeldeinformationen verwenden, um das temporäre DB-Token zu erstellen. Dies ist besonders nützlich für die Verbindung zu Datenbanken, die sich nicht im selben AWS-Konto wie Kviklet befinden. Um diese Funktion zu nutzen, geben Sie einfach die Rollen-ARN in das dafür vorgesehene Feld ein, wenn Sie eine IAM Auth-Verbindung erstellen oder bearbeiten. Wenn Sie das Feld leer lassen, wird der Standard-Anmeldeinformationsanbieter verwendet (keine Rollenübernahme).

Die AWS-Region, die bei der Token-Generierung verwendet werden soll, wird aus Ihrer Verbindungs-URL abgeleitet, daher gibt es keine Option, sie festzulegen.

Um zu erfahren, wie Sie IAM Auth für Ihre Datenbank einrichten, folgen Sie der offiziellen AWS-Dokumentation: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
Die beiden Hauptpunkte sind:

- Erstellen Sie einen DB-Benutzer mit der IAM-Auth-Option und den korrekten Berechtigungen
- Erstellen Sie eine IAM-Richtlinie, die es der AWS-Entität ermöglicht, Token für diesen Benutzer zu generieren

### Review Gates

Standardmäßig erlaubt Kviklet eine einfache Konfiguration der Überprüfungsanzahl. Sie können konfigurieren, wie viele Genehmigungen Anfragen auf einer bestimmten Verbindung benötigen, bevor sie ausgeführt werden können.

Der Genehmigungsstatus einer Anfrage wird basierend auf der letzten Aktion jedes Prüfers berechnet. Wenn ein Prüfer genehmigt und später Änderungen anfordert, zählt nur die Änderungsanforderung — seine frühere Genehmigung wird entfernt. Das Bearbeiten einer Anfrage setzt immer alle vorherigen Genehmigungen zurück, um sicherzustellen, dass keine Änderungen ausgeführt werden können, ohne zuvor überprüft zu werden. Wenn eine Ausführung fehlschlägt (z. B. aufgrund eines SQL-Syntaxfehlers), werden die Genehmigungen ebenfalls zurückgesetzt, damit die Anfrage korrigiert und erneut genehmigt werden kann, ohne eine neue erstellen zu müssen.

Sie können auch ein **max executions**-Limit pro Verbindung konfigurieren, um zu steuern, wie oft eine einzelne genehmigte Anfrage ausgeführt werden kann. Der Standardwert ist 1. Wenn Sie diesen auf 0 setzen, sind unbegrenzte Ausführungen möglich. Fehlgeschlagene Ausführungen zählen nicht zu diesem Limit.

#### Rollenbasierte Überprüfungsanforderungen (Enterprise)

Mit einer Kviklet Enterprise-Lizenz können Sie einzelne Verbindungen so konfigurieren, dass sie Genehmigungen von Benutzern mit bestimmten Rollen erfordern. Dies ermöglicht es Ihnen, z. B. eine Genehmigung vom Team, das eine bestimmte Datenbank verwaltet, zu verlangen oder sensible Verbindungen hinter DBA- oder Management-Genehmigungen zu sperren.

**So funktioniert es:**

Jede Verbindung hat eine **total reviews required**-Anzahl (`numTotalRequired`), die als Untergrenze fungiert — die Mindestanzahl unterschiedlicher Genehmigungen, die unabhängig von Rollen erforderlich ist. Darüber hinaus können Sie **Rollenanforderungen** hinzufügen, die angeben, wie viele Genehmigungen von Benutzern mit einer bestimmten Rolle stammen müssen (z. B. „1 von DBA, 1 von Security").

Eine Anfrage wird nur genehmigt, wenn **beide** Bedingungen erfüllt sind:

- Die Gesamtzahl der unterschiedlichen Genehmigungen erreicht `numTotalRequired`
- Jede Rollenanforderung ist einzeln erfüllt

Wenn ein Benutzer mehreren Rollen angehört, zählt eine einzelne Genehmigung dieses Benutzers für alle übereinstimmenden Rollenanforderungen. Sie zählt jedoch weiterhin nur als eine Genehmigung für die Gesamtanzahl.

**Beispiel:** Eine Verbindung erfordert 3 Gesamtgenehmigungen, darunter 1 von einem DBA und 1 von Security. Ein Benutzer, der sowohl die DBA- als auch die Security-Rolle hat, genehmigt — dies erfüllt beide Rollenanforderungen, zählt aber nur als 1 der 3 benötigten Gesamtgenehmigungen. Zwei weitere Genehmigungen von beliebigen Benutzern sind weiterhin erforderlich.

Wenn Ihre Enterprise-Lizenz abläuft, bleiben bestehende rollenbasierte Überprüfungsanforderungen in Kraft, können aber nicht mehr geändert werden. Sie können sie nur entfernen, um zur einfachen Gesamtüberprüfungskonfiguration zurückzukehren.

### Rollen

Kviklet wird mit 3 Rollen ausgeliefert: Default, Admins und Developers.

- Die Default-Rolle bietet Lesezugriff auf alle Verbindungen und Anfragen. Diese Rolle wird jedem Benutzer zugewiesen und kann nicht entfernt werden. Sie können jedoch die Berechtigungen dieser Rolle nach Belieben ändern.
- Admins haben die Berechtigung, Verbindungen zu erstellen und zu bearbeiten sowie neue Benutzer hinzuzufügen und deren Berechtigungen festzulegen.
- Developers können Anfragen erstellen sowie genehmigen und kommentieren und natürlich die eigentlichen Anweisungen ausführen.

Sie können Rollen anpassen und z. B. einer Rolle nur Zugriff auf eine bestimmte Verbindung oder eine Gruppe von DB-Verbindungen geben.
Dies ist nützlich, wenn Sie z. B. verschiedene Teams mit unterschiedlichen Datenbanken haben und den Zugriff darauf granularer steuern möchten.

#### Erstellen einer neuen Rolle

Das Erstellen einer neuen Rolle funktioniert wie folgt. Gehen Sie zu Einstellungen -> Rollen -> Rolle hinzufügen.

![Rolle hinzufügen](https://assets.kitploit.com/production/public/readmes/7140/a91b79287c0b3130b83bdde1c059f49b89c5d43a1c0deae33b211ea427956f8e.png)
![Rolle hinzufügen](https://assets.kitploit.com/production/public/readmes/7140/c535ac152759bb21bea04a0968ce43fa7bf946c7699feca23c71f9eaba41ceaf.png)

Die Standardeinstellungen sind für die meisten Rollen nicht so relevant und Sie können einfach User Read und RoleView Access vergeben und es dabei belassen.
Interessanter ist das Hinzufügen individueller Berechtigungen für Verbindungen. Hier fügen Sie zunächst einen Selektor hinzu, um bestimmte Verbindungen auszuwählen. Dies kann entweder eine bestimmte ID sein oder Sie verwenden Wildcards mit `*`, um mehrere Verbindungen abzugleichen. Wenn Sie z. B. eine Rolle haben möchten, die Zugriff auf alle Dev-Datenbanken hat (falls Sie auch den Zugriff darauf mit kviklet verwalten), würden Sie einen Selektor wie `dev-*` verwenden und sicherstellen, dass die IDs der Verbindungen korrekt gesetzt sind.

Sie können natürlich auch ein System entwickeln, das Sie für Ihre verschiedenen Teams innerhalb Ihrer Organisation verwenden.

### Rollen-Synchronisierung (Enterprise)

Synchronisieren Sie Benutzerrollen automatisch aus den Gruppen Ihres Identitätsanbieters. Diese Funktion erfordert eine Enterprise-Lizenz.

**Die Konfiguration** erfolgt unter Einstellungen > Rollen-Synchronisierung:

- **Rollen-Synchronisierung aktivieren**: Synchronisierung ein-/ausschalten
- **Synchronisierungsmodus**:
  - **Vollständige Synchronisierung** - Benutzerrollen entsprechen genau ihren IdP-Gruppenzuordnungen (plus der Standardrolle)
  - **Additiv** - IdP-Gruppen fügen Rollen hinzu, entfernen aber keine bestehenden
  - **Nur beim ersten Login** - Rollen werden nur beim ersten Login synchronisiert, manuelle Änderungen bleiben danach erhalten
- **Gruppen-Attribut**: Das IdP-Attribut, das Gruppenmitgliedschaften enthält (Standard: `groups`)
- **Rollen-Zuordnungen**: Ordnen Sie IdP-Gruppennamen (z. B. `engineering`) Kviklet-Rollen zu

#### OIDC-Einrichtung

Konfigurieren Sie Ihren OIDC-Anbieter so, dass er einen `groups`-Claim im ID-Token enthält:

- **Keycloak**:

  Keycloak fügt Gruppen standardmäßig nicht in Tokens ein, daher müssen Sie einen Mapper zum Client hinzufügen.
  1. Navigieren Sie zu **Clients** im linken Menü
  2. Wählen Sie Ihren Kviklet-Client aus
  3. Gehen Sie zum Tab **Client scopes**
  4. Klicken Sie auf den dedizierten Scope (z. B. `kviklet-dedicated`)
  5. Gehen Sie zum Tab **Mappers**
  6. Klicken Sie auf **Add mapper** → **By configuration**
  7. Wählen Sie **Group Membership**
  8. Konfigurieren Sie den Mapper:

  | Einstellung         | Wert     |
  | ------------------- | -------- |
  | 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. Klicken Sie auf **Save**

  > **Wichtig:** Der „Token Claim Name" muss mit dem „Groups Attribute" übereinstimmen, das in Kviklets Rollen-Synchronisierungs-Einstellungen konfiguriert ist (Standard: `groups`).

- **Andere OIDC-Anbieter**: Fügen Sie einen Gruppen-Mapper/Claim hinzu, der die Gruppenmitgliedschaften des Benutzers im ID-Token enthält. Dies erfolgt typischerweise in der Admin-Oberfläche des Anbieters.

  Wenn Sie auf Probleme stoßen, können Sie gerne ein Issue erstellen. Wir haben noch nicht jeden einzelnen OIDC-Anbieter ausprobiert (noch nicht) und es könnte geringfügige Unterschiede in der Implementierung geben, die Aktualisierungen auf Kviklets Seite erfordern könnten.

#### LDAP-Einrichtung

Die LDAP-Rollensynchronisierung verwendet das `memberOf`-Attribut:

1. Stellen Sie sicher, dass Ihr LDAP-Server das `memberOf`-Overlay aktiviert hat
2. Setzen Sie **Groups Attribute** auf `memberOf` in Kviklet
3. Gruppennamen werden dann aus dem `memberOf`-Attribut in den Benutzerattributen extrahiert.

#### SAML-Einrichtung

Konfigurieren Sie Ihren SAML-IdP so, dass er Gruppen in der Assertion enthält:

1. Fügen Sie eine Attribut-Anweisung hinzu, die Benutzergruppenmitgliedschaften zuordnet
2. Setzen Sie das **Groups Attribute** in Kviklet so, dass es mit Ihrem SAML-Attributnamen übereinstimmt
3. Gruppennamen werden dann aus dem SAML-Attribut in den Benutzerattributen extrahiert.

### Benachrichtigungen

Sie können Kviklet so konfigurieren, dass Benachrichtigungen an einen Kanal in Slack oder Teams gesendet werden. Dies ist nützlich, um Ihr Team über neue Anfragen zu informieren, die überprüft werden müssen. Sie können dies unter Einstellungen -> Allgemein -> Benachrichtigungseinstellungen konfigurieren.

#### Slack

Um Slack-Benachrichtigungen zu konfigurieren, müssen Sie eine Slack-App erstellen und Webhooks dafür aktivieren. Sie können den Anweisungen hier folgen: https://api.slack.com/messaging/webhooks

#### Teams

Teams-Benachrichtigungen verwenden einen Power Automate **Workflow**-Webhook. Kviklet sendet eine Adaptive Card, die die Webhook-Vorlage in Ihren Kanal postet.

**Empfohlen: Verwenden Sie die Workflow-Vorlage**

1. Öffnen Sie in Teams den Kanal, in dem Sie Benachrichtigungen erhalten möchten, klicken Sie auf die **...** neben dem Kanalnamen und wählen Sie **Workflows** (oder fügen Sie die **Workflows**-App hinzu).
2. Suchen Sie nach der Vorlage **„Send webhook alerts to a channel"** und erstellen Sie sie.
3. Melden Sie sich bei Aufforderung an, wählen Sie dann das Ziel-Team und den Kanal aus und erstellen Sie den Workflow.
4. Öffnen Sie den Trigger-Schritt und kopieren Sie die generierte **HTTP POST URL**.
5. Fügen Sie die URL in Kviklet unter Einstellungen -> Allgemein -> Benachrichtigungseinstellungen ein und klicken Sie auf Speichern.

**Alternative: Erstellen Sie den Workflow manuell**

Wenn Sie den Flow lieber selbst erstellen möchten (oder die Vorlage nicht verfügbar ist):

1. Kanal **...** -> **Workflows** -> Erstellen Sie einen Flow mit dem Trigger **„When a Teams webhook request is received"**.
2. Fügen Sie die Aktion **Microsoft Teams -> „Post card in a chat or channel"** hinzu.
3. Setzen Sie das Feld **Adaptive Card** der Aktion auf den Ausdruck `string(triggerBody())`, damit die von Kviklet gesendete Karte gepostet wird.
4. Wählen Sie das Ziel-Team und den Kanal aus, **Speichern** Sie, und kopieren Sie dann die **HTTP POST URL** aus dem Trigger-Schritt.

Derzeit gibt es Benachrichtigungen für:

- Neue Anfragen, die Genehmigungen benötigen
- Neue Genehmigungen für Anfragen

#### Basis-URL-Konfiguration

Wenn Kviklet hinter einem Reverse-Proxy oder Kubernetes Ingress ausgeführt wird, verwenden Benachrichtigungslinks möglicherweise die interne IP-Adresse anstelle Ihrer öffentlichen Domain. Kviklet versucht, die korrekte URL zu ermitteln, indem es eingehende Anfragen betrachtet, aber einige Reverse-Proxys setzen die Forwarded-Header nicht korrekt. Um dies zu beheben, legen Sie die Basis-URL explizit fest:```
KVIKLET_BASE_URL=https://kviklet.example.com

Kviklet protokolliert beim Start eine Zeile, die angibt, ob Telemetrie aktiviert ist.

**Was gesendet wird.** Jedes Ereignis trägt eine zufällige Instanz-ID (einmal generiert und in Kviklets Datenbank gespeichert), die Basis-URL, unter der Kviklet erreichbar ist (siehe oben; oft ein interner Hostname), und die Kviklet-Version. Benutzer werden nur durch eine undurchsichtige, auf die Instanz beschränkte ID identifiziert, sodass eindeutige Benutzer gezählt werden können, aber es werden niemals E-Mail-Adressen oder Namen gesendet. Die genauen Ereignisse und ihre Eigenschaften sind in `backend/src/main/kotlin/dev/kviklet/kviklet/telemetry/TelemetryEvent.kt` definiert.

**Was niemals gesendet wird.** Abfragen, Anweisungen, Ergebnisse, Befehlsausgaben, Fehlermeldungen, Verbindungsnamen, Hostnamen, Anmeldedaten, Anfrage-Titel oder -Beschreibungen, Kommentare sowie Benutzer- oder Rollennamen.

### Protokollierung

Standardmäßig schreibt Kviklet menschenlesbare (pretty) Logs nach stdout, was praktisch ist, wenn man sie direkt oder über `docker logs` liest.

Wenn Sie Logs an ein zentrales System (Elasticsearch, Loki, Datadog, CloudWatch, …) weiterleiten, können Sie stattdessen auf strukturierte **JSON-Logs** umsteigen, die einfacher zu indizieren und abzufragen sind. Legen Sie das Format über eine Umgebungsvariable fest:```
# One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs

Kviklet verschlüsselt beim Start alle vorhandenen Anmeldedaten und verwendet das Secret für zukünftige Verbindungen, die du erstellst.

### Schlüsselrotation

Wenn du den Schlüssel rotieren möchtest, kannst du einfach eine weitere Variable für den vorherigen Schlüssel hinzufügen und den aktuellen ändern:```
ENCRYPTION_KEY_PREVIOUS=some-secret
ENCRYPTION_KEY_CURRENT=another-secret

API-Schlüssel erben die Berechtigungen des Benutzers, der sie erstellt. Derzeit können nur Administratoren API-Schlüssel verwalten, und alle mit einem API-Schlüssel durchgeführten Aktionen werden dem Benutzer zugeschrieben, der den Schlüssel erstellt hat.

Einige rudimentäre API-Dokumentationen finden sich unter `[kviklet_host]/api/swagger-ui/index.html`. Beachten Sie jedoch, dass dies ein Work in Progress ist und sich die API in zukünftigen Versionen ändern kann.

Letztendlich liegt die Wahrheit im Code, daher können Sie jederzeit den Controller ansehen, um zu sehen, wie die API definiert ist. Wenn Sie Fragen haben, können Sie gerne ein Issue eröffnen.

## Experimentelle Funktionen

Derzeit gibt es zwei experimentelle Funktionen. Sie wurden größtenteils auf Basis von Community-Feedback entwickelt. Probieren Sie diese gerne aus und hinterlassen Sie Ihr Feedback. Wir hoffen, dies in Zukunft weiterzuentwickeln und gut mit dem Kern-Genehmigungsablauf zu integrieren.

### Kubernetes Exec

Wenn Sie die Kubernetes-Exec-Funktion nutzen möchten, müssen Sie eine separate Kubernetes-Verbindung erstellen. Kviklet verwendet den Benutzer des bereitgestellten Pods, um den Befehl auszuführen. Stellen Sie daher sicher, dass der Benutzer über die erforderlichen Berechtigungen verfügt, um Befehle auf den Pods auszuführen, auf die Sie zugreifen möchten.

Kviklet verwendet außerdem /bin/sh, um den Befehl auszuführen, daher müssen Sie sicherstellen, dass Ihre Pods eine Shell oder zumindest einen Symlink in /bin/sh haben. Wenn Sie das stört, können Sie gerne ein Issue eröffnen; wir können dies möglicherweise konfigurierbar machen oder eine andere Lösung finden.

Kubernetes-Befehle warten nur 5 Sekunden auf die Ausgabe. Wenn der Befehl länger dauert, wartet Kviklet bis zu einer Stunde, bevor der Befehl ein Timeout erhält. Dies ist eine vorläufige Lösung; wir untersuchen WebSockets, um dies reaktionsschneller zu machen und möglicherweise Terminal-Sitzungen zu ermöglichen.

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

Wenn Sie Anfragen für temporären Zugriff erstellen, können Sie – anstatt die Weboberfläche zu verwenden – Ihre Abfragen über einen von Kviklet verwalteten Proxy ausführen und den DB-Client Ihrer Wahl verwenden.
Der Proxy ist eine Enterprise-Funktion: Er erfordert eine gültige Lizenz, und ein Administrator muss ihn zusätzlich unter Einstellungen -> Allgemein -> Datenbank-Proxy aktivieren.
Dazu lauscht der Container auf festen Ports (standardmäßig 5432 und 3306, konfigurierbar über `kviklet.proxy.postgres.port` und `kviklet.proxy.mysql.port`), daher müssen Sie diese Ports freigeben.
Benutzer können dann eine temporäre Zugriffsanfrage erstellen und nach der Genehmigung auf „Proxy starten“ klicken. Jede Anfrage erhält einen temporären Benutzernamen und ein Passwort; Kviklet ordnet jede Verbindung anhand des Benutzernamens ihrer Anfrage zu. Damit können sie sich mit der Datenbank verbinden. Kviklet validiert den temporären Benutzer und das Passwort und leitet alle Anfragen an den zugrunde liegenden Benutzer auf der Datenbank weiter. Alle ausgeführten Anweisungen werden im Audit-Log protokolliert, als wären sie über die Weboberfläche ausgeführt worden.

Hinweis: Der Proxy unterstützt derzeit keine Ergebnisverfolgung. Ausgeführte Anweisungen werden also protokolliert, aber nicht die Ergebnisse oder ob eine Anweisung erfolgreich war oder fehlgeschlagen ist.

![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 beendet die TLS-Verbindung zur Datenbank. Das bedeutet, dass standardmäßig jeglicher Datenverkehr von und zum Proxy selbst nicht verschlüsselt ist.  
Wenn Sie möchten, dass Kviklet den Datenverkehr erneut verschlüsselt, können Sie Kviklet ein TLS-Zertifikat und einen Schlüssel für den Proxy bereitstellen, indem Sie die folgenden Umgebungsvariablen setzen:```
PROXY_TLS_CERTIFICATE_SOURCE=env
PROXY_TLS_CERTIFICATE_CERT=your-certificate
PROXY_TLS_CERTIFICATE_KEY=your-key

In beiden Fällen müssen das Zertifikat und der Schlüssel im [PEM-Format](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) gespeichert werden.

## Fragen? Beiträge?

Wenn du Fragen hast, Feedback geben möchtest oder Hilfe bei der Einrichtung benötigst, tritt unserer [Discord-Community](https://discord.gg/7SmPJfeP6e) bei. Du kannst auch ein [GitHub-Issue](https://github.com/kviklet/kviklet/issues) für Fehlerberichte und Funktionswünsche erstellen.

Wenn du beitragen möchtest, kannst du gerne forken und PRs für kleine Dinge erstellen. Wenn du größere Funktionen planst, würde ich mich über eine vorherige Diskussion in einem GitHub-Issue oder auf Discord freuen.

Du kannst mich auch unter [email protected] kontaktieren.