Kviklet

उत्पादन वातावरणों तक सुरक्षित पहुंच, डेवलपर उत्पादकता को प्रभावित किए बिना।

Kviklet Kviklet

Kviklet (उच्चारण क्विक-लेट) चार-आँख सिद्धांत और उच्च स्तरीय कॉन्फ़िगरेबिलिटी को अपनाता है ताकि व्यक्तिगत SQL स्टेटमेंट या डेटाबेस सत्रों के लिए पुल रिक्वेस्ट-जैसी समीक्षा और अनुमोदन प्रवाह की अनुमति मिल सके। इससे इंजीनियरिंग टीमें स्वयं नियंत्रित कर सकती हैं कि किसे किस डेटा तक और कब पहुंच मिले, जिससे संगठन आधुनिक, सशक्त और वास्तविक "DevOps" कार्यप्रवाहों को अपनाते हुए सुरक्षित और अनुपालन में रह सकते हैं।

Kviklet एक स्व-होस्टेड डॉकर कंटेनर है, जो आपको एक सिंगल पेज वेब ऐप प्रदान करता है। SQL अनुरोध बनाने या दूसरों के अनुरोधों को अनुमोदित करने के लिए लॉगिन करें। एक वैकल्पिक एंटरप्राइज लाइसेंस SAML प्रमाणीकरण, भूमिका-आधारित समीक्षा आवश्यकताओं, भूमिका सिंक और API कुंजियों जैसी उन्नत सुविधाओं को अनलॉक करता है। आप kviklet.dev पर एंटरप्राइज लाइसेंस का अनुरोध कर सकते हैं।

हम वर्तमान में Postgres, MySQL, MS SQL Server और MongoDB का समर्थन करते हैं।

Features

Kviklet उन सुविधाओं की एक विविधता के साथ आता है जिनकी एक इंजीनियरिंग टीम को अपने उत्पादन डेटाबेस तक पहुंच को सरल लेकिन सुरक्षित तरीके से प्रबंधित करने के लिए आवश्यकता होती है:

SSO (OIDC, Google, Keycloak, आदि): बिना उपयोगकर्ता नाम या पासवर्ड की आवश्यकता के Kviklet में लॉगिन करें। DB पहुंच के लिए साझा क्रेडेंशियल की अब कोई आवश्यकता नहीं।
LDAP समर्थन: अपने LDAP क्रेडेंशियल से Kviklet में लॉगिन करें।
SAML समर्थन: अपने SAML क्रेडेंशियल से Kviklet में लॉगिन करें। (केवल एंटरप्राइज)
समीक्षा/अनुमोदन प्रवाह: अन्य डेवलपर्स के डेटा अनुरोधों पर टिप्पणियाँ और सुझाव दें।
अस्थायी पहुंच (1 घंटा): अनुमोदित होने के बाद 1 घंटे के लिए db पर कोई भी स्टेटमेंट निष्पादित करें।
एकल क्वेरी: एक एकल स्टेटमेंट निष्पादित करें। समीक्षक को निष्पादन से पहले आपकी क्वेरी की समीक्षा करने की अनुमति देता है।
ऑडिट लॉग: एकल स्थान जो लेखक, निष्पादन का कारण आदि के साथ सभी निष्पादित स्टेटमेंट को लॉग करता है।
RBAC: कॉन्फ़िगर करें कि किस टीम की किस डेटाबेस/तालिका तक पहुंच है, DB इंजन जितनी बारीक ग्रैन्युलैरिटी की अनुमति देता है उतनी बारीक।
Postgres प्रॉक्सी: अपनी पसंद के DB क्लाइंट का उपयोग करने के लिए एक प्रॉक्सी सर्वर शुरू करें, लेकिन सब कुछ Kviklet ऑडिट लॉग में रिकॉर्ड किया जाएगा।
Kubernetes Exec: अपने कुबरनेट्स क्लस्टर में एक पॉड पर एक स्टेटमेंट निष्पादित करें। (वर्तमान में केवल एकल कमांड के निष्पादन का समर्थन करता है, अभी तक लाइव सत्र नहीं)
भूमिका-आधारित समीक्षा गेट्स: निष्पादन से पहले विशिष्ट भूमिकाओं से अनुमोदन आवश्यक है। (केवल एंटरप्राइज)
भूमिका सिंक: अपने आइडेंटिटी प्रोवाइडर समूहों से स्वचालित रूप से उपयोगकर्ता भूमिकाएँ सिंक करें। (केवल एंटरप्राइज)
API कुंजियाँ: Kviklet API तक प्रोग्रामेटिक पहुँच। (केवल एंटरप्राइज)

Feature by Database/Connection Type

अधिकांश सुविधाएँ सभी डेटाबेस के लिए उपलब्ध हैं (SSO, LDAP, RBAC, समीक्षा/अनुमोदन प्रवाह, ऑडिट लॉग, आदि)। लेकिन कुछ सुविधाएँ प्रतिबंधित हैं, या तो इसलिए कि इसे अभी तक बनाया नहीं गया है या क्योंकि इसका उस विशिष्ट उद्देश्य के लिए कोई मतलब नहीं है। निम्न तालिका दिखाती है कि कौन सी सुविधाएँ किस डेटाबेस प्रकार के लिए उपलब्ध हैं:

Database	स्टेटमेंट समीक्षा	अस्थायी पहुंच	प्रॉक्सी(बीटा)	एक्सप्लेन प्लान
Postgres	✓	✓	✓	✓
MySQL	✓	✓	✗	✓
MariaDB	✓	✓	✗	✓
SQL Server	✓	✓	✗	✓
MongoDB	✓	✓	✗	✗
Kubernetes	✓	✗	✗	✗

Setup

Kviklet एक सरल डॉकर कंटेनर के रूप में आता है। आप उपलब्ध संस्करण Releases के अंतर्गत पा सकते हैं। हम अनुशंसा करते हैं कि आप अपने द्वारा उपयोग किए जा रहे संस्करण को नियमित रूप से अपडेट करें क्योंकि हम नई सुविधाएँ बनाते रहते हैं।
वर्तमान में नवीनतम ghcr.io/kviklet/kviklet:0.7.0 है, आप :main का भी उपयोग कर सकते हैं लेकिन कभी-कभी हम गलती से कुछ बगी मर्ज कर सकते हैं। हालांकि हम उससे बचने की कोशिश करते हैं।

Quick Start

यदि आप केवल यह देखना चाहते हैं कि यह कैसे काम करता है:

यहाँ एक न्यूनतम docker-compose.yaml है:
कंपोज़ सामग्री विस्तार करने के लिए क्लिक करें
``` 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.sql
kviklet-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 up -d के माध्यम से चलाएँ। Kviklet पोर्ट 80 पर शुरू होगा, localhost पर जाएँ और इसके साथ खेलें। एडमिन लॉगिन [email protected] है और पासवर्ड admin है।
डॉकर-कम्पोज़ में एक अतिरिक्त 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>

### डीबी सेटअप

Kviklet को क्वेरी, कनेक्शन, अनुमोदन आदि के बारे में मेटाडेटा सहेजने के लिए अपने स्वयं के पोस्टग्रेस डेटाबेस (या कम से कम स्कीमा) की आवश्यकता होती है।
आप उनकी आधिकारिक छवि यहाँ पा सकते हैं: https://hub.docker.com/_/postgres, या अपने पसंदीदा क्लाउड प्रदाता द्वारा क्लाउड होस्टेड संस्करण का उपयोग कर सकते हैं।

Kviklet कंटेनर शुरू करते समय, आपको इन तीन पर्यावरण चरों को तदनुसार सेट करने की आवश्यकता होगी:```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]

वैकल्पिक प्रमाणीकरण विधियाँ

IAM Auth: डेटाबेस कनेक्शन के लिए AWS IAM Auth का उपयोग करना संभव है, जिस स्थिति में आप बस पासवर्ड छोड़ देते हैं और केवल उपयोगकर्ता नाम सेट करते हैं। आपको पर्यावरण चर भी सेट करना होगा: ``` SPRING_DATASOURCE_IAMAUTH=true

Kviklet सामान्य स्थानों (env vars, instance roles, आदि) से क्रेडेंशियल्स लोड करेगा और कनेक्शन के लिए एक टोकन उत्पन्न करेगा।

Certificates: आप db कनेक्शन के लिए भी प्रमाणपत्र का उपयोग कर सकते हैं, उदाहरण के लिए यहाँ देखें।

Initial User

आपको कॉन्फ़िगरेशन उद्देश्यों के लिए एक प्रारंभिक एडमिन उपयोगकर्ता की आवश्यकता होगी। इसके लिए 2 env वेरिएबल्स सेट करें: INITIAL_USER_EMAIL और INITIAL_USER_PASSWORD ताकि आप वेब इंटरफ़ेस में लॉगिन कर सकें। आप बाद में UI के माध्यम से पासवर्ड बदल सकते हैं।
Example:``` 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

google क्लाइंट आईडी और सीक्रेट आप आसानी से google के निर्देशों का पालन करके यहाँ प्राप्त कर सकते हैं:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid

मान्य redirect URI के लिए, आपको कॉन्फ़िगर करना चाहिए: https://[kviklet_host]/api/login/oauth2/code/google
Allowed Origins के लिए, बस आपका होस्ट किया गया kviklet URL।

इन environment variables को सेट करने के बाद आपके संगठन का कोई भी व्यक्ति "sign in with google" बटन से लॉगिन कर सकता है। लेकिन डिफ़ॉल्ट रूप से उनके पास कोई अनुमति नहीं होगी, आपको उन्हें एक बार लॉग इन करने के बाद एक भूमिका (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 इंस्टेंस पर रीडायरेक्ट करता है। एंटरप्राइज एडिशन में आप role sync को सक्षम कर सकते हैं ताकि आपके keycloak इंस्टेंस से रोल्स को kviklet में स्वचालित रूप से सिंक किया जा सके। अधिक जानकारी के लिए Role Sync सेक्शन देखें।

GitHub (बीटा)

बीटा: GitHub प्रमाणीकरण नया है और अभी role sync का समर्थन नहीं करता — हर नया उपयोगकर्ता डिफ़ॉल्ट भूमिका के साथ आता है और उसे मैन्युअल रूप से भूमिकाएं असाइन की जानी चाहिए।

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

एक GitHub OAuth ऐप बनाएं https://github.com/settings/developers पर और कॉन्फ़िगर करें:

- प्राधिकरण कॉलबैक URL: `https://[kviklet_host]/api/login/oauth2/code/github`
- होमपेज URL: आपका होस्ट किया गया Kviklet URL

`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` **आवश्यक** है (Kviklet इसके बिना शुरू होने से इनकार करता है)। GitHub OAuth ऐप्स यह प्रतिबंधित नहीं कर सकते कि OAuth प्रवाह कौन पूरा करता है, इसलिए Kviklet प्रमाणीकरण के बाद `/user/orgs` को कॉल करता है और उन उपयोगकर्ताओं को अस्वीकार करता है जो कम से कम एक अनुमत सूचीबद्ध संगठन के सदस्य नहीं हैं (केस-असंवेदनशील, पहले 100 संगठनों की जाँच की जाती है)।

संगठन जाँच के लिए उपयोगकर्ता की सदस्यता देखने के लिए, उपयोगकर्ता को OAuth सहमति स्क्रीन पर प्रत्येक अनुमत सूचीबद्ध संगठन के आगे **Grant** (या **Request**) पर क्लिक करना होगा। यदि संगठन में "Restrict third-party OAuth applications" सक्षम है, तो किसी भी सदस्य की सदस्यता दिखाई देने से पहले एक संगठन स्वामी को OAuth ऐप को एक बार अनुमोदित करना होगा।

Kviklet `read:user`, `user:email` और `read:org` स्कोप का अनुरोध करता है। ईमेल हमेशा `/user/emails` से पढ़े जाते हैं और केवल एक `primary && verified` प्रविष्टि स्वीकार की जाती है, इसलिए निजी ईमेल पते वाले उपयोगकर्ता अभी भी सफलतापूर्वक लॉग इन करते हैं।

#### अन्य OIDC प्रदाता

अन्य OIDC-अनुरूप प्रदाता (GitLab, Auth0, Okta, आदि) को Keycloak के समान काम करना चाहिए। ध्यान दें कि `redirect URI` आपके द्वारा चुने गए प्रकार के आधार पर बदल जाएगा, इसलिए यदि आप `gitlab` चुनते हैं तो यह `https://[kviklet_host]/api/login/oauth2/code/gitlab` होगा।
यदि आपको समस्याएँ आती हैं, तो बेझिझक एक मुद्दा बनाएँ, हमने अभी तक हर एक OIDC प्रदाता का परीक्षण नहीं किया है (अभी तक) और कार्यान्वयन में मामूली अंतर हो सकते हैं जिनके लिए Kviklet की ओर से अद्यतन की आवश्यकता हो सकती है।

### LDAP

Kviklet LDAP प्रमाणीकरण का समर्थन करता है। LDAP को सक्षम और कॉन्फ़िगर करने के लिए, आप निम्नलिखित पर्यावरण चर को ओवरराइड कर सकते हैं:```
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: उपयोगकर्ता खाते संग्रहीत किए जाने वाले संगठनात्मक इकाई (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

आपके पहचान प्रदाता को निम्नलिखित के साथ कॉन्फ़िगर किया जाना चाहिए:

Entity ID: https://[kviklet_host]/api/saml2/service-provider-metadata/saml
Redirect Uri: https://[kviklet_host]/api/login/saml2/sso/saml

SAML कॉन्फ़िगर करने के बाद, उपयोगकर्ता पहचान प्रदाता के माध्यम से लॉग इन कर सकते हैं। पहली लॉगिन पर, डिफ़ॉल्ट अनुमतियों के साथ एक उपयोगकर्ता खाता बनाया जाता है।

यदि आप सही ढंग से IDP पर रीडायरेक्ट हो जाते हैं लेकिन फिर CORS त्रुटि मिलती है, तो आप अपने IDPs होस्ट को Kviklet में अनुमत मूल में जोड़ सकते हैं:``` CORS_ALLOWEDORIGINS=https://[idp_host]

## कॉन्फ़िगरेशन

### कनेक्शन

Kviklet शुरू करने के बाद, आपको पहले एक डेटाबेस कनेक्शन कॉन्फ़िगर करना होगा। सेटिंग्स -> डेटाबेस -> कनेक्शन जोड़ें पर जाएं।

![कनेक्शन जोड़ें](https://assets.kitploit.com/production/public/readmes/7140/3ded2a0b23e5d2f02feb21a854263c91dedea25a789fb75ab8342384c4e39b52.png)
![कनेक्शन जोड़ें](https://assets.kitploit.com/production/public/readmes/7140/585238c9eddad8ed4e2440096ce0616445a6696e1042f58676a1d0b038edde7f.png)

यहां आप प्रत्येक कनेक्शन के लिए समीक्षा आवश्यकताओं और निष्पादन सीमाओं को कॉन्फ़िगर कर सकते हैं। विवरण के लिए [समीक्षा गेट्स](#review-gates) देखें।

#### AWS IAM AUTH

Kviklet Postgres और MySQL डेटाबेस कनेक्शन के लिए IAM Auth का उपयोग करने का समर्थन करता है। इसके लिए, नया कनेक्शन बनाते समय IAM Auth चुनें।

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

इससे पासवर्ड सेट करने का विकल्प हट जाएगा और इसके बजाय डेटाबेस से कनेक्ट करने के लिए AWS क्रेडेंशियल्स का उपयोग किया जाएगा।

Kviklet क्रेडेंशियल्स खोजने और कनेक्शन के लिए टोकन उत्पन्न करने के लिए AWS के `DefaultCredentialsProvider` का उपयोग करता है। इसका मतलब है कि सभी सामान्य स्थान काम करने चाहिए (env vars या संबद्ध इंस्टेंस भूमिकाएं), सटीक क्रम यहां प्रलेखित है: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html

इसके अतिरिक्त, आप एक AWS भूमिका ARN प्रदान कर सकते हैं जिसे Kviklet ग्रहण करेगा, और उन क्रेडेंशियल्स का उपयोग करके अस्थायी DB टोकन बनाएगा। यह उन डेटाबेस से कनेक्ट करने के लिए विशेष रूप से उपयोगी है जो Kviklet के समान AWS खाते में नहीं हैं। इस सुविधा का उपयोग करने के लिए, IAM Auth कनेक्शन बनाते या संपादित करते समय निर्धारित फ़ील्ड में भूमिका ARN दर्ज करें। फ़ील्ड को खाली छोड़ने पर डिफ़ॉल्ट क्रेडेंशियल प्रदाता का उपयोग होगा (कोई भूमिका ग्रहण नहीं)।

टोकन उत्पादन के दौरान उपयोग करने के लिए AWS क्षेत्र आपके कनेक्शन URL से अनुमानित किया जाता है, इसलिए इसे सेट करने का कोई विकल्प नहीं है।

अपने डेटाबेस के लिए IAM Auth सेटअप करने का तरीका जानने के लिए आधिकारिक AWS दस्तावेज़ का पालन करें: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
मुख्य दो बिंदु हैं:

- IAM Auth विकल्प और सही अनुमतियों के साथ एक DB उपयोगकर्ता बनाएं
- एक IAM नीति बनाएं जो AWS इकाई को इस उपयोगकर्ता के लिए टोकन उत्पन्न करने की अनुमति दे

### समीक्षा गेट्स

डिफ़ॉल्ट रूप से Kviklet एक सरल समीक्षा गणना कॉन्फ़िगरेशन की अनुमति देता है। आप कॉन्फ़िगर कर सकते हैं कि किसी विशेष कनेक्शन पर कितने अनुमोदन अनुरोधों की आवश्यकता है, इससे पहले कि उन्हें निष्पादित किया जा सके।

एक अनुरोध की अनुमोदन स्थिति प्रत्येक समीक्षक की नवीनतम कार्रवाई के आधार पर गणना की जाती है। यदि कोई समीक्षक अनुमोदन करता है और बाद में परिवर्तन का अनुरोध करता है, तो केवल परिवर्तन अनुरोध गिना जाता है—उनका पिछला अनुमोदन हटा दिया जाता है। किसी अनुरोध को संपादित करना हमेशा सभी पूर्व अनुमोदनों को रीसेट करता है, यह सुनिश्चित करते हुए कि बिना पहले समीक्षा किए कोई भी परिवर्तन निष्पादित नहीं किया जा सकता। इसी तरह, यदि कोई निष्पादन विफल होता है (जैसे SQL सिंटैक्स त्रुटि के कारण), तो अनुमोदन रीसेट हो जाते हैं ताकि अनुरोध को सही किया जा सके और बिना नया बनाए फिर से अनुमोदित किया जा सके।

आप प्रति कनेक्शन **अधिकतम निष्पादन** सीमा भी कॉन्फ़िगर कर सकते हैं ताकि यह नियंत्रित किया जा सके कि एक स्वीकृत अनुरोध को कितनी बार निष्पादित किया जा सकता है। डिफ़ॉल्ट 1 है। इसे 0 पर सेट करने से असीमित निष्पादन की अनुमति मिलती है। विफल निष्पादन इस सीमा में नहीं गिने जाते।

#### भूमिका-आधारित समीक्षा आवश्यकताएँ (एंटरप्राइज़)

Kviklet एंटरप्राइज़ लाइसेंस के साथ, आप अलग-अलग कनेक्शनों को विशिष्ट भूमिकाओं वाले उपयोगकर्ताओं से अनुमोदन की आवश्यकता के लिए कॉन्फ़िगर कर सकते हैं। यह आपको उदाहरण के लिए, किसी दिए गए डेटाबेस को बनाए रखने वाली टीम से अनुमोदन की आवश्यकता करने या संवेदनशील कनेक्शनों को DBA या प्रबंधन अनुमोदन के पीछे रखने की अनुमति देता है।

**यह कैसे काम करता है:**

प्रत्येक कनेक्शन में **कुल आवश्यक समीक्षाओं** की संख्या (`numTotalRequired`) होती है जो एक न्यूनतम सीमा के रूप में कार्य करती है—भूमिकाओं की परवाह किए बिना आवश्यक अलग-अलग अनुमोदनों की न्यूनतम संख्या। इसके ऊपर, आप **भूमिका आवश्यकताएँ** जोड़ सकते हैं जो निर्दिष्ट करती हैं कि किसी विशेष भूमिका वाले उपयोगकर्ताओं से कितने अनुमोदन आने चाहिए (जैसे, "DBA से 1, सुरक्षा से 1")।

एक अनुरोध तभी स्वीकृत होता है जब **दोनों** शर्तें पूरी हों:
- अलग-अलग अनुमोदनों की कुल संख्या `numTotalRequired` को पूरा करती है
- प्रत्येक भूमिका आवश्यकता अलग-अलग संतुष्ट होती है

यदि कोई उपयोगकर्ता कई भूमिकाओं से संबंधित है, तो उस उपयोगकर्ता का एक एकल अनुमोदन सभी मिलान वाली भूमिका आवश्यकताओं में गिना जाता है। हालाँकि, यह कुल गणना में केवल एक अनुमोदन के रूप में गिना जाता है।

**उदाहरण:** एक कनेक्शन के लिए 3 कुल अनुमोदन की आवश्यकता है, जिसमें DBA से 1 और सुरक्षा से 1 शामिल है। एक उपयोगकर्ता जिसके पास DBA और सुरक्षा दोनों भूमिकाएँ हैं, वह अनुमोदन करता है—यह दोनों भूमिका आवश्यकताओं को संतुष्ट करता है लेकिन कुल आवश्यक 3 अनुमोदनों में से केवल 1 के रूप में गिना जाता है। किसी भी उपयोगकर्ता से दो और अनुमोदन अभी भी आवश्यक हैं।

यदि आपका एंटरप्राइज़ लाइसेंस समाप्त हो जाता है, तो मौजूदा भूमिका-आधारित समीक्षा आवश्यकताएँ लागू रहती हैं लेकिन अब उन्हें संशोधित नहीं किया जा सकता। आप केवल उन्हें हटा सकते हैं ताकि सरल कुल समीक्षा कॉन्फ़िगरेशन पर वापस जा सकें।

### भूमिकाएँ

Kviklet 3 भूमिकाओं के साथ आता है: डिफ़ॉल्ट, व्यवस्थापक और डेवलपर।

- डिफ़ॉल्ट भूमिका सभी कनेक्शनों और अनुरोधों के लिए पढ़ने की पहुँच प्रदान करती है। यह भूमिका प्रत्येक उपयोगकर्ता को असाइन की जाती है और इसे हटाया नहीं जा सकता। हालाँकि, आप इस भूमिका की अनुमतियाँ अपनी इच्छानुसार बदल सकते हैं।
- व्यवस्थापकों के पास कनेक्शन बनाने और संपादित करने की अनुमति है, साथ ही नए उपयोगकर्ताओं को जोड़ने और उनकी अनुमतियाँ सेट करने की अनुमति है।
- डेवलपर अनुरोध बना सकते हैं, साथ ही उन्हें अनुमोदित और टिप्पणी कर सकते हैं, और निश्चित रूप से वास्तविक कथनों को निष्पादित कर सकते हैं।

आप भूमिकाओं को अनुकूलित कर सकते हैं और उदाहरण के लिए, किसी भूमिका को केवल एक विशिष्ट कनेक्शन या DB कनेक्शनों के समूह तक पहुँच दे सकते हैं।
यह उपयोगी है, उदाहरण के लिए, यदि आपके पास विभिन्न डेटाबेस वाली अलग-अलग टीमें हैं और आप उन तक पहुँच को अधिक सूक्ष्मता से नियंत्रित करना चाहते हैं।

#### नई भूमिका बनाना

नई भूमिका बनाना इस प्रकार काम करता है। सेटिंग्स -> भूमिकाएँ -> भूमिका जोड़ें पर जाएँ।

![भूमिका जोड़ें](https://assets.kitploit.com/production/public/readmes/7140/a91b79287c0b3130b83bdde1c059f49b89c5d43a1c0deae33b211ea427956f8e.png)
![भूमिका जोड़ें](https://assets.kitploit.com/production/public/readmes/7140/c535ac152759bb21bea04a0968ce43fa7bf946c7699feca23c71f9eaba41ceaf.png)

डिफ़ॉल्ट सेटिंग्स अधिकांश भूमिकाओं के लिए उतनी प्रासंगिक नहीं हैं और आप बस उपयोगकर्ता को पढ़ने और भूमिका दृश्य पहुँच दे सकते हैं और इसे वहीं छोड़ सकते हैं।
अधिक दिलचस्प कनेक्शनों के लिए व्यक्तिगत अनुमतियाँ जोड़ना है। यहाँ आप पहले विशिष्ट कनेक्शनों का चयन करने के लिए एक चयनकर्ता जोड़ते हैं। यह या तो एक विशिष्ट id हो सकता है या आप एकाधिक कनेक्शनों से मेल खाने के लिए `*` के साथ वाइल्डकार्ड का उपयोग कर सकते हैं। उदाहरण के लिए, यदि आप एक ऐसी भूमिका चाहते हैं जिसकी सभी dev डेटाबेस तक पहुँच हो (यदि आप उन तक पहुँच को भी Kviklet के साथ प्रबंधित करते हैं), तो आप `dev-*` जैसे चयनकर्ता का उपयोग करेंगे और सुनिश्चित करेंगे कि कनेक्शनों की ids सही ढंग से सेट हैं।

बेशक, आप एक ऐसी प्रणाली भी बना सकते हैं जिसका उपयोग आप अपने संगठन के विभिन्न टीमों के लिए करते हैं।

### भूमिका सिंक (एंटरप्राइज़)

अपने आइडेंटिटी प्रदाता समूहों से स्वचालित रूप से उपयोगकर्ता भूमिकाओं को सिंक करें। इस सुविधा के लिए एंटरप्राइज़ लाइसेंस की आवश्यकता है।

**कॉन्फ़िगरेशन** सेटिंग्स > भूमिका सिंक में किया जाता है:

- **भूमिका सिंक सक्षम करें**: सिंक्रोनाइज़ेशन चालू/बंद करें
- **सिंक मोड**:
  - **पूर्ण सिंक** - उपयोगकर्ता भूमिकाएँ उनके IdP समूह मैपिंग (डिफ़ॉल्ट भूमिका के अतिरिक्त) से बिल्कुल मेल खाती हैं
  - **योगात्मक** - IdP समूह भूमिकाएँ जोड़ते हैं लेकिन मौजूदा भूमिकाओं को नहीं हटाते
  - **केवल पहले लॉगिन पर** - भूमिकाएँ केवल पहले लॉगिन पर सिंक होती हैं, उसके बाद मैन्युअल परिवर्तन संरक्षित रहते हैं
- **समूह विशेषता**: समूह सदस्यता वाली IdP विशेषता (डिफ़ॉल्ट: `groups`)
- **भूमिका मैपिंग**: IdP समूह के नामों (जैसे, `engineering`) को Kviklet भूमिकाओं से मैप करें

#### OIDC सेटअप

अपने OIDC प्रदाता को ID टोकन में `groups` दावा शामिल करने के लिए कॉन्फ़िगर करें:

- **Keycloak**:

  Keycloak डिफ़ॉल्ट रूप से टोकन में समूह शामिल नहीं करता है, इसलिए आपको क्लाइंट में एक मैपर जोड़ना होगा।

  1. बाएं मेनू में **क्लाइंट** पर जाएँ
  2. अपना Kviklet क्लाइंट चुनें
  3. **क्लाइंट स्कोप** टैब पर जाएँ
  4. समर्पित स्कोप पर क्लिक करें (जैसे, `kviklet-dedicated`)
  5. **मैपर** टैब पर जाएँ
  6. **मैपर जोड़ें** → **कॉन्फ़िगरेशन द्वारा** पर क्लिक करें
  7. **समूह सदस्यता** चुनें
  8. मैपर कॉन्फ़िगर करें:

  | सेटिंग | मान |
  |---------|------|
  | नाम | `groups` |
  | टोकन दावा नाम | `groups` |
  | पूर्ण समूह पथ | **बंद** |
  | ID टोकन में जोड़ें | **चालू** |
  | एक्सेस टोकन में जोड़ें | **चालू** |
  | userinfo में जोड़ें | **चालू** |

  9. **सहेजें** पर क्लिक करें

  > **महत्वपूर्ण:** "टोकन दावा नाम" को Kviklet की भूमिका सिंक सेटिंग्स में कॉन्फ़िगर किए गए "समूह विशेषता" (डिफ़ॉल्ट: `groups`) से मेल खाना चाहिए।

- **अन्य OIDC प्रदाता**: ID टोकन में उपयोगकर्ता की समूह सदस्यता शामिल करने के लिए एक समूह मैपर/दावा जोड़ें। यह आमतौर पर प्रदाता के व्यवस्थापक UI में किया जाता है।

  यदि आपको समस्याएँ आती हैं, तो बेझिझक एक मुद्दा बनाएँ, हमने अभी तक हर एक OIDC प्रदाता को आज़माया नहीं है और कार्यान्वयन में थोड़े अंतर हो सकते हैं जिनके लिए Kviklet की ओर से अपडेट की आवश्यकता हो सकती है।

#### LDAP सेटअप

LDAP भूमिका सिंक `memberOf` विशेषता का उपयोग करता है:

1. सुनिश्चित करें कि आपके LDAP सर्वर में `memberOf` ओवरले सक्षम है
2. Kviklet में **समूह विशेषता** को `memberOf` पर सेट करें
3. फिर समूह के नाम उपयोगकर्ता विशेषताओं में `memberOf` विशेषता से निकाले जाते हैं।

#### SAML सेटअप

अपने SAML IdP को अभिकथन में समूह शामिल करने के लिए कॉन्फ़िगर करें:

1. एक विशेषता कथन जोड़ें जो उपयोगकर्ता समूह सदस्यता को मैप करता है
2. Kviklet में **समूह विशेषता** को अपने SAML विशेषता नाम से मिलान करने के लिए सेट करें
3. फिर समूह के नाम उपयोगकर्ता विशेषताओं में SAML विशेषता से निकाले जाते हैं।

### सूचनाएँ

आप Kviklet को Slack या Teams में एक चैनल पर सूचनाएँ भेजने के लिए कॉन्फ़िगर कर सकते हैं। यह आपकी टीम को समीक्षा की आवश्यकता वाले नए अनुरोधों के बारे में सूचित करने के लिए उपयोगी है। आप इसे सेटिंग्स -> सामान्य -> सूचना सेटिंग्स में कॉन्फ़िगर कर सकते हैं।

#### Slack

Slack सूचनाओं को कॉन्फ़िगर करने के लिए, आपको एक Slack ऐप बनाना होगा और उसके लिए वेबहुक सक्षम करना होगा। आप यहाँ दिए गए निर्देशों का पालन कर सकते हैं: https://api.slack.com/messaging/webhooks

#### Teams

Teams सूचनाएँ एक Power Automate **वर्कफ़्लो** वेबहुक का उपयोग करती हैं। Kviklet एक Adaptive Card भेजता है, जिसे वेबहुक टेम्पलेट आपके चैनल पर पोस्ट करता है।

**अनुशंसित: वर्कफ़्लो टेम्पलेट का उपयोग करें**

1. Teams में, उस चैनल पर जाएँ जहाँ आप सूचनाएँ चाहते हैं, चैनल नाम के आगे **...** पर क्लिक करें और **वर्कफ़्लो** चुनें (या **वर्कफ़्लो** ऐप जोड़ें)।
2. **"एक चैनल पर वेबहुक अलर्ट भेजें"** टेम्पलेट खोजें और बनाएँ।
3. संकेत मिलने पर साइन इन करें, फिर लक्ष्य टीम और चैनल चुनें और वर्कफ़्लो बनाएँ।
4. ट्रिगर चरण खोलें और उत्पन्न **HTTP POST URL** कॉपी करें।
5. URL को Kviklet में सेटिंग्स -> सामान्य -> सूचना सेटिंग्स के तहत पेस्ट करें और सहेजें पर क्लिक करें।

**वैकल्पिक: वर्कफ़्लो को मैन्युअल रूप से बनाएँ**

यदि आप स्वयं फ़्लो बनाना पसंद करते हैं (या टेम्पलेट उपलब्ध नहीं है):

1. चैनल **...** -> **वर्कफ़्लो** -> ट्रिगर **"जब एक Teams वेबहुक अनुरोध प्राप्त होता है"** के साथ एक फ़्लो बनाएँ।
2. क्रिया **Microsoft Teams -> "चैट या चैनल में कार्ड पोस्ट करें"** जोड़ें।
3. क्रिया के **Adaptive Card** फ़ील्ड को एक्सप्रेशन `string(triggerBody())` पर सेट करें ताकि वह Kviklet द्वारा भेजा गया कार्ड पोस्ट करे।
4. लक्ष्य टीम और चैनल चुनें, **सहेजें**, फिर ट्रिगर चरण से **HTTP POST URL** कॉपी करें।

वर्तमान में निम्नलिखित के लिए सूचनाएँ हैं:

- नए अनुरोध, जिन्हें अनुमोदन की आवश्यकता है
- अनुरोधों पर नए अनुमोदन

#### बेस URL कॉन्फ़िगरेशन

जब Kviklet किसी रिवर्स प्रॉक्सी या Kubernetes Ingress के पीछे चल रहा हो, तो सूचना लिंक आपके सार्वजनिक डोमेन के बजाय आंतरिक IP पते का उपयोग कर सकते हैं। Kviklet आने वाले अनुरोधों को देखकर सही URL ट्रैक करने का प्रयास करता है, लेकिन कुछ रिवर्स प्रॉक्सी Forwarded हेडर सही ढंग से सेट नहीं करते हैं। इसे ठीक करने के लिए, बेस URL स्पष्ट रूप से सेट करें:```
KVIKLET_BASE_URL=https://kviklet.example.com

This ensures all notification links point to the correct public URL.

लॉगिंग

डिफ़ॉल्ट रूप से Kviklet मानव-पठनीय (सुंदर) लॉग stdout पर लिखता है, जो उन्हें सीधे या docker logs के माध्यम से पढ़ने में सुविधाजनक होता है।

यदि आप लॉग को किसी केंद्रीय सिस्टम (Elasticsearch, Loki, Datadog, CloudWatch, …) पर भेजते हैं, तो आप इसके बजाय संरचित JSON लॉग पर स्विच कर सकते हैं, जिन्हें अनुक्रमित और क्वेरी करना आसान होता है। प्रारूप को एक पर्यावरण चर के माध्यम से सेट करें:

KVIKLET__LOG_FORMAT=json

One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)

LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs

## एन्क्रिप्शन

यदि आप नहीं चाहते कि क्रेडेंशियल DB में स्पष्ट टेक्स्ट में संग्रहीत हों, तो यह अनुशंसा की जाती है कि आप Kviklet postgres DB पर ही डेटाबेस एन्क्रिप्शन सक्षम करें। अधिकांश होस्टेड प्रदाताओं के लिए यह क्लिक करने के लिए एक साधारण चेकबॉक्स है। फिर भी, यदि Kviklet डेटाबेस किसी भी तरह से समझौता हो जाता है, तो यह एक बड़ा सुरक्षा जोखिम है। क्योंकि इसमें संभावित रूप से आपके सभी उत्पादन डेटास्टोर के डेटाबेस क्रेडेंशियल शामिल हैं। इसलिए आप आराम से क्रेडेंशियल्स के एन्क्रिप्शन को सक्षम कर सकते हैं।

ऐसा करने के लिए बस दो पर्यावरण चर सेट करें।```
ENCRYPTION_ENABLED=true
ENCRYPTION_KEY_CURRENT=some-secret

Kviklet आपके सभी मौजूदा क्रेडेंशियल्स को स्टार्टअप पर एन्क्रिप्ट करेगा, और भविष्य में आपके द्वारा बनाए जाने वाले कनेक्शनों के लिए गुप्त कुंजी का उपयोग करेगा।

कुंजी रोटेशन

यदि आप कुंजी को रोटेट करना चाहते हैं, तो आप बस पिछली कुंजी के लिए एक और वेरिएबल जोड़ सकते हैं और वर्तमान को बदल सकते हैं:``` ENCRYPTION_KEY_PREVIOUS=some-secret ENCRYPTION_KEY_CURRENT=another-secret

Kviklet स्टार्टअप पर सभी कनेक्शनों को फिर से एन्क्रिप्ट करेगा, ताकि आप पिछली कुंजी को हटाकर कंटेनर को पुनः प्रारंभ कर सकें।

## एपीआई कुंजियाँ

Kviklet सिस्टम तक प्रोग्रामेटिक पहुँच के लिए एपीआई कुंजियों का समर्थन करता है। यह केवल एंटरप्राइज़ सुविधा है और इसके लिए एक वैध लाइसेंस आवश्यक है। आप सेटिंग्स -> एपीआई कुंजियाँ अनुभाग में एपीआई कुंजियाँ बना सकते हैं।

![एपीआई कुंजियाँ](https://assets.kitploit.com/production/public/readmes/7140/a11d80c93ef29ead3b8b3bf3b435a782208d10bd2978d80cd2c4edc1fc7bc506.png)
![एपीआई कुंजियाँ](https://assets.kitploit.com/production/public/readmes/7140/21948bc6a43dbdd88be563befbfc9052a1dd4a99735817c2ff99680c9c32cbd0.png)

इसका उपयोग इस प्रकार करें:```bash
curl --location '[kviklet_host]/api/connections/' \
--header 'Authorization: Bearer your-api-key'

API कुंजियाँ उन उपयोगकर्ताओं की अनुमतियाँ प्राप्त करती हैं जो उन्हें बनाते हैं। वर्तमान में केवल एडमिन ही API कुंजियाँ प्रबंधित कर सकते हैं और API कुंजी के साथ किए गए सभी कार्यों का श्रेय उस उपयोगकर्ता को दिया जाता है जिसने कुंजी बनाई थी।

कुछ प्रारंभिक API दस्तावेज़ [kviklet_host]/api/swagger-ui/index.html पर पाए जा सकते हैं। लेकिन ध्यान रखें कि यह कार्य प्रगति पर है और भविष्य के संस्करणों में API बदल सकता है।

अंततः सत्य कोड में है, इसलिए आप हमेशा नियंत्रक को देख सकते हैं कि API कैसे परिभाषित किया गया है। यदि आपके कोई प्रश्न हैं तो बेझिझक एक मुद्दा खोलें।

प्रायोगिक सुविधाएँ

वर्तमान में दो प्रायोगिक सुविधाएँ हैं। जो अधिकतर समुदाय की प्रतिक्रिया पर आधारित हैं। इन्हें आज़माने और अपनी कोई भी राय देने के लिए स्वतंत्र महसूस करें। हम भविष्य में इसे और विकसित करने और मुख्य अनुमोदन प्रवाह के साथ इसे अच्छी तरह से काम करने की आशा करते हैं।

कुबेरनेटीज़ Exec

यदि आप Kubernetes Exec सुविधा का उपयोग करना चाहते हैं तो आपको एक अलग kubernetes कनेक्शन बनाना होगा। Kviklet कमांड को निष्पादित करने के लिए तैनात पॉड के उपयोगकर्ता का उपयोग करेगा। इसलिए सुनिश्चित करें कि उपयोगकर्ता के पास उन पॉड्स पर कमांड निष्पादित करने के लिए आवश्यक अनुमतियाँ हैं जिन तक आप पहुँचना चाहते हैं।

Kviklet कमांड को निष्पादित करने के लिए /bin/sh का भी उपयोग करता है, इसलिए आपको यह सुनिश्चित करना होगा कि आपके पॉड्स में एक शेल हो या कम से कम /bin/sh में एक सिम्लिंक हो। यदि यह आपको परेशान करता है तो बेझिझक एक मुद्दा खोलें, हम संभावित रूप से इसे कॉन्फ़िगरेबल बना सकते हैं या कोई अन्य समाधान ढूंढ सकते हैं।

Kubernetes कमांड आउटपुट के लिए केवल 5 सेकंड प्रतीक्षा करते हैं, यदि कमांड उससे अधिक समय लेता है तो Kviklet कमांड को टाइम आउट करने से पहले एक घंटे तक प्रतीक्षा करेगा। यह एक अस्थायी समाधान है, हम इसे और अधिक प्रतिक्रियाशील बनाने और संभावित रूप से टर्मिनल सत्रों को सक्षम करने के लिए वेबसॉकेट्स की जांच कर रहे हैं।

प्रॉक्सी, केवल Postgres

यदि आप अस्थायी पहुँच के लिए अनुरोध बनाते हैं, तो आप वेब इंटरफ़ेस का उपयोग करने के बजाय अपने प्रश्नों को kviklet प्रबंधित प्रॉक्सी के माध्यम से चला सकते हैं और अपनी पसंद के DB क्लाइंट का उपयोग कर सकते हैं। इसके लिए कंटेनर पोर्ट 5438-6000 का उपयोग करता है, इसलिए आपको उन्हें एक्सपोज़ करने की आवश्यकता है। उपयोगकर्ता तब एक अस्थायी पहुँच अनुरोध बना सकता है, और अनुमोदित होने के बाद "Start Proxy" पर क्लिक कर सकता है। प्रत्येक अनुरोध को एक पोर्ट और एक उपयोगकर्ता + एक अस्थायी पासवर्ड मिलेगा। इसके साथ वे डेटाबेस से कनेक्ट हो सकते हैं। Kviklet अस्थायी उपयोगकर्ता और पासवर्ड को मान्य करता है और सभी अनुरोधों को डेटाबेस पर अंतर्निहित उपयोगकर्ता को प्रॉक्सी करता है। कोई भी निष्पादित स्टेटमेंट ऑडिट लॉग में लॉग किए जाते हैं जैसे कि वे वेब इंटरफ़ेस के माध्यम से चलाए गए हों। ध्यान दें कि प्रॉक्सी पक्ष पर संदेश पार्सिंग का सभी क्लाइंट के साथ परीक्षण नहीं किया गया है, इसलिए यदि आपको उदाहरण के लिए स्टेटमेंट लॉग न होने जैसी समस्याओं का सामना करना पड़ता है तो बेझिझक एक मुद्दा खोलें।

Postgres Proxy

Postgres Proxy - TLS

Kviklet डेटाबेस के लिए TLS कनेक्शन को समाप्त करता है। इसका मतलब है कि डिफ़ॉल्ट रूप से प्रॉक्सी से और प्रॉक्सी तक कोई भी ट्रैफ़िक एन्क्रिप्टेड नहीं है।
यदि आप चाहते हैं कि kviklet ट्रैफ़िक को पुनः एन्क्रिप्ट करे, तो आप निम्नलिखित पर्यावरण चर सेट करके Kviklet को प्रॉक्सी के लिए एक TLS प्रमाणपत्र और कुंजी दे सकते हैं:``` 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 format में संग्रहीत किया जाना चाहिए।

प्रश्न? योगदान?

यदि आपके कोई प्रश्न हैं, प्रतिक्रिया देना चाहते हैं, या सेटअप में सहायता चाहते हैं, तो हमारे Discord समुदाय से जुड़ें। आप बग रिपोर्ट और सुविधा अनुरोधों के लिए GitHub issue भी बना सकते हैं।

यदि आप योगदान देना चाहते हैं, तो छोटी चीज़ों के लिए fork करें और PRs बनाने में संकोच न करें। यदि आप बड़ी सुविधाओं की योजना बना रहे हैं, तो मैं GitHub issue या Discord पर कुछ चर्चा की सराहना करूंगा।

आप मुझे [email protected] पर भी संपर्क कर सकते हैं।

kviklet v0.8.0

श्रेणियाँ