kviklet v0.9.0
डेटाबेस क्वेरीज़ के लिए पुल रिक्वेस्ट-जैसी समीक्षा/अनुमोदन प्रवाह। अनुपालनपूर्ण लेकिन सहज इंजीनियरिंग पहुँच के लिए उत्पादन में।
Kviklet
Kviklet.dev | रिलीज़ नोट्स | Discord
डेवलपर उत्पादकता को प्रभावित किए बिना प्रोडक्शन एनवायरनमेंट तक सुरक्षित पहुँच।
Kviklet (उच्चारण Quick-let) प्रोडक्शन डेटाबेस एक्सेस पर Four-Eyes Principle लागू करता है, जिसमें व्यक्तिगत SQL स्टेटमेंट या समय-सीमित डेटाबेस सेशन के लिए pull request जैसी समीक्षा और अनुमोदन वर्कफ़्लो होती है। इंजीनियर एक-दूसरे के अनुरोधों की समीक्षा और अनुमोदन कर सकते हैं, बिना हर क्वेरी को किसी DBA या ऑपरेशंस टीम के माध्यम से भेजे।
Kviklet self-hosted है और एप्लिकेशन स्टेट के लिए PostgreSQL डेटाबेस के साथ एक Docker कंटेनर के रूप में चलता है। इसका वेब इंटरफ़ेस आपको अनुरोध सबमिट, समीक्षा और निष्पादित करने देता है। एक वैकल्पिक एंटरप्राइज़ लाइसेंस SAML प्रमाणीकरण, भूमिका-आधारित समीक्षा आवश्यकताएँ, भूमिका सिंक और API कुंजियाँ अनलॉक करता है। एंटरप्राइज़ लाइसेंस के लिए kviklet.dev पर अनुरोध करें।
समर्थित डेटाबेस हैं Postgres, MySQL, MariaDB, MS SQL Server और MongoDB।
एक्सेस मॉडल
हम Kviklet को आपके मौजूदा आइडेंटिटी प्रोवाइडर से कनेक्ट करने की सलाह देते हैं। Kviklet OIDC (Google, Keycloak, आदि) या SAML (केवल एंटरप्राइज़) के माध्यम से SSO, साथ ही LDAP प्रमाणीकरण (Active Directory, आदि) का समर्थन करता है।
इसके बाद उपयोगकर्ता connections के लिए requests बनाते हैं जो किसी विशिष्ट डेटाबेस उपयोगकर्ता से मैप होते हैं। ये अनुरोध या तो होते हैं:
- Single Query: समीक्षा के लिए सबमिट किया गया एक विशिष्ट SQL स्टेटमेंट।
- Temporary Access: एक समय-सीमित सेशन जिसमें आप कई स्टेटमेंट चला सकते हैं।
कॉन्फ़िगरेशन के आधार पर, Kviklet के निष्पादन की अनुमति देने से पहले अनुरोधों की समीक्षा और अनुमोदन अन्य उपयोगकर्ताओं द्वारा किया जाता है।
Kviklet उपयोगकर्ता की ओर से डेटाबेस से कनेक्ट होता है। कनेक्शन का डेटाबेस पासवर्ड उपयोगकर्ता को कभी नहीं दिखाया जाता।
एक एडमिन कॉन्फ़िगर कर सकता है कि किस भूमिका की किस कनेक्शन तक पहुँच है और निष्पादन के लिए कौन से समीक्षा गेट आवश्यक हैं। डेटाबेस-स्तरीय पहुँच अंतर्निहित डेटाबेस के RBAC तंत्रों के माध्यम से प्रबंधित की जाती है। उदाहरण के लिए, read-only कनेक्शन के लिए read-only भूमिका बनाना और उसके लिए write कनेक्शन की तुलना में कम समीक्षा आवश्यकताएँ निर्दिष्ट करना संभव है।
Kviklet निष्पादित स्टेटमेंट रिकॉर्ड करता है और उन्हें उपयोगकर्ता और एक्सेस अनुरोध से संबद्ध करता है। मैन्युअल डेटाबेस एक्सेस की पूर्ण कवरेज के लिए, सीधे कनेक्शन प्रतिबंधित करें और किसी भी मैन्युअल एक्सेस को Kviklet के माध्यम से रूट करें। इंजीनियरों को अंतर्निहित डेटाबेस क्रेडेंशियल प्राप्त या साझा करने की आवश्यकता नहीं है।
अतिरिक्त एंटरप्राइज़ सुविधाओं में शामिल हैं:
- SAML: SAML प्रमाणीकरण के लिए समर्थन।
- Proxy (Postgres, MariaDB, MySQL): अस्थायी पासवर्ड के साथ अनुमोदित temporary-access सेशन के माध्यम से अपने पसंदीदा डेटाबेस क्लाइंट का उपयोग करें। निष्पादित स्टेटमेंट Kviklet के ऑडिट लॉग में रिकॉर्ड किए जाते हैं।
- Role-Based Review Gates: निष्पादन से पहले विशिष्ट भूमिकाओं से अनुमोदन आवश्यक करें।
- Role Sync: आपके आइडेंटिटी प्रोवाइडर समूहों से उपयोगकर्ता भूमिकाओं को स्वचालित रूप से सिंक करें।
- API Keys: Kviklet API तक प्रोग्रामेटिक पहुँच।
अधिक स्क्रीनशॉट
Requests
सभी डेटा अनुरोध एक ही स्थान पर रहते हैं। आपके प्रोडक्शन डेटाबेस के लिए खुले PR की तरह:
Live Sessions
एक अनुमोदित temporary access अनुरोध सीधे ब्राउज़र में एक लाइव SQL सेशन खोलता है:
Audit log
प्रत्येक निष्पादित स्टेटमेंट रिकॉर्ड किया जाता है — चाहे वह समीक्षित single query के रूप में चला हो, लाइव सेशन में, या डेटाबेस proxy के माध्यम से:
डेटाबेस/कनेक्शन प्रकार के अनुसार सुविधा
अधिकांश सुविधाएँ सभी डेटाबेस के लिए उपलब्ध हैं (SSO, LDAP, RBAC, Review/Approval Flow, audit log, आदि)। लेकिन कुछ सुविधाएँ प्रतिबंधित हैं, या तो इसलिए कि वे अभी तक बनाई नहीं गई हैं या क्योंकि वे उस विशिष्ट उद्देश्य के लिए उपयुक्त नहीं हैं। निम्न तालिका दिखाती है कि कौन सी सुविधाएँ किस डेटाबेस प्रकार के लिए उपलब्ध हैं:
| Database | Statement Review | Temporary Access | Proxy(Beta) | Explain Plan |
|---|---|---|---|---|
| Postgres | ✓ | ✓ | ✓ | ✓ |
| MySQL | ✓ | ✓ | ✓ | ✓ |
| MariaDB | ✓ | ✓ | ✓ | ✓ |
| SQL Server | ✓ | ✓ | ✗ | ✓ |
| MongoDB | ✓ | ✓ | ✗ | ✗ |
| Kubernetes | ✓ | ✗ | ✗ | ✗ |
सेटअप
Kviklet एक साधारण docker कंटेनर के रूप में उपलब्ध है।
आप उपलब्ध संस्करण Releases के अंतर्गत पा सकते हैं। हम आपके द्वारा उपयोग किए जा रहे संस्करण को नियमित रूप से अपडेट करने की सलाह देते हैं क्योंकि हम नई सुविधाएँ बनाना जारी रखते हैं।
वर्तमान में नवीनतम ghcr.io/kviklet/kviklet:0.8.0 है, आप :main भी उपयोग कर सकते हैं लेकिन कभी-कभी ऐसा हो सकता है कि हम गलती से कुछ बगी मर्ज कर दें। हालाँकि हम इससे बचने की कोशिश करते हैं।
त्वरित शुरुआत
यदि आप बस यह आज़माना चाहते हैं कि यह कैसे काम करता है:
-
यहाँ एक न्यूनतम docker-compose.yaml है:
compose सामग्री विस्तारित करने के लिए क्लिक करें
``` services: postgres: image: postgres:16 restart: always environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: postgres ports: - "5432:5432" volumes: - ./postgres-data:/var/lib/postgresql/data # - ./sample_data.sql:/docker-entrypoint-initdb.d/init.sqlkviklet-postgres: image: postgres:16 restart: always environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: kviklet ports: - "5433:5432" volumes: - ./kviklet-postgres-data:/var/lib/postgresql/data
kviklet: image: ghcr.io/kviklet/kviklet:main ports: - "80:8080" environment: - SPRING_DATASOURCE_URL=jdbc:postgresql://kviklet-postgres:5432/kviklet - SPRING_DATASOURCE_USERNAME=postgres - SPRING_DATASOURCE_PASSWORD=postgres - INITIAL_USER_EMAIL=[email protected] - INITIAL_USER_PASSWORD=admin depends_on: - kviklet-postgres
-
docker-compose.ymlकोdocker-compose up -dके माध्यम से चलाएँ। Kviklet पोर्ट 80 पर शुरू हो जाएगा,localhostपर जाएँ और इसे आज़माएँ। एडमिन लॉगिन [email protected] है और पासवर्डadminहै। -
docker-compose में एक अतिरिक्त postgres डेटाबेस शामिल है जिसके लिए आप Kviklet में कनेक्शन सेटअप कर सकते हैं। इस डेटाबेस में कुछ डेटा डालने के लिए, इस पंक्ति को अनकमेंट करें: ``` - ./sample_data.sql:/docker-entrypoint-initdb.d/init.sql
और एक sample_data.sql फ़ाइल बनाएँ:
sample_data.sql सामग्री का विस्तार करने के लिए क्लिक करें
```sql CREATE TABLE Locations ( Name VARCHAR(100) NOT NULL, Address VARCHAR(255) NOT NULL, City VARCHAR(100) NOT NULL, Country VARCHAR(100) NOT NULL, PostalCode VARCHAR(20) NOT NULL );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>
### DB सेटअप
Kviklet को queries, connections, approvals, आदि के बारे में metadata सहेजने के लिए अपने स्वयं के postgres database (या कम से कम schema) की आवश्यकता होती है।
आप उनकी आधिकारिक image यहाँ पा सकते हैं: https://hub.docker.com/_/postgres, या अपने पसंदीदा cloud provider द्वारा प्रदान किए गए cloud hosted version का उपयोग कर सकते हैं।
kviklet container शुरू करते समय आपको इन तीन environment variables को तदनुसार सेट करना होगा:```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]
वैकल्पिक प्रमाणीकरण विधियाँ
- IAM Auth:
डेटाबेस कनेक्शन के लिए AWS IAM Auth का उपयोग करना संभव है, इस स्थिति में आप बस पासवर्ड छोड़ देते हैं और केवल उपयोगकर्ता नाम सेट करते हैं।
आपको env var भी सेट करना होगा: ```
SPRING_DATASOURCE_IAMAUTH=true
Kviklet क्रेडेंशियल्स को सामान्य स्थानों (env vars, instance roles, आदि) से लोड करेगा और कनेक्शन के लिए एक टोकन जनरेट करेगा।
- प्रमाणपत्र: आप db कनेक्शन के लिए प्रमाणपत्र भी उपयोग कर सकते हैं, उदाहरण के लिए यहाँ देखें।
प्रारंभिक उपयोगकर्ता
कॉन्फ़िगरेशन उद्देश्यों के लिए आपको एक प्रारंभिक एडमिन उपयोगकर्ता की आवश्यकता होगी। इसके लिए इन 2 env variables को सेट करें:
INITIAL_USER_EMAIL और INITIAL_USER_PASSWORD ताकि आप वेब इंटरफ़ेस में लॉगिन कर सकें। आप बाद में UI के माध्यम से पासवर्ड बदल सकते हैं।
उदाहरण:```
INITIAL_USER_EMAIL=[email protected]
INITIAL_USER_PASSWORD=someverysecurepassword
हम अभी के लिए अपने कंटेनर GitHub packages पर प्रकाशित करते हैं, इसलिए इन सभी सेटिंग्स के साथ आप `ghcr.io/kviklet/kviklet:main` चला सकते हैं, पोर्ट `8080` को मैप करना न भूलें जो Kviklet के डिफ़ॉल्ट पोर्ट पर शुरू होता है।
एक उदाहरण docker run कुछ इस तरह दिख सकता है:```
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
OIDC / OAuth2 के माध्यम से SSO
यदि आप अपने Kviklet इंस्टेंस के लिए SSO सेटअप करना चाहते हैं (जो बहुत समझदारी भरा है क्योंकि अन्यथा आपको फिर से पासवर्ड प्रबंधित करने पड़ेंगे)। आपको इन 3 एनवायरनमेंट वेरिएबल्स को सेटअप करना होगा:``` KVIKLET_IDENTITYPROVIDER_CLIENTID KVIKLET_IDENTITYPROVIDER_CLIENTSECRET KVIKLET_IDENTITYPROVIDER_TYPE=google
The google client id और secret आप google के निर्देशों का पालन करके आसानी से प्राप्त कर सकते हैं:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid
मान्य redirect URIs के लिए, आपको कॉन्फ़िगर करना चाहिए: https://[kviklet_host]/api/login/oauth2/code/google
Allowed Origins के लिए, बस आपका होस्ट किया गया kviklet url।
उन environment variables को सेट करने के बाद आपके संगठन में हर कोई sign in with google बटन से लॉगिन कर सकता है। लेकिन डिफ़ॉल्ट रूप से उनके पास कोई permissions नहीं होंगी, एक बार लॉगिन करने के बाद आपको उन्हें एक role असाइन करना होगा।
#### Keycloak
अगर आप इसके बजाय Keycloak के साथ SSO सेटअप करना चाहते हैं तो आपको ये 4 environment variables सेट करने होंगे:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]
आप Keycloak में एक एप्लिकेशन बनाते समय client id और secret प्राप्त करते हैं। वैध redirect URIs के लिए, आपको कॉन्फ़िगर करना चाहिए: https://[kviklet_host]/api/login/oauth2/code/keycloak Allowed Origins के लिए, बस अपना होस्ट किया गया kviklet url।
उन environment variables को सेट करने के बाद लॉगिन पेज पर एक Login with Keycloak बटन दिखना चाहिए जो आपके keycloak instance पर redirect करता है। enterprise edition में आप role sync को सक्षम कर सकते हैं ताकि आपके keycloak instance से kviklet में roles स्वचालित रूप से sync हो जाएं। अधिक जानकारी के लिए Role Sync अनुभाग देखें।
GitHub (Beta)
Beta: GitHub authentication नया है और अभी role sync का समर्थन नहीं करता — प्रत्येक नया उपयोगकर्ता default role के साथ आता है और उसे मैन्युअल रूप से roles असाइन करने होंगे।
GitHub OIDC-अनुरूप नहीं है (यह शुद्ध OAuth 2.0 है), इसलिए Kviklet में इसका समर्पित समर्थन है। ये environment variables सेट करें:``` KVIKLET_IDENTITYPROVIDER_CLIENTID KVIKLET_IDENTITYPROVIDER_CLIENTSECRET KVIKLET_IDENTITYPROVIDER_TYPE=github KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS=your-org,another-org
https://github.com/settings/developers पर एक GitHub OAuth App बनाएं और कॉन्फ़िगर करें:
- Authorization callback URL: `https://[kviklet_host]/api/login/oauth2/code/github`
- Homepage URL: आपका होस्ट किया गया Kviklet URL
`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` **आवश्यक** है (इसके बिना Kviklet शुरू होने से इनकार कर देता है)। GitHub OAuth Apps यह प्रतिबंधित नहीं कर सकते कि कौन OAuth फ़्लो पूरा करता है, इसलिए Kviklet प्रमाणीकरण के बाद `/user/orgs` को कॉल करता है और उन उपयोगकर्ताओं को अस्वीकार कर देता है जो कम से कम एक allowlisted org के सदस्य नहीं हैं (case-insensitive, पहले 100 orgs की जाँच की जाती है)।
org जाँच को किसी उपयोगकर्ता की सदस्यता देखने के लिए, उपयोगकर्ता को OAuth सहमति स्क्रीन पर प्रत्येक allowlisted org के बगल में **Grant** (या **Request**) पर क्लिक करना होगा। यदि org में "Restrict third-party OAuth applications" सक्षम है, तो किसी भी सदस्य की सदस्यता दिखाई देने से पहले एक org owner को भी एक बार OAuth app को स्वीकृत करना होगा।
Kviklet `read:user`, `user:email` और `read:org` scopes का अनुरोध करता है। ईमेल हमेशा `/user/emails` से पढ़े जाते हैं और केवल एक `primary && verified` प्रविष्टि स्वीकार की जाती है, इसलिए निजी ईमेल पतों वाले उपयोगकर्ता भी सफलतापूर्वक लॉग इन करते हैं।
#### अन्य OIDC प्रदाता
अन्य OIDC-अनुरूप प्रदाता (GitLab, Auth0, Okta, आदि) Keycloak के समान काम करने चाहिए। ध्यान दें कि आपके द्वारा चुने गए प्रकार के आधार पर `redirect URI` बदल जाएगा, इसलिए यदि आप `gitlab` चुनते हैं तो यह `https://[kviklet_host]/api/login/oauth2/code/gitlab` होगा।
यदि आपको कोई समस्या आती है तो बेझिझक एक issue बनाएं, हमने अभी तक हर एक OIDC प्रदाता को आज़माया नहीं है और implementation में मामूली अंतर हो सकते हैं जिनके लिए Kviklet की ओर से अपडेट की आवश्यकता हो सकती है।
### LDAP
Kviklet LDAP प्रमाणीकरण का समर्थन करता है। LDAP को सक्षम और कॉन्फ़िगर करने के लिए, आप निम्नलिखित environment variables को override कर सकते हैं:```
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
प्रत्येक सेटिंग का अर्थ यहाँ दिया गया है:
LDAP_ENABLED: LDAP प्रमाणीकरण सक्षम करने के लिए इसेtrueपर सेट करें।LDAP_URL: आपके LDAP सर्वर का URL।LDAP_BASE: LDAP खोजों के लिए आधार DN।LDAP_PRINCIPAL: LDAP सर्वर से बाइंड करने के लिए एडमिन उपयोगकर्ता का DN।LDAP_PASSWORD: एडमिन उपयोगकर्ता का पासवर्ड।LDAP_UNIQUE_IDENTIFIER_ATTRIBUTE: उपयोगकर्ताओं के लिए विशिष्ट पहचानकर्ता के रूप में उपयोग किया जाने वाला LDAP एट्रिब्यूट (डिफ़ॉल्ट: "uid")।LDAP_EMAIL_ATTRIBUTE: वह LDAP एट्रिब्यूट जिसमें उपयोगकर्ता का ईमेल पता होता है (डिफ़ॉल्ट: "mail")।LDAP_FULL_NAME_ATTRIBUTE: वह LDAP एट्रिब्यूट जिसमें उपयोगकर्ता का पूरा नाम होता है (डिफ़ॉल्ट: "cn")।LDAP_USER_OU: वह Organizational Unit (OU) जहाँ उपयोगकर्ता खाते संग्रहीत होते हैं (डिफ़ॉल्ट: "people")।LDAP_SEARCH_BASE: उपयोगकर्ता खोजों के लिए आधार DN को ओवरराइड करने की अनुमति देता है (डिफ़ॉल्ट: "ou=people")। यदि आप FreeIPA का उपयोग करते हैं तो आपको इसे उदाहरण के लिएcn=usersपर सेट करने की आवश्यकता हो सकती है। यदि सेट किया जाता है तो LDAP_USER_OU को अनदेखा कर दिया जाता है।
आप अपने LDAP स्कीमा से मेल खाने के लिए इन एट्रिब्यूट्स को अनुकूलित कर सकते हैं। LDAP कॉन्फ़िगर करने के बाद, उपयोगकर्ता अपने LDAP क्रेडेंशियल्स का उपयोग करके लॉग इन कर सकेंगे। पहली बार जब कोई LDAP उपयोगकर्ता लॉग इन करता है, तो Kviklet में डिफ़ॉल्ट अनुमतियों के साथ एक संबंधित उपयोगकर्ता खाता बनाया जाएगा। इन उपयोगकर्ताओं के पहले लॉगिन के बाद एक एडमिन को उन्हें उपयुक्त भूमिकाएँ सौंपनी होंगी।
SAML (केवल एंटरप्राइज़)
Kviklet SAML 2.0 प्रमाणीकरण का समर्थन करता है। SAML सक्षम करने के लिए, निम्नलिखित एनवायरनमेंट वेरिएबल्स सेट करें:``` 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-----
कॉन्फ़िगरेशन विवरण:
- `SAML_ENABLED`: SAML प्रमाणीकरण सक्षम करने के लिए `true` पर सेट करें
- `SAML_ENTITYID`: आपके SAML पहचान प्रदाता की एंटिटी ID
- `SAML_SSOSERVICELOCATION`: आपके पहचान प्रदाता का SSO सेवा URL
- `SAML_VERIFICATIONCERTIFICATE`: SAML प्रतिक्रियाओं को सत्यापित करने के लिए उपयोग किया जाने वाला X.509 प्रमाणपत्र (BEGIN/END CERTIFICATE पंक्तियाँ शामिल करें)
आप वैकल्पिक रूप से SAML एट्रिब्यूट मैपिंग को अनुकूलित कर सकते हैं:```
SAML_USERATTRIBUTES_EMAILATTRIBUTE=email
SAML_USERATTRIBUTES_NAMEATTRIBUTE=name
SAML_USERATTRIBUTES_IDATTRIBUTE=nameID
आपके identity provider को इस प्रकार कॉन्फ़िगर किया जाना चाहिए:
- Entity ID:
https://[kviklet_host]/api/saml2/service-provider-metadata/saml - Redirect Uri:
https://[kviklet_host]/api/login/saml2/sso/saml
SAML कॉन्फ़िगर करने के बाद, उपयोगकर्ता identity provider के माध्यम से लॉग इन कर सकते हैं। पहली बार लॉग इन करने पर, डिफ़ॉल्ट अनुमतियों के साथ एक उपयोगकर्ता खाता बनाया जाता है।
यदि आप सही ढंग से IDP पर रीडायरेक्ट हो जाते हैं लेकिन फिर cors error प्राप्त होता है, तो आप Kviklet में अपने IDP के host को allowed origins में इस प्रकार जोड़ सकते हैं:``` CORS_ALLOWEDORIGINS=https://[idp_host]
## कॉन्फ़िगरेशन
### कनेक्शन
Kviklet शुरू करने के बाद आपको पहले एक डेटाबेस कनेक्शन कॉन्फ़िगर करना होगा। Settings -> Databases -> Add Connection पर जाएं।
यहां आप प्रत्येक कनेक्शन के लिए समीक्षा आवश्यकताओं और निष्पादन सीमाओं को कॉन्फ़िगर कर सकते हैं। विवरण के लिए [Review Gates](#review-gates) देखें।
#### AWS IAM AUTH
Kviklet Postgres, MySQL और MariaDB डेटाबेस कनेक्शन के लिए IAM Auth का उपयोग करने का समर्थन करता है, इसके लिए नया कनेक्शन बनाते समय IAM Auth चुनें।
यह पासवर्ड सेट करने का विकल्प हटा देगा और इसके बजाय डेटाबेस से कनेक्ट करने के लिए AWS क्रेडेंशियल्स का उपयोग करेगा।
Kviklet क्रेडेंशियल्स खोजने और कनेक्शन के लिए टोकन उत्पन्न करने के लिए AWS के `DefaultCredentialsProvider` का उपयोग करता है। इसका मतलब है कि सभी सामान्य स्थानों पर काम करना चाहिए (env vars या संबद्ध instance roles), सटीक क्रम यहां प्रलेखित है: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html
इसके अतिरिक्त, आप एक AWS role ARN प्रदान कर सकते हैं जिसे Kviklet assume करेगा, और उन क्रेडेंशियल्स का उपयोग अस्थायी DB टोकन बनाने के लिए करेगा। यह उन डेटाबेस से कनेक्ट करने के लिए विशेष रूप से उपयोगी है जो Kviklet के समान AWS खाते में नहीं हैं। इस सुविधा का उपयोग करने के लिए, IAM Auth कनेक्शन बनाते या संपादित करते समय निर्दिष्ट फ़ील्ड में role ARN दर्ज करें। फ़ील्ड को खाली छोड़ने पर डिफ़ॉल्ट क्रेडेंशियल्स प्रदाता का उपयोग होगा (कोई role assumption नहीं)।
टोकन जनरेशन के दौरान उपयोग किया जाने वाला AWS क्षेत्र आपके कनेक्शन URL से अनुमानित किया जाता है इसलिए इसे सेट करने का कोई विकल्प नहीं है।
अपने डेटाबेस के लिए IAM Auth सेटअप करना सीखने के लिए आधिकारिक AWS दस्तावेज़ का पालन करें: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
मुख्य दो बिंदु हैं:
- IAM auth विकल्प और सही अनुमतियों के साथ एक DB उपयोगकर्ता बनाएं
- एक IAM नीति बनाएं जो AWS इकाई को इस उपयोगकर्ता के लिए टोकन उत्पन्न करने की अनुमति देती है
### Review Gates
डिफ़ॉल्ट रूप से Kviklet एक सरल समीक्षा गणना कॉन्फ़िगरेशन की अनुमति देता है। आप कॉन्फ़िगर कर सकते हैं कि किसी विशिष्ट कनेक्शन पर अनुरोधों को निष्पादित करने से पहले कितने अनुमोदनों की आवश्यकता है।
किसी अनुरोध की अनुमोदन स्थिति प्रत्येक समीक्षक की नवीनतम कार्रवाई के आधार पर गणना की जाती है। यदि कोई समीक्षक अनुमोदन करता है और बाद में परिवर्तन का अनुरोध करता है, तो केवल परिवर्तन अनुरोध गिना जाता है — उनका पहले का अनुमोदन हटा दिया जाता है। किसी अनुरोध को संपादित करना हमेशा सभी पूर्व अनुमोदनों को रीसेट करता है, यह सुनिश्चित करते हुए कि कोई भी परिवर्तन पहले समीक्षा किए बिना निष्पादित नहीं किया जा सकता। इसी तरह, यदि कोई निष्पादन विफल हो जाता है (उदाहरण के लिए SQL सिंटैक्स त्रुटि के कारण), तो अनुमोदन रीसेट हो जाते हैं ताकि अनुरोध को ठीक किया जा सके और नया बनाए बिना फिर से अनुमोदित किया जा सके।
आप प्रति कनेक्शन **max executions** सीमा भी कॉन्फ़िगर कर सकते हैं ताकि यह नियंत्रित किया जा सके कि एक अनुमोदित अनुरोध को कितनी बार निष्पादित किया जा सकता है। डिफ़ॉल्ट 1 है। इसे 0 पर सेट करने से असीमित निष्पादन की अनुमति मिलती है। विफल निष्पादन इस सीमा में नहीं गिने जाते।
#### Role-Based Review Requirements (Enterprise)
Kviklet Enterprise License के साथ आप व्यक्तिगत कनेक्शनों को कॉन्फ़िगर कर सकते हैं ताकि विशिष्ट भूमिकाओं वाले उपयोगकर्ताओं से अनुमोदन की आवश्यकता हो। यह आपको उदाहरण के लिए किसी दिए गए डेटाबेस को बनाए रखने वाली टीम से अनुमोदन की आवश्यकता करने या संवेदनशील कनेक्शनों को DBA या प्रबंधन अनुमोदनों के पीछे रखने की अनुमति देता है।
**यह कैसे काम करता है:**
प्रत्येक कनेक्शन में एक **total reviews required** गणना (`numTotalRequired`) होती है जो एक न्यूनतम सीमा के रूप में कार्य करती है — भूमिकाओं की परवाह किए बिना आवश्यक न्यूनतम संख्या में विशिष्ट अनुमोदन। इसके अतिरिक्त आप **role requirements** जोड़ सकते हैं जो निर्दिष्ट करती हैं कि किसी विशेष भूमिका वाले उपयोगकर्ताओं से कितने अनुमोदन आने चाहिए (उदाहरण के लिए, "DBA से 1, Security से 1")।
एक अनुरोध तभी अनुमोदित होता है जब **दोनों** शर्तें पूरी हों:
- विशिष्ट अनुमोदनों की कुल संख्या `numTotalRequired` को पूरा करती हो
- प्रत्येक role requirement व्यक्तिगत रूप से संतुष्ट हो
यदि कोई उपयोगकर्ता कई भूमिकाओं से संबंधित है, तो उस उपयोगकर्ता से एक अनुमोदन सभी मेल खाने वाली role requirements की ओर गिना जाता है। हालांकि, यह कुल गणना की ओर अभी भी केवल एक अनुमोदन के रूप में गिना जाता है।
**उदाहरण:** एक कनेक्शन को 3 कुल अनुमोदनों की आवश्यकता है जिसमें DBA से 1 और Security से 1 शामिल है। एक उपयोगकर्ता जिसके पास DBA और Security दोनों भूमिकाएं हैं, अनुमोदन करता है — यह दोनों role requirements को संतुष्ट करता है लेकिन आवश्यक 3 कुल अनुमोदनों में से केवल 1 के रूप में गिना जाता है। किसी भी उपयोगकर्ता से दो और अनुमोदन अभी भी आवश्यक हैं।
यदि आपका enterprise license समाप्त हो जाता है, तो मौजूदा role-based review requirements लागू रहती हैं लेकिन उन्हें संशोधित नहीं किया जा सकता। आप सरल total reviews कॉन्फ़िगरेशन पर वापस जाने के लिए उन्हें केवल हटा सकते हैं।
### Roles
Kviklet 3 भूमिकाओं के साथ आता है, Default, Admins और Developers।
- डिफ़ॉल्ट भूमिका सभी कनेक्शनों और Requests तक Read पहुंच प्रदान करती है। यह भूमिका प्रत्येक उपयोगकर्ता को सौंपी जाती है और इसे हटाया नहीं जा सकता। हालांकि आप इस भूमिका की अनुमतियों को अपनी इच्छानुसार बदल सकते हैं।
- Admins के पास कनेक्शन बनाने और संपादित करने, साथ ही नए Users जोड़ने और उनकी अनुमतियां सेट करने की अनुमति होती है।
- Developers Requests बना सकते हैं और साथ ही उन्हें अनुमोदित और टिप्पणी कर सकते हैं और निश्चित रूप से वास्तविक statements निष्पादित कर सकते हैं।
आप Roles को अनुकूलित कर सकते हैं और उदाहरण के लिए किसी भूमिका को केवल एक विशिष्ट कनेक्शन या DB कनेक्शनों के समूह तक पहुंच दे सकते हैं।
यह उपयोगी है उदाहरण के लिए यदि आपके पास अलग-अलग डेटाबेस वाली अलग-अलग टीमें हैं और आप उन तक पहुंच को अधिक सूक्ष्मता से नियंत्रित करना चाहते हैं।
#### नई Role बनाना
नई role बनाना इस प्रकार काम करता है। Settings -> Roles -> Add Role पर जाएं।
डिफ़ॉल्ट सेटिंग्स अधिकांश भूमिकाओं के लिए उतनी प्रासंगिक नहीं हैं और आप बस User Read और RoleView Access दे सकते हैं और उसे वहीं छोड़ सकते हैं।
अधिक रोचक है Connections के लिए व्यक्तिगत अनुमतियां जोड़ना। यहां आप पहले विशिष्ट कनेक्शनों का चयन करने के लिए एक selector जोड़ते हैं। यह या तो एक विशिष्ट id हो सकता है या आप कई कनेक्शनों से मिलान करने के लिए `*` के साथ wildcards का उपयोग करते हैं। उदाहरण के लिए यदि आप एक ऐसी role चाहते हैं जिसके पास सभी dev डेटाबेस तक पहुंच हो (यदि आप kviklet के साथ उन तक पहुंच भी प्रबंधित करते हैं) तो आप `dev-*` जैसा selector उपयोग करेंगे और सुनिश्चित करेंगे कि कनेक्शनों की ids सही ढंग से सेट हैं।
आप निश्चित रूप से अपने संगठन के भीतर अपनी विभिन्न टीमों के लिए उपयोग किए जाने वाला एक सिस्टम भी बना सकते हैं।
### Role Sync (Enterprise)
अपने identity provider groups से उपयोगकर्ता भूमिकाओं को स्वचालित रूप से सिंक करें। इस सुविधा के लिए enterprise license आवश्यक है।
**कॉन्फ़िगरेशन** Settings > Role Sync में किया जाता है:
- **Enable Role Sync**: सिंक्रोनाइज़ेशन चालू/बंद करें
- **Sync Mode**:
- **Full Sync** - उपयोगकर्ता भूमिकाएं उनके IdP group mappings से बिल्कुल मेल खाती हैं (साथ ही डिफ़ॉल्ट role)
- **Additive** - IdP groups भूमिकाएं जोड़ते हैं लेकिन मौजूदा को हटाते नहीं हैं
- **First Login Only** - भूमिकाएं केवल पहले लॉगिन पर सिंक होती हैं, मैन्युअल परिवर्तन बाद में संरक्षित रहते हैं
- **Groups Attribute**: group memberships वाला IdP attribute (डिफ़ॉल्ट: `groups`)
- **Role Mappings**: IdP group नामों (उदाहरण के लिए, `engineering`) को Kviklet भूमिकाओं से मैप करें
#### OIDC Setup
अपने OIDC provider को ID token में `groups` claim शामिल करने के लिए कॉन्फ़िगर करें:
- **Keycloak**:
Keycloak डिफ़ॉल्ट रूप से tokens में groups शामिल नहीं करता इसलिए आपको client में एक mapper जोड़ना होगा।
1. बाएं मेनू में **Clients** पर जाएं
2. अपना Kviklet client चुनें
3. **Client scopes** टैब पर जाएं
4. समर्पित scope पर क्लिक करें (उदाहरण के लिए, `kviklet-dedicated`)
5. **Mappers** टैब पर जाएं
6. **Add mapper** → **By configuration** पर क्लिक करें
7. **Group Membership** चुनें
8. 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. **Save** पर क्लिक करें
> **महत्वपूर्ण:** "Token Claim Name" को Kviklet की Role Sync सेटिंग्स में कॉन्फ़िगर किए गए "Groups Attribute" से मेल खाना चाहिए (डिफ़ॉल्ट: `groups`)।
- **अन्य OIDC providers**: एक groups mapper/claim जोड़ें जो ID token में उपयोगकर्ता की group memberships शामिल करता हो। यह आमतौर पर provider के admin UI में किया जाता है।
यदि आपको कोई समस्या आती है तो बेझिझक एक issue बनाएं, हमने अभी तक हर एक OIDC provider को आज़माया नहीं है और implementation में मामूली अंतर हो सकते हैं जिनके लिए Kviklet की ओर से अपडेट की आवश्यकता हो सकती है।
#### LDAP Setup
LDAP role sync `memberOf` attribute का उपयोग करता है:
1. सुनिश्चित करें कि आपके LDAP सर्वर में `memberOf` overlay सक्षम है
2. Kviklet में **Groups Attribute** को `memberOf` पर सेट करें
3. Group नाम तब उपयोगकर्ता attributes में `memberOf` attribute से निकाले जाते हैं।
#### SAML Setup
अपने SAML IdP को assertion में groups शामिल करने के लिए कॉन्फ़िगर करें:
1. एक attribute statement जोड़ें जो उपयोगकर्ता group memberships को मैप करता हो
2. Kviklet में **Groups Attribute** को अपने SAML attribute नाम से मेल खाने के लिए सेट करें
3. Group नाम तब उपयोगकर्ता attributes में SAML attribute से निकाले जाते हैं।
### Notifications
आप Kviklet को Slack या Teams में एक चैनल पर सूचनाएं भेजने के लिए कॉन्फ़िगर कर सकते हैं। यह आपकी टीम को उन नए अनुरोधों के बारे में सूचित करने के लिए उपयोगी है जिनकी समीक्षा की आवश्यकता है। आप इसे Settings -> General -> Notification Settings में कॉन्फ़िगर कर सकते हैं।
#### Slack
Slack सूचनाओं को कॉन्फ़िगर करने के लिए आपको एक Slack App बनाना होगा और उसके लिए webhooks सक्षम करने होंगे। आप यहां दिए गए निर्देशों का पालन कर सकते हैं: https://api.slack.com/messaging/webhooks
#### Teams
Teams सूचनाएं Power Automate **Workflow** webhook का उपयोग करती हैं। Kviklet एक Adaptive Card भेजता है, जिसे webhook template आपके चैनल पर पोस्ट करता है।
**अनुशंसित: workflow template का उपयोग करें**
1. Teams में, वह चैनल खोलें जिसमें आप सूचनाएं चाहते हैं, चैनल नाम के बगल में **...** पर क्लिक करें और **Workflows** चुनें (या **Workflows** ऐप जोड़ें)।
2. **"Send webhook alerts to a channel"** template को खोजें और बनाएं।
3. संकेत मिलने पर साइन इन करें, फिर लक्ष्य Team और Channel चुनें और workflow बनाएं।
4. trigger step खोलें और उत्पन्न **HTTP POST URL** कॉपी करें।
5. URL को Kviklet में Settings -> General -> Notification Settings के अंतर्गत पेस्ट करें और save पर क्लिक करें।
**वैकल्पिक: workflow मैन्युअल रूप से बनाएं**
यदि आप flow स्वयं बनाना पसंद करते हैं (या template उपलब्ध नहीं है):
1. Channel **...** -> **Workflows** -> **"When a Teams webhook request is received"** trigger के साथ एक flow बनाएं।
2. **Microsoft Teams -> "Post card in a chat or channel"** action जोड़ें।
3. action के **Adaptive Card** फ़ील्ड को expression `string(triggerBody())` पर सेट करें ताकि यह Kviklet द्वारा भेजा गया card पोस्ट करे।
4. लक्ष्य Team और Channel चुनें, **Save** करें, फिर trigger step से **HTTP POST URL** कॉपी करें।
वर्तमान में इनके लिए सूचनाएं हैं:
- नए Requests, जिन्हें अनुमोदन की आवश्यकता है
- requests पर नए अनुमोदन
#### Base URL Configuration
जब Kviklet को reverse proxy या Kubernetes Ingress के पीछे चलाया जाता है, तो notification links आपके सार्वजनिक डोमेन के बजाय आंतरिक IP पते का उपयोग कर सकते हैं। Kviklet आने वाले अनुरोधों को देखकर सही URL को ट्रैक करने का प्रयास करता है लेकिन कुछ reverse proxies Forwarded headers को सही ढंग से सेट नहीं करते। इसे ठीक करने के लिए, base URL को स्पष्ट रूप से सेट करें:```
KVIKLET_BASE_URL=https://kviklet.example.com
यह सुनिश्चित करता है कि सभी नोटिफिकेशन लिंक सही सार्वजनिक URL की ओर इंगित करें।
टेलीमेट्री
Kviklet अनाम उपयोग आंकड़े रिपोर्ट करता है ताकि हमें यह समझने में मदद मिले कि कौन-कौन सी सुविधाएँ उपयोग की जाती हैं और त्रुटियाँ कहाँ होती हैं। इसे बंद करने के लिए, सेट करें:``` KVIKLET_TELEMETRY_ENABLED=false
Kviklet स्टार्टअप पर एक पंक्ति लॉग करता है जिसमें बताया जाता है कि टेलीमेट्री चालू है या नहीं।
**क्या भेजा जाता है।** प्रत्येक इवेंट में एक रैंडम इंस्टेंस आईडी (एक बार जनरेट की जाती है और Kviklet के
डेटाबेस में संग्रहीत की जाती है), वह बेस URL जिस पर Kviklet तक पहुँचा जाता है (ऊपर देखें; अक्सर एक आंतरिक होस्टनेम), और Kviklet
संस्करण शामिल होता है। उपयोगकर्ताओं की पहचान केवल इंस्टेंस तक सीमित एक अपारदर्शी आईडी द्वारा की जाती है, इसलिए अद्वितीय उपयोगकर्ताओं की
गणना की जा सकती है, लेकिन कोई ईमेल पता या नाम कभी नहीं भेजा जाता है। सटीक इवेंट और उनके गुण
`backend/src/main/kotlin/dev/kviklet/kviklet/telemetry/TelemetryEvent.kt` में परिभाषित हैं।
**क्या कभी नहीं भेजा जाता है।** क्वेरीज़, स्टेटमेंट्स, परिणाम, कमांड आउटपुट, त्रुटि संदेश, कनेक्शन
नाम, होस्टनेम, क्रेडेंशियल्स, अनुरोध शीर्षक या विवरण, टिप्पणियाँ, और उपयोगकर्ता या भूमिका नाम।
### लॉगिंग
डिफ़ॉल्ट रूप से Kviklet stdout पर मानव-पठनीय (pretty) लॉग लिखता है, जो उन्हें सीधे या `docker logs` के माध्यम से
पढ़ते समय सुविधाजनक होता है।
यदि आप लॉग को किसी केंद्रीय सिस्टम (Elasticsearch, Loki, Datadog, CloudWatch, …) में भेजते हैं, तो आप
इसके बजाय संरचित **JSON लॉग** पर स्विच कर सकते हैं, जिन्हें इंडेक्स और क्वेरी करना आसान होता है। फ़ॉर्मेट को
एक एनवायरनमेंट वेरिएबल के माध्यम से सेट करें:```
# One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs
एन्क्रिप्शन
यदि आप नहीं चाहते कि क्रेडेंशियल्स DB में cleartext में संग्रहीत हों, तो यह अनुशंसित है कि आप Kviklet postgres DB पर ही database encryption सक्षम करें। अधिकांश hosted providers के लिए यह क्लिक करने योग्य एक साधारण checkbox है। फिर भी, यदि Kviklet database किसी तरह से compromise हो जाता है, तो यह एक बहुत बड़ा security risk है। क्योंकि इसमें संभावित रूप से आपके सभी production datastores के लिए database credentials होते हैं। इसलिए आप credentials की at rest encryption सक्षम कर सकते हैं।
ऐसा करने के लिए बस दो environment variables सेट करें।``` ENCRYPTION_ENABLED=true ENCRYPTION_KEY_CURRENT=some-secret
Kviklet स्टार्टअप पर आपके सभी मौजूदा क्रेडेंशियल्स को एन्क्रिप्ट कर देगा, और भविष्य के कनेक्शन्स के लिए उस सीक्रेट का उपयोग करेगा जो आप बनाते हैं।
### Key Rotation
यदि आप की को रोटेट करना चाहते हैं तो आप पिछली की के लिए बस एक और वेरिएबल जोड़ सकते हैं और वर्तमान वाले को बदल सकते हैं:```
ENCRYPTION_KEY_PREVIOUS=some-secret
ENCRYPTION_KEY_CURRENT=another-secret
Kviklet स्टार्टअप पर सभी कनेक्शनों को फिर से एन्क्रिप्ट कर देगा, ताकि आप बाद में पिछली कुंजी हटाकर कंटेनर को पुनः आरंभ कर सकें।
API Keys
Kviklet सिस्टम तक प्रोग्रामेटिक पहुँच के लिए API keys का समर्थन करता है। यह एक enterprise-only सुविधा है और इसके लिए एक वैध लाइसेंस आवश्यक है। आप Settings -> API Keys अनुभाग में API keys बना सकते हैं।
इसका उपयोग इस प्रकार करें:```bash
curl --location '[kviklet_host]/api/connections/'
--header 'Authorization: Bearer your-api-key'
API Keys उन्हें बनाने वाले उपयोगकर्ता की अनुमतियाँ विरासत में लेते हैं। वर्तमान में केवल एडमिन ही API keys प्रबंधित कर सकते हैं और API key के साथ की गई सभी क्रियाएँ उस उपयोगकर्ता को आरोपित की जाती हैं जिसने key बनाई है।
कुछ बुनियादी API दस्तावेज़ `[kviklet_host]/api/swagger-ui/index.html` पर पाए जा सकते हैं। लेकिन ध्यान रखें कि यह अभी कार्य प्रगति पर है और API भविष्य के संस्करणों में बदल सकती है।
अंत में सत्य कोड में ही है, इसलिए आप API को परिभाषित होते देखने के लिए हमेशा controller को देख सकते हैं। यदि आपके कोई प्रश्न हों तो बेझिझक एक issue खोलें।
## प्रायोगिक सुविधाएँ
वर्तमान में दो प्रायोगिक सुविधाएँ हैं। ये मुख्यतः समुदाय की प्रतिक्रिया पर बनाई गई थीं। इन्हें आज़माने में संकोच न करें और अपना कोई भी इनपुट दें। हमें उम्मीद है कि भविष्य में इन्हें और विकसित करेंगे और मुख्य approval flow के साथ अच्छी तरह काम कराएँगे।
### Kubernetes Exec
यदि आप Kubernetes Exec सुविधा का उपयोग करना चाहते हैं तो आपको एक अलग kubernetes connection बनाना होगा। Kviklet कमांड निष्पादित करने के लिए deployed pod के उपयोगकर्ता का उपयोग करेगा। इसलिए सुनिश्चित करें कि उस उपयोगकर्ता के पास उन pods पर कमांड निष्पादित करने की आवश्यक अनुमतियाँ हैं जिन्हें आप एक्सेस करना चाहते हैं।
Kviklet कमांड निष्पादित करने के लिए /bin/sh का भी उपयोग करता है, इसलिए आपको यह सुनिश्चित करना होगा कि आपके pods में एक shell हो या कम से कम /bin/sh में एक symlink हो। यदि यह आपको परेशान करता है तो बेझिझक एक issue खोलें, हम संभवतः इसे configurable बना सकते हैं या कोई अन्य समाधान खोज सकते हैं।
Kubernetes कमांड आउटपुट के लिए केवल 5 सेकंड प्रतीक्षा करते हैं यदि कमांड उससे अधिक समय लेता है तो Kviklet कमांड को timeout करने से पहले एक घंटे तक प्रतीक्षा करेगा। यह एक अस्थायी समाधान है, हम इसे और अधिक responsive बनाने और संभवतः terminal sessions सक्षम करने के लिए websockets पर विचार कर रहे हैं।
### Proxy - Postgres, MariaDB, MySQL (Enterprise)
यदि आप अस्थायी एक्सेस के लिए अनुरोध बनाते हैं, तो आप - web interface का उपयोग करने के बजाय - kviklet managed proxy के माध्यम से अपनी queries चला सकते हैं और अपनी पसंद का DB client उपयोग कर सकते हैं।
Proxy एक enterprise सुविधा है: इसके लिए एक वैध लाइसेंस आवश्यक है, और एक एडमिन को अतिरिक्त रूप से इसे Settings -> General -> Database Proxy के अंतर्गत चालू करना होगा।
इसके लिए container स्थिर ports पर सुनता है (डिफ़ॉल्ट रूप से 5432 और 3306, `kviklet.proxy.postgres.port` और `kviklet.proxy.mysql.port` के माध्यम से configurable), इसलिए आपको उन ports को expose करना होगा।
उपयोगकर्ता तब एक अस्थायी एक्सेस अनुरोध बना सकते हैं, और approve होने के बाद "Start Proxy" पर क्लिक कर सकते हैं। प्रत्येक अनुरोध को एक अस्थायी username और password मिलता है; Kviklet प्रत्येक connection को username के आधार पर उसके अनुरोध तक route करता है। इनके साथ वे database से connect कर सकते हैं। Kviklet temp user और password को validate करता है और सभी अनुरोधों को database पर underlying user तक proxy करता है। निष्पादित किए गए कोई भी statements audit log में इस तरह लॉग किए जाते हैं जैसे वे web interface के माध्यम से चलाए गए हों।
नोट: Proxy वर्तमान में result tracking का समर्थन नहीं करता। इसलिए निष्पादित statements लॉग किए जाते हैं लेकिन परिणाम नहीं या कि कोई statement सफल होता है या विफल।
#### Proxy - TLS
Kviklet database से TLS connection को terminate करता है। इसका मतलब है कि डिफ़ॉल्ट रूप से proxy से और proxy तक का कोई भी ट्रैफ़िक एन्क्रिप्टेड नहीं है।
यदि आप चाहते हैं कि kviklet ट्रैफ़िक को पुनः एन्क्रिप्ट करे तो आप निम्नलिखित environment variables सेट करके Kviklet को proxy के लिए एक TLS certificate और key दे सकते हैं:```
PROXY_TLS_CERTIFICATE_SOURCE=env
PROXY_TLS_CERTIFICATE_CERT=your-certificate
PROXY_TLS_CERTIFICATE_KEY=your-key
वैकल्पिक रूप से आप फ़ाइलों का उपयोग कर सकते हैं:``` PROXY_TLS_CERTIFICATE_SOURCE=file PROXY_TLS_CERTIFICATE_CERT_FILE=path/to/cert.pem PROXY_TLS_CERTIFICATE_KEY_FILE=path/to/key.pem
या तो प्रमाणपत्र और कुंजी को [pem प्रारूप](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) में संग्रहीत किया जाना चाहिए।
## प्रश्न? योगदान?
यदि आपके कोई प्रश्न हैं, प्रतिक्रिया देना चाहते हैं, या सेटअप में सहायता चाहिए, तो हमारे [Discord समुदाय](https://discord.gg/7SmPJfeP6e) से जुड़ें। आप बग रिपोर्ट और फीचर अनुरोधों के लिए [GitHub issue](https://github.com/kviklet/kviklet/issues) भी बना सकते हैं।
यदि आप योगदान देना चाहते हैं, तो छोटी चीज़ों के लिए बेझिझक fork करें और PR बनाएं। यदि आप बड़े फीचर्स की योजना बना रहे हैं, तो मैं GitHub issue या Discord पर पहले से कुछ चर्चा की सराहना करूंगा।
आप मुझसे [email protected] पर भी संपर्क कर सकते हैं।