alter table public.Locations owner to postgres;

INSERT INTO public.Locations (Name, Address, City, Country, PostalCode) VALUES ('Central Park', '59th to 110th St', 'New York', 'USA', '10022'), ('Eiffel Tower', 'Champ de Mars, 5 Avenue Anatole', 'Paris', 'France', '75007'), ('Colosseum', 'Piazza del Colosseo, 1', 'Rome', 'Italy', '00184'), ('Sydney Opera House', 'Bennelong Point', 'Sydney', 'Australia', '2000'), ('Great Wall of China', 'Huairou District', 'Beijing', 'China', '101405');

</details>

### Configuración de la base de datos

Kviklet necesita su propia base de datos postgres (o al menos un esquema) para guardar metadatos sobre consultas, conexiones, aprobaciones, etc.
Puedes encontrar su imagen oficial aquí: https://hub.docker.com/_/postgres, o usar una versión alojada en la nube de tu proveedor de nube preferido.

Al iniciar el contenedor de kviklet, deberás configurar estas tres variables de entorno en consecuencia:```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]

Métodos alternativos de autenticación

• IAM Auth: Es posible usar AWS IAM Auth para la conexión a la base de datos, en cuyo caso simplemente omite la contraseña y solo establece el nombre de usuario. También debes configurar la variable de entorno:

SPRING_DATASOURCE_IAMAUTH=true

Kviklet cargará las credenciales desde los lugares habituales (variables de entorno, roles de instancia, etc.) y generará un token para la conexión.

- **Certificados:**
También puede usar certificados para la conexión a la base de datos, consulte [aquí](https://github.com/kviklet/kviklet/blob/HEAD/examples/certificates) para ver un ejemplo.

### Usuario Inicial

Necesitará un usuario administrador inicial para fines de configuración. Para ello, establezca las 2 variables de entorno:
`INITIAL_USER_EMAIL` y `INITIAL_USER_PASSWORD` para que pueda iniciar sesión en la interfaz web. Luego puede cambiar la contraseña mediante la interfaz de usuario.  
Ejemplo:```
[email protected]
INITIAL_USER_PASSWORD=someverysecurepassword

Publicamos nuestros contenedores en GitHub packages por ahora, así que con todo esto configurado puedes ejecutar ghcr.io/kviklet/kviklet:main no olvides mapear el puerto 8080 que es el puerto predeterminado en el que Kviklet se inicia.

Un ejemplo de docker run podría verse así:``` docker run
-e SPRING_DATASOURCE_PASSWORD=postgres
-e SPRING_DATASOURCE_USERNAME=postgres
-e SPRING_DATASOURCE_URL=jdbc:postgresql://localhost:5432/Kviklet
-e INITIAL_USER_EMAIL=[email protected]
-e INITIAL_USER_PASSWORD=someverysecurepassword
--network host
ghcr.io/kviklet/kviklet:main

### SSO mediante OIDC / OAuth2

#### Google

Si deseas configurar SSO para tu instancia de Kviklet (lo cual tiene mucho sentido, ya que de lo contrario tendrías que gestionar contraseñas nuevamente).
Necesitas configurar estas 3 variables de entorno:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=google

Puede obtener fácilmente el ID de cliente y el secreto de Google siguiendo las instrucciones de Google aquí: https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid

Para URI de redireccionamiento válidas, debe configurar: https://[kviklet_host]/api/login/oauth2/code/google Para Orígenes permitidos, simplemente la URL de su kviklet alojado.

Después de configurar esas variables de entorno, todos en su organización pueden iniciar sesión con el botón de 'Iniciar sesión con Google'. Pero no tendrán ningún permiso de forma predeterminada; deberá asignarles un rol después de que inicien sesión una vez.

Keycloak

Si desea configurar SSO con Keycloak en su lugar, debe establecer estas 4 variables de entorno:``` KVIKLET_IDENTITYPROVIDER_CLIENTID KVIKLET_IDENTITYPROVIDER_CLIENTSECRET KVIKLET_IDENTITYPROVIDER_TYPE=keycloak KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]

Obtienes el client ID y el secreto cuando creas una aplicación en Keycloak.
Para las URI de redirección válidas, debes configurar: https://[kviklet_host]/api/login/oauth2/code/keycloak
Para Allowed Origins, simplemente la URL de tu instancia de Kviklet.

Después de establecer esas variables de entorno, la página de inicio de sesión debería mostrar un botón de «Iniciar sesión con Keycloak» que redirige a tu instancia de Keycloak. En la edición empresarial, puedes habilitar la sincronización de roles para sincronizar automáticamente los roles desde tu instancia de Keycloak a Kviklet. Consulta la sección [Role Sync](#role-sync-enterprise) para más detalles.

#### GitHub (Beta)

> **Beta:** La autenticación de GitHub es nueva y **no** es compatible con [role sync](#role-sync-enterprise) aún — cada nuevo usuario obtiene el rol predeterminado y se le deben asignar roles manualmente.

GitHub no es compatible con OIDC (es OAuth 2.0 puro), por lo que tiene soporte dedicado en Kviklet. Configura estas variables de entorno:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=github
KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS=your-org,another-org

Crea una aplicación OAuth de GitHub en https://github.com/settings/developers y configúrala:

• URL de callback de autorización: https://[kviklet_host]/api/login/oauth2/code/github
• URL de inicio: la URL de tu Kviklet alojado

KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS es obligatorio (Kviklet se niega a iniciar sin él). Las aplicaciones OAuth de GitHub no pueden restringir quién completa el flujo OAuth, por lo que Kviklet llama a /user/orgs después de la autenticación y rechaza a los usuarios que no son miembros de al menos una organización en la lista blanca (sin distinción entre mayúsculas y minúsculas, se verifican las primeras 100 organizaciones).

Para que la verificación de organización pueda ver la membresía de un usuario, el usuario debe hacer clic en Grant (o Request) junto a cada organización en la lista blanca en la pantalla de consentimiento OAuth. Si la organización tiene habilitada la opción "Restrict third-party OAuth applications", el propietario de la organización también debe aprobar la aplicación OAuth una vez antes de que la membresía de cualquier miembro sea visible.

Kviklet solicita los ámbitos read:user, user:email y read:org. Los correos electrónicos siempre se leen de /user/emails y solo se acepta una entrada primary && verified, por lo que los usuarios con direcciones de correo electrónico privadas aún pueden iniciar sesión correctamente.

Otros proveedores OIDC

Otros proveedores compatibles con OIDC (GitLab, Auth0, Okta, etc.) deberían funcionar de manera similar a Keycloak. Ten en cuenta que la redirect URI cambiará según el tipo que elijas, por lo que si eliges gitlab, será https://[kviklet_host]/api/login/oauth2/code/gitlab. Si tienes problemas, no dudes en crear un issue, no hemos probado todos los proveedores OIDC (aún) y puede haber ligeras diferencias en la implementación que puedan requerir actualizaciones por parte de Kviklet.

LDAP

Kviklet soporta autenticación LDAP. Para habilitar y configurar LDAP, puedes sobrescribir las siguientes variables de entorno:``` 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

Esto es lo que significa cada configuración:

- `LDAP_ENABLED`: Establézcalo en `true` para habilitar la autenticación LDAP.
- `LDAP_URL`: La URL de su servidor LDAP.
- `LDAP_BASE`: El DN base para las búsquedas LDAP.
- `LDAP_PRINCIPAL`: El DN del usuario administrador para enlazar con el servidor LDAP.
- `LDAP_PASSWORD`: La contraseña del usuario administrador.
- `LDAP_UNIQUE_IDENTIFIER_ATTRIBUTE`: El atributo LDAP utilizado como identificador único para los usuarios (por defecto: "uid").
- `LDAP_EMAIL_ATTRIBUTE`: El atributo LDAP que contiene la dirección de correo electrónico del usuario (por defecto: "mail").
- `LDAP_FULL_NAME_ATTRIBUTE`: El atributo LDAP que contiene el nombre completo del usuario (por defecto: "cn").
- `LDAP_USER_OU`: La Unidad Organizativa (OU) donde se almacenan las cuentas de usuario (por defecto: "people").
- `LDAP_SEARCH_BASE`: Permite sobrescribir el DN base para las búsquedas de usuarios (por defecto: "ou=people"). Si usa FreeIPA, es posible que necesite establecer esto en, por ejemplo, `cn=users`. Si se establece, se ignora LDAP_USER_OU.

Puede personalizar estos atributos para que coincidan con su esquema LDAP. Después de configurar LDAP, los usuarios podrán iniciar sesión usando sus credenciales LDAP. La primera vez que un usuario LDAP inicia sesión, se creará una cuenta de usuario correspondiente en Kviklet con permisos predeterminados. Un administrador deberá asignar los roles apropiados a estos usuarios después de su primer inicio de sesión.

### SAML (solo Enterprise)

Kviklet admite la autenticación SAML 2.0. Para habilitar SAML, establezca las siguientes variables de entorno:```
SAML_ENABLED=true
SAML_ENTITYID=https://your-identity-provider.com
SAML_SSOSERVICELOCATION=https://your-identity-provider.com/sso
SAML_VERIFICATIONCERTIFICATE=-----BEGIN CERTIFICATE-----\nMIICmzCCAYMCBgF4...\n-----END CERTIFICATE-----

Detalles de configuración:

• SAML_ENABLED: Establézcalo en true para habilitar la autenticación SAML
• SAML_ENTITYID: El ID de entidad de su proveedor de identidad SAML
• SAML_SSOSERVICELOCATION: La URL del servicio SSO de su proveedor de identidad
• SAML_VERIFICATIONCERTIFICATE: El certificado X.509 utilizado para verificar las respuestas SAML (incluya las líneas BEGIN/END CERTIFICATE)

Opcionalmente, puede personalizar las asignaciones de atributos SAML:``` SAML_USERATTRIBUTES_EMAILATTRIBUTE=email SAML_USERATTRIBUTES_NAMEATTRIBUTE=name SAML_USERATTRIBUTES_IDATTRIBUTE=nameID

Su proveedor de identidad debe configurarse con:

- ID de entidad: `https://[kviklet_host]/api/saml2/service-provider-metadata/saml`
- URI de redirección: `https://[kviklet_host]/api/login/saml2/sso/saml`

Después de configurar SAML, los usuarios pueden iniciar sesión a través del proveedor de identidad. En el primer inicio de sesión, se crea una cuenta de usuario con permisos predeterminados.

Si se redirige correctamente al IDP pero luego obtiene un error CORS, puede agregar el host de su IDP a los orígenes permitidos en Kviklet mediante:```
CORS_ALLOWEDORIGINS=https://[idp_host]

Configuración

Conexiones

Después de iniciar Kviklet, primero debes configurar una conexión a la base de datos. Ve a Ajustes → Bases de datos → Añadir conexión.

Aquí puedes configurar los requisitos de revisión y los límites de ejecución para cada conexión. Consulta Puertas de revisión para más detalles.

AWS IAM AUTH

Kviklet admite el uso de autenticación IAM para conexiones de bases de datos Postgres y MySQL; para ello, elige IAM Auth al crear una nueva conexión.

Esto eliminará la opción de establecer una contraseña y, en su lugar, usará las credenciales de AWS para conectarse a la base de datos.

Kviklet usa el DefaultCredentialsProvider de AWS para encontrar las credenciales y generar el token para la conexión. Esto significa que todos los lugares típicos deberían funcionar (variables de entorno o roles de instancia asociados). El orden exacto está documentado aquí: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html

Adicionalmente, puedes proporcionar un ARN de rol de AWS que Kviklet asumirá, y usará esas credenciales para crear el token temporal de la base de datos. Esto es particularmente útil para conectar a bases de datos que no están en la misma cuenta de AWS que Kviklet. Para usar esta función, simplemente ingresa el ARN del rol en el campo designado al crear o editar una conexión IAM Auth. Dejar el campo vacío usará el proveedor de credenciales por defecto (sin asunción de roles).

La región de AWS a utilizar durante la generación del token se infiere de la URL de conexión, por lo que no hay opción para configurarla.

Para aprender cómo configurar IAM Auth en tu base de datos, sigue la documentación oficial de AWS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html Los dos puntos principales son:

• Crear un usuario de base de datos con la opción de autenticación IAM y permisos correctos
• Crear una política de IAM que permita a la entidad de AWS generar tokens para este usuario

Puertas de revisión

Por defecto, Kviklet permite una configuración simple de recuento de revisiones. Puedes configurar cuántas aprobaciones necesita una solicitud en una conexión específica antes de que se pueda ejecutar.

El estado de aprobación de una solicitud se calcula en función de la última acción de cada revisor. Si un revisor aprueba y luego solicita cambios, solo cuenta la solicitud de cambio; su aprobación anterior se elimina. Editar una solicitud siempre restablece todas las aprobaciones previas, asegurando que ningún cambio pueda ejecutarse sin ser revisado primero. De manera similar, si una ejecución falla (por ejemplo, debido a un error de sintaxis SQL), las aprobaciones se restablecen para que la solicitud pueda corregirse y volver a aprobarse sin tener que crear una nueva.

También puedes configurar un límite de ejecuciones máximas por conexión para controlar cuántas veces se puede ejecutar una solicitud aprobada. El valor predeterminado es 1. Establecerlo en 0 permite ejecuciones ilimitadas. Las ejecuciones fallidas no cuentan para este límite.

Requisitos de revisión basados en roles (Enterprise)

Con una licencia Enterprise de Kviklet puedes configurar conexiones individuales para que requieran aprobaciones de usuarios con roles específicos. Esto te permite, por ejemplo, requerir la aprobación del equipo que mantiene una base de datos determinada o proteger conexiones sensibles detrás de aprobaciones de DBA o gerencia.

Cómo funciona:

Cada conexión tiene un recuento de revisiones totales requeridas (numTotalRequired) que actúa como un límite mínimo: la cantidad de aprobaciones distintas necesarias independientemente de los roles. Además, puedes agregar requisitos de roles que especifiquen cuántas aprobaciones deben provenir de usuarios con un rol particular (por ejemplo, "1 de DBA, 1 de Seguridad").

Una solicitud se aprueba solo cuando se cumplen ambas condiciones:

• El número total de aprobaciones distintas alcanza numTotalRequired
• Cada requisito de rol se satisface individualmente

Si un usuario pertenece a varios roles, una sola aprobación de ese usuario cuenta para todos los requisitos de rol coincidentes. Sin embargo, sigue contando solo como una aprobación hacia el total requerido.

Ejemplo: Una conexión requiere 3 aprobaciones totales, incluyendo 1 de un DBA y 1 de Seguridad. Un usuario que tiene tanto el rol de DBA como el de Seguridad aprueba — esto satisface ambos requisitos de rol pero solo cuenta como 1 de las 3 aprobaciones totales necesarias. Todavía se requieren dos aprobaciones más de cualquier usuario.

Si tu licencia enterprise expira, los requisitos de revisión basados en roles existentes permanecen en vigor pero ya no se pueden modificar. Solo puedes eliminarlos para volver a la configuración simple de revisiones totales.

Roles

Kviklet viene con 3 roles: Predeterminado, Administradores y Desarrolladores.

• El rol predeterminado proporciona acceso de lectura a todas las conexiones y solicitudes. Este rol se asigna a todos los usuarios y no se puede eliminar. Sin embargo, puedes modificar los permisos de este rol como desees.
• Los Administradores tienen permiso para crear y editar conexiones, así como agregar nuevos usuarios y establecer sus permisos.
• Los Desarrolladores pueden crear solicitudes, así como aprobarlas y comentarlas y, por supuesto, ejecutar las sentencias reales.

Puedes personalizar los roles y, por ejemplo, otorgar a un rol acceso solo a una conexión específica o a un grupo de conexiones de bases de datos. Esto es útil, por ejemplo, si tienes diferentes equipos con diferentes bases de datos y deseas controlar el acceso a ellas de manera más granular.

Crear un nuevo rol

Crear un nuevo rol funciona de la siguiente manera. Ve a Ajustes → Roles → Añadir rol.

La configuración predeterminada no es muy relevante para la mayoría de los roles; puedes simplemente darle al usuario acceso de Lectura y Vista de roles y dejarlo así. Más interesante es agregar permisos individuales para las conexiones. Aquí primero agregas un selector para seleccionar conexiones específicas. Esto puede ser un id específico o puedes usar comodines con * para coincidir con múltiples conexiones. Por ejemplo, si deseas tener un rol que tenga acceso a todas las bases de datos de desarrollo (en caso de que también administres el acceso a esas con Kviklet), usarías un selector como dev-* y asegurarte de que los ids de las conexiones estén configurados correctamente.

Por supuesto, también puedes inventar un sistema que uses para tus diferentes equipos dentro de tu organización.

Sincronización de roles (Enterprise)

Sincroniza automáticamente los roles de usuario desde los grupos de tu proveedor de identidad. Esta función requiere una licencia enterprise.

Configuración se realiza en Ajustes > Sincronización de roles:

• Habilitar sincronización de roles: Activar/desactivar la sincronización
• Modo de sincronización:
  • Sincronización completa - Los roles de los usuarios coinciden exactamente con sus asignaciones de grupos del IdP (más el rol predeterminado)
  • Aditivo - Los grupos del IdP agregan roles pero no eliminan los existentes
  • Solo en el primer inicio de sesión - Los roles se sincronizan solo en el primer inicio de sesión; los cambios manuales se conservan después
• Atributo de grupos: El atributo del IdP que contiene las membresías de grupo (predeterminado: groups)
• Asignaciones de roles: Asigna nombres de grupos del IdP (por ejemplo, engineering) a roles de Kviklet

Configuración OIDC

Configura tu proveedor OIDC para incluir una declaración groups en el token de identificación:

• Keycloak:

  Keycloak no incluye grupos en los tokens de forma predeterminada, por lo que deberás agregar un mapper al cliente.

  1. Navega a Clients en el menú izquierdo
  2. Selecciona tu cliente de Kviklet
  3. Ve a la pestaña Client scopes
  4. Haz clic en el ámbito dedicado (por ejemplo, kviklet-dedicated)
  5. Ve a la pestaña Mappers
  6. Haz clic en Add mapper → By configuration
  7. Selecciona Group Membership
  8. Configura el mapper:

  Configuración	Valor
  Nombre	groups
  Nombre de la declaración del token	groups
  Ruta completa del grupo	OFF
  Añadir al token de identificación	ON
  Añadir al token de acceso	ON
  Añadir a userinfo	ON

  9. Haz clic en Save

  Importante: El "Token Claim Name" debe coincidir con el "Groups Attribute" configurado en los ajustes de Sincronización de roles de Kviklet (predeterminado: groups).

• Otros proveedores OIDC: Agrega un mapper/declaración de grupos que incluya las membresías de grupo del usuario en el token de identificación. Esto normalmente se hace en la interfaz de administración del proveedor.

  Si te encuentras con problemas, no dudes en crear un issue; no hemos probado todos los proveedores OIDC existentes (aún) y podría haber ligeras diferencias en la implementación que requieran actualizaciones por parte de Kviklet.

Configuración LDAP

La sincronización de roles LDAP usa el atributo memberOf:

1. Asegúrate de que tu servidor LDAP tenga habilitado el overlay memberOf
2. Establece Groups Attribute como memberOf en Kviklet
3. Los nombres de los grupos se extraen del atributo memberOf en los atributos del usuario.

Configuración SAML

Configura tu IdP SAML para incluir grupos en la afirmación:

1. Agrega una declaración de atributo que asigne las membresías de grupo del usuario
2. Establece el Groups Attribute en Kviklet para que coincida con el nombre del atributo SAML
3. Los nombres de los grupos se extraen del atributo SAML en los atributos del usuario.

Notificaciones

Puedes configurar Kviklet para que envíe notificaciones a un canal en Slack o Teams. Esto es útil para notificar a tu equipo sobre nuevas solicitudes que necesitan revisión. Puedes configurarlo en Ajustes → General → Configuración de notificaciones.

Slack

Para configurar notificaciones de Slack, necesitas crear una aplicación de Slack y habilitar los webhooks para ella. Puedes seguir las instrucciones aquí: https://api.slack.com/messaging/webhooks

Teams

Las notificaciones de Teams utilizan un webhook de Workflow de Power Automate. Kviklet envía una tarjeta adaptable (Adaptive Card), que la plantilla del webhook publica en tu canal.

Recomendado: usar la plantilla del workflow

1. En Teams, abre el canal donde deseas recibir notificaciones, haz clic en el ... junto al nombre del canal y elige Workflows (o agrega la aplicación Workflows).
2. Busca y crea la plantilla "Send webhook alerts to a channel".
3. Inicia sesión cuando se te solicite, luego selecciona el equipo y canal de destino y crea el workflow.
4. Abre el paso del desencadenador y copia la URL HTTP POST generada.
5. Pega la URL en Kviklet en Ajustes → General → Configuración de notificaciones y haz clic en guardar.

Alternativa: construir el workflow manualmente

Si prefieres construir el flujo tú mismo (o la plantilla no está disponible):

1. Canal ... -> Workflows -> crea un flujo con el desencadenador "When a Teams webhook request is received".
2. Agrega la acción Microsoft Teams -> "Post card in a chat or channel".
3. Establece el campo Adaptive Card de la acción en la expresión string(triggerBody()) para que publique la tarjeta que Kviklet envía.
4. Selecciona el equipo y canal de destino, Guardar, luego copia la URL HTTP POST del paso del desencadenador.

Actualmente hay notificaciones para:

• Nuevas solicitudes que necesitan aprobaciones
• Nuevas aprobaciones en solicitudes

Configuración de la URL base

Cuando Kviklet se ejecuta detrás de un proxy inverso o un Ingress de Kubernetes, los enlaces de las notificaciones pueden usar la dirección IP interna en lugar de tu dominio público. Kviklet intenta rastrear la URL correcta examinando las solicitudes entrantes, pero algunos proxies inversos no configuran correctamente las cabeceras Forwarded. Para solucionarlo, establece la URL base explícitamente:``` KVIKLET_BASE_URL=https://kviklet.example.com

Esto asegura que todos los enlaces de notificación apunten a la URL pública correcta.

### Registro

Por defecto, Kviklet escribe registros legibles para humanos (pretty) en stdout, lo cual es conveniente al leerlos directamente o mediante `docker logs`.

Si envías registros a un sistema centralizado (Elasticsearch, Loki, Datadog, CloudWatch, …) puedes cambiar a **registros JSON** estructurados en su lugar, que son más fáciles de indexar y consultar. Establece el formato mediante una variable de entorno:```
# One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs

Cifrado

Si no deseas que las credenciales se almacenen en texto claro en la base de datos, se recomienda habilitar el cifrado de base de datos en la propia base de datos postgres de Kviklet. Para la mayoría de los proveedores alojados, esto es simplemente una casilla de verificación que marcar.

No obstante, si la base de datos de Kviklet se viera comprometida de alguna manera, esto supone un gran riesgo de seguridad, ya que contiene las credenciales de base de datos de potencialmente todos tus almacenes de datos de producción. Por lo tanto, puedes habilitar el cifrado de las credenciales en reposo.

Para ello, simplemente configura las dos variables de entorno.``` ENCRYPTION_ENABLED=true ENCRYPTION_KEY_CURRENT=some-secret

Kviklet cifrará todas tus credenciales existentes al iniciar, y usará el secreto para futuras conexiones que crees.

### Rotación de Claves

Si deseas rotar la clave, simplemente puedes agregar otra variable para la clave anterior y cambiar la actual:```
ENCRYPTION_KEY_PREVIOUS=some-secret
ENCRYPTION_KEY_CURRENT=another-secret

Kviklet volverá a cifrar todas las conexiones al iniciarse, para que luego puedas reiniciar el contenedor con la clave anterior eliminada.

Claves de API

Kviklet admite claves de API para acceso programático al sistema. Esta es una característica solo para empresas y requiere una licencia válida. Puedes crear claves de API en la sección Configuración -> Claves de API.

Úsalo de la siguiente manera:```bash curl --location '[kviklet_host]/api/connections/'
--header 'Authorization: Bearer your-api-key'

Las claves API heredan los permisos del usuario que las crea. Actualmente solo los administradores pueden gestionar las claves API y todas las acciones realizadas con una clave API se atribuyen al usuario que creó la clave.

Puede encontrar documentación rudimentaria de la API en `[kviklet_host]/api/swagger-ui/index.html`. Pero tenga en cuenta que esto es un trabajo en progreso y la API podría cambiar en versiones futuras.

Al final, la verdad está en el código, por lo que siempre puede consultar el controlador para ver cómo está definida la API. Si tiene alguna pregunta, no dude en abrir un issue.

## Funciones Experimentales

Actualmente hay dos funciones experimentales. Fueron construidas principalmente con comentarios de la comunidad. Siéntase libre de probarlas y dejar cualquier comentario que pueda tener. Esperamos desarrollarlas más en el futuro y hacer que funcionen bien con el flujo de aprobación central.

### Kubernetes Exec

Si desea utilizar la función Kubernetes Exec, debe crear una conexión kubernetes separada. Kviklet utilizará el usuario del pod desplegado para ejecutar el comando. Así que asegúrese de que el usuario tenga los permisos necesarios para ejecutar comandos en los pods a los que desea acceder.

Kviklet también usa /bin/sh para ejecutar el comando, por lo que deberá asegurarse de que sus pods tengan un shell o al menos un enlace simbólico en /bin/sh. Si esto le molesta, no dude en abrir un issue; potencialmente podemos hacer esto configurable o encontrar otra solución.

Los comandos de Kubernetes solo esperan 5 segundos para la salida; si el comando tarda más que eso, Kviklet esperará hasta una hora antes de agotar el tiempo de espera del comando. Esta es una solución provisional; estamos investigando websockets para hacer esto más receptivo y potencialmente habilitar sesiones de terminal.

### Proxy, solo Postgres

Si crea solicitudes de acceso temporal, puede, en lugar de usar la interfaz web, ejecutar sus consultas a través de un proxy gestionado por kviklet y usar el cliente de base de datos de su elección.
Para esto, el contenedor utiliza los puertos 5438-6000, por lo que necesita exponerlos.
El usuario puede entonces crear una solicitud de acceso temporal, y hacer clic en "Iniciar proxy" una vez que haya sido aprobada. Cada solicitud obtendrá un puerto y un usuario + una contraseña temporal. Con esto pueden conectarse a la base de datos. Kviklet valida el usuario temporal y la contraseña y proxy todas las solicitudes al usuario subyacente en la base de datos. Cualquier declaración ejecutada se registra en el registro de auditoría como si se hubiera ejecutado a través de la interfaz web.
Tenga en cuenta que el análisis de mensajes en el lado del proxy no se ha probado con todos los clientes, por lo que si encuentra problemas, por ejemplo, con declaraciones que no se registran, no dude en abrir un issue.

![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 Postgres - TLS

Kviklet termina la conexión TLS a la base de datos. Eso significa que, por defecto, cualquier tráfico hacia y desde el propio proxy no está cifrado.  
Si desea que kviklet vuelva a cifrar el tráfico, puede proporcionarle un certificado TLS y una clave para el proxy configurando las siguientes variables de entorno:```
PROXY_TLS_CERTIFICATE_SOURCE=env
PROXY_TLS_CERTIFICATE_CERT=your-certificate
PROXY_TLS_CERTIFICATE_KEY=your-key

alternativamente puedes usar archivos:``` PROXY_TLS_CERTIFICATE_SOURCE=file PROXY_TLS_CERTIFICATE_CERT_FILE=path/to/cert.pem PROXY_TLS_CERTIFICATE_KEY_FILE=path/to/key.pem

De cualquier manera el certificado y la clave deben almacenarse en [formato pem](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail).

## ¿Preguntas? ¿Contribuciones?

Si tienes alguna pregunta, deseas proporcionar comentarios o necesitas ayuda con la configuración, únete a nuestra [comunidad de Discord](https://discord.gg/7SmPJfeP6e). También puedes crear un [issue en GitHub](https://github.com/kviklet/kviklet/issues) para reportar errores y solicitar funciones.

Si deseas contribuir, no dudes en hacer fork y crear PRs para cosas pequeñas. Si planeas funciones más grandes, agradecería una discusión previa en un issue de GitHub o en Discord.

También puedes contactarme en [email protected].