kviklet v0.8.0
تدفق مراجعة/موافقة شبيه بـ Pull Request لاستعلامات قاعدة البيانات. للوصول السلس والمتوافق للمهندسين إلى الإنتاج.
Kviklet
Kviklet.dev | ملاحظات الإصدار | ديسكورد
الوصول الآمن إلى بيئات الإنتاج دون إضعاف إنتاجية المطورين.
Kviklet (تنطق كويك-ليت) تتبنى مبدأ الأربع عيون ومستوى عالٍ من قابلية التهيئة لتوفير تدفق مراجعة وموافقة يشبه طلب السحب لعبارات SQL الفردية أو جلسات قاعدة البيانات. يتيح ذلك للفرق الهندسية التنظيم الذاتي حول من يحصل على أي بيانات ومتى، مما يسمح للمؤسسات بالبقاء آمنة ومتوافقة مع تبني سير عمل حديث ومُمكّن وحقيقي "DevOps".
Kviklet هي حاوية دوكر مستضافة ذاتيًا، توفر لك تطبيق ويب أحادي الصفحة. سجل الدخول لإنشاء طلبات SQL أو الموافقة على طلبات الآخرين. ترخيص مؤسسي اختياري يفتح ميزات متقدمة مثل مصادقة SAML، متطلبات المراجعة القائمة على الأدوار، مزامنة الأدوار، ومفاتيح API. يمكنك طلب ترخيص مؤسسي على kviklet.dev.
ندعم حاليًا Postgres، MySQL، MS SQL Server و MongoDB.
الميزات
تأتي Kviklet مع مجموعة متنوعة من الميزات التي تحتاجها الفرق الهندسية لإدارة الوصول إلى قواعد بيانات الإنتاج بطريقة بسيطة ولكن آمنة:
- SSO (OIDC, Google, Keycloak, إلخ): سجل الدخول إلى Kviklet دون الحاجة لاسم مستخدم أو كلمة مرور. لا مزيد من بيانات الاعتماد المشتركة للوصول إلى قاعدة البيانات.
- دعم LDAP: سجل الدخول إلى Kviklet باستخدام بيانات اعتماد LDAP الخاصة بك.
- دعم SAML: سجل الدخول إلى Kviklet باستخدام بيانات اعتماد SAML الخاصة بك. (للمؤسسات فقط)
- تدفق المراجعة/الموافقة: اترك تعليقات واقتراحات على طلبات البيانات للمطورين الآخرين.
- الوصول المؤقت (ساعة واحدة): نفذ أي عبارة على قاعدة بيانات لمدة ساعة بعد الموافقة.
- استعلام واحد: نفذ عبارة واحدة. يسمح للمراجع بمراجعة استعلامك قبل التنفيذ.
- سجل التدقيق: صفحة واحدة تسجل جميع العبارات المنفذة مع المؤلف وسبب التنفيذ إلخ.
- RBAC: قم بتكوين أي فريق لديه حق الوصول إلى أي قاعدة بيانات/جدول بدقة تسمح بها محرك قاعدة البيانات.
- وكيل Postgres: ابدأ خادم وكيل لاستخدام عميل قاعدة البيانات الذي تختاره، ولكن سيتم تخزين كل شيء في سجل تدقيق Kviklet.
- Kubernetes Exec: نفذ عبارة على بود في مجموعة Kubernetes الخاصة بك. (يدعم حاليًا تنفيذ أمر واحد فقط، لا جلسة مباشرة بعد)
- بوابات المراجعة القائمة على الأدوار: تتطلب موافقات من أدوار محددة قبل التنفيذ. (للمؤسسات فقط)
- مزامنة الأدوار: مزامنة أدوار المستخدمين تلقائيًا من مجموعات موفر الهوية الخاص بك. (للمؤسسات فقط)
- مفاتيح API: وصول برمجي إلى واجهة برمجة تطبيقات Kviklet. (للمؤسسات فقط)
الميزات حسب قاعدة البيانات/نوع الاتصال
معظم الميزات متاحة لجميع قواعد البيانات (SSO, LDAP, RBAC, تدفق المراجعة/الموافقة، سجل التدقيق، إلخ). لكن بعض الميزات مقيدة، إما لأنها لم تُبن بعد أو لأنها لا معنى لها لهذا الغرض المحدد. يوضح الجدول التالي الميزات المتاحة لكل نوع قاعدة بيانات:
| قاعدة البيانات | مراجعة العبارة | الوصول المؤقت | الوكيل (تجريبي) | شرح الخطة |
|---|---|---|---|---|
| Postgres | ✓ | ✓ | ✓ | ✓ |
| MySQL | ✓ | ✓ | ✗ | ✓ |
| MariaDB | ✓ | ✓ | ✗ | ✓ |
| SQL Server | ✓ | ✓ | ✗ | ✓ |
| MongoDB | ✓ | ✓ | ✗ | ✗ |
| Kubernetes | ✓ | ✗ | ✗ | ✗ |
الإعداد
تأتي Kviklet كحاوية دوكر بسيطة.
يمكنك العثور على الإصدارات المتاحة تحت الإصدارات. نوصي بتحديث الإصدار الذي تستخدمه بانتظام لأننا نواصل بناء ميزات جديدة.
أحدث إصدار حاليًا هو ghcr.io/kviklet/kviklet:0.7.0، يمكنك أيضًا استخدام :main لكن قد يحدث أحيانًا أن ندمج شيئًا به أخطاء عن طريق الخطأ. رغم أننا نحاول تجنب ذلك.
بداية سريعة
إذا كنت تريد فقط تجربة كيفية عمله:
-
إليك ملف 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.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>
### إعداد قاعدة البيانات
يحتاج Kviklet إلى قاعدة بيانات postgres خاصة به (أو على الأقل مخطط) لحفظ البيانات الوصفية حول الاستعلامات والاتصالات والموافقات وما إلى ذلك.
يمكنك العثور على صورته الرسمية هنا: 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:
من الممكن استخدام مصادقة AWS IAM لاتصال قاعدة البيانات، وفي هذه الحالة يمكنك ببساطة حذف كلمة المرور وتعيين اسم المستخدم فقط.
يجب عليك أيضًا تعيين متغير البيئة: ```
SPRING_DATASOURCE_IAMAUTH=true
Kviklet سوف يقوم بتحميل بيانات الاعتماد من الأماكن المعتادة (متغيرات البيئة، أدوار المثيل، إلخ) وإنشاء رمز مميز للاتصال.
- الشهادات: يمكنك أيضًا استخدام الشهادات للاتصال بقاعدة البيانات، انظر هنا كمثال.
المستخدم الأولي
ستحتاج إلى مستخدم إداري أولي لأغراض التهيئة. لهذا، قم بتعيين متغيري البيئة التاليين:
INITIAL_USER_EMAIL و INITIAL_USER_PASSWORD حتى تتمكن من تسجيل الدخول إلى الواجهة الويب. يمكنك تغيير كلمة المرور لاحقًا عبر الواجهة.
مثال:```
INITIAL_USER_EMAIL=[email protected]
INITIAL_USER_PASSWORD=someverysecurepassword
نحن ننشر حاوياتنا إلى حزم GitHub حاليًا، لذا مع كل هذا الإعداد يمكنك تشغيل `ghcr.io/kviklet/kviklet:main` لا تنسَ تعيين المنفذ `8080` وهو المنفذ الافتراضي الذي يعمل عليه Kviklet.
قد يبدو مثال تشغيل docker بهذا الشكل:```
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
SSO عبر OIDC / OAuth2
إذا كنت ترغب في إعداد تسجيل الدخول الموحد (SSO) لمثيل Kviklet الخاص بك (وهو أمر منطقي جدًا لأنه بخلاف ذلك سيتعين عليك إدارة كلمات المرور مرة أخرى). ستحتاج إلى إعداد هذه المتغيرات البيئية الثلاثة:``` KVIKLET_IDENTITYPROVIDER_CLIENTID KVIKLET_IDENTITYPROVIDER_CLIENTSECRET KVIKLET_IDENTITYPROVIDER_TYPE=google
معرف العميل وسر google يمكنك الحصول عليهما بسهولة باتباع تعليمات google هنا:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid
بالنسبة لعناوين URI الصالحة لإعادة التوجيه، يجب تكوين: https://[kviklet_host]/api/login/oauth2/code/google
بالنسبة للأصول المسموح بها، ببساطة عنوان URL الخاص بـ kviklet المستضاف.
بعد تعيين متغيرات البيئة هذه، يمكن لأي شخص في مؤسستك تسجيل الدخول باستخدام زر تسجيل الدخول عبر google. لكن لن يكون لديه أي صلاحيات افتراضياً، سيتعين عليك تعيين دور له بعد تسجيل دخوله مرة واحدة.
#### Keycloak
إذا كنت ترغب في إعداد SSO باستخدام Keycloak بدلاً من ذلك، فستحتاج إلى تعيين متغيرات البيئة الأربعة هذه:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]
تحصل على معرف العميل والسر عند إنشاء تطبيق في Keycloak. بالنسبة لعناوين URI الصالحة لإعادة التوجيه، يجب تكوين: https://[kviklet_host]/api/login/oauth2/code/keycloak بالنسبة للأصول المسموح بها، ببساطة عنوان URL الخاص بـ kviklet المستضاف.
بعد تعيين متغيرات البيئة هذه، يجب أن تظهر صفحة تسجيل الدخول زر "تسجيل الدخول باستخدام Keycloak" يعيد التوجيه إلى مثيل keycloak الخاص بك. في الإصدار المؤسسي، يمكنك تمكين مزامنة الأدوار لمزامنة الأدوار تلقائيًا من مثيل keycloak إلى kviklet. راجع قسم مزامنة الأدوار لمزيد من التفاصيل.
GitHub (تجريبي)
تجريبي: مصادقة GitHub جديدة و لا تدعم مزامنة الأدوار بعد — كل مستخدم جديد يصل بدور افتراضي ويجب تعيين الأدوار يدويًا.
GitHub ليس متوافقًا مع OIDC (إنه OAuth 2.0 خالص)، لذلك لديه دعم مخصص في Kviklet. قم بتعيين متغيرات البيئة هذه:``` 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 للصفحة الرئيسية: عنوان URL المستضاف لـ Kviklet الخاص بك
`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` **مطلوب** (يرفض Kviklet البدء بدونه). لا يمكن لتطبيقات GitHub OAuth تقييد من يقوم بتدفق OAuth، لذلك يقوم Kviklet باستدعاء `/user/orgs` بعد المصادقة ويرفض المستخدمين الذين ليسوا أعضاءً في منظمة واحدة على الأقل مدرجة في القائمة البيضاء (غير حساس لحالة الأحرف، يتم التحقق من أول 100 منظمة).
لكي يتحقق فحص المنظمة من عضوية المستخدم، يجب على المستخدم النقر على **Grant** (أو **Request**) بجوار كل منظمة مدرجة في القائمة البيضاء على شاشة موافقة OAuth. إذا كانت المنظمة قد فعّلت "Restrict third-party OAuth applications"، فيجب على مالك المنظمة أيضًا الموافقة على تطبيق OAuth مرة واحدة قبل أن تصبح عضوية أي عضو مرئية.
يطلب Kviklet نطاقات `read:user` و `user:email` و `read:org`. تتم قراءة رسائل البريد الإلكتروني دائمًا من `/user/emails` ويتم قبول إدخال `primary && verified` فقط، لذلك لا يزال المستخدمون الذين لديهم عناوين بريد إلكتروني خاصة قادرين على تسجيل الدخول بنجاح.
#### مزودو OIDC الآخرون
يجب أن تعمل مزودات OIDC المتوافقة الأخرى (GitLab, Auth0, Okta, etc.) بشكل مشابه لـ Keycloak. لاحظ أن `redirect URI` ستتغير حسب النوع الذي تختاره، لذلك إذا اخترت `gitlab` فسيكون `https://[kviklet_host]/api/login/oauth2/code/gitlab`.
إذا واجهت مشكلات، فلا تتردد في إنشاء مشكلة (issue)، فلم نجرب كل مزود 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: اضبط علىtrueلتمكين مصادقة LDAP.LDAP_URL: عنوان URL لخادم LDAP الخاص بك.LDAP_BASE: DN الأساسي لعمليات البحث في LDAP.LDAP_PRINCIPAL: DN للمستخدم المسؤول للربط بخادم LDAP.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`: قم بتعيينه إلى `true` لتفعيل مصادقة SAML
- `SAML_ENTITYID`: معرف الكيان الخاص بموفر هوية SAML الخاص بك
- `SAML_SSOSERVICELOCATION`: عنوان URL لخدمة SSO لموفر الهوية الخاص بك
- `SAML_VERIFICATIONCERTIFICATE`: شهادة X.509 المستخدمة للتحقق من استجابات SAML (قم بتضمين أسطر BEGIN/END CERTIFICATE)
يمكنك اختياريًا تخصيص تعيينات سمات SAML:```
SAML_USERATTRIBUTES_EMAILATTRIBUTE=email
SAML_USERATTRIBUTES_NAMEATTRIBUTE=name
SAML_USERATTRIBUTES_IDATTRIBUTE=nameID
يجب تكوين مزود الهوية الخاص بك باستخدام:
- معرف الكيان:
https://[kviklet_host]/api/saml2/service-provider-metadata/saml - رابط إعادة التوجيه:
https://[kviklet_host]/api/login/saml2/sso/saml
بعد تكوين SAML، يمكن للمستخدمين تسجيل الدخول عبر مزود الهوية. عند تسجيل الدخول لأول مرة، يتم إنشاء حساب مستخدم بصلاحيات افتراضية.
إذا تمت إعادة توجيهك بشكل صحيح إلى IDP ولكنك تواجه خطأ cors، يمكنك إضافة مضيف IDP الخاص بك إلى الأصول المسموح بها في Kviklet عبر:``` CORS_ALLOWEDORIGINS=https://[idp_host]
## الإعدادات
### الاتصالات
بعد تشغيل Kviklet، يجب أولاً تكوين اتصال بقاعدة البيانات. اذهب إلى الإعدادات -> قواعد البيانات -> إضافة اتصال.
هنا يمكنك تكوين متطلبات المراجعة وحدود التنفيذ لكل اتصال. راجع [بوابات المراجعة](#review-gates) للتفاصيل.
#### مصادقة AWS IAM
يدعم Kviklet استخدام مصادقة IAM لاتصالات قواعد بيانات Postgres و MySQL، لذلك اختر مصادقة IAM عند إنشاء اتصال جديد.
سيؤدي ذلك إلى إزالة خيار تعيين كلمة مرور واستخدام بيانات اعتماد AWS بدلاً من ذلك للاتصال بقاعدة البيانات.
يستخدم Kviklet موفر `DefaultCredentialsProvider` الخاص بـ AWS للعثور على بيانات الاعتماد وإنشاء الرمز المميز للاتصال. هذا يعني أن جميع الأماكن المعتادة يجب أن تعمل (متغيرات البيئة أو أدوار المثيل المرتبطة) والترتيب الدقيق موثق هنا: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html
بالإضافة إلى ذلك، يمكنك توفير ARN دور AWS سيفترضه Kviklet، واستخدام تلك البيانات الاعتماد لإنشاء رمز DB المؤقت. هذا مفيد بشكل خاص للاتصال بقواعد البيانات التي ليست في نفس حساب AWS مثل Kviklet. لاستخدام هذه الميزة، ما عليك سوى إدخال ARN الدور في الحقل المخصص عند إنشاء أو تعديل اتصال مصادقة IAM. سيؤدي ترك الحقل فارغًا إلى استخدام موفر بيانات الاعتماد الافتراضي (بدون افتراض دور).
يتم استنتاج منطقة AWS لاستخدامها أثناء إنشاء الرمز المميز من عنوان URL للاتصال الخاص بك، لذلك لا توجد خيارات لتعيينها.
لمعرفة كيفية إعداد مصادقة IAM لقاعدة البيانات الخاصة بك، اتبع وثائق AWS الرسمية: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
النقطتان الرئيسيتان هما:
- إنشاء مستخدم DB مع خيار مصادقة IAM والأذونات الصحيحة
- إنشاء سياسة IAM تسمح لكيان AWS بإنشاء رموز مميزة لهذا المستخدم
### بوابات المراجعة
بشكل افتراضي، يسمح Kviklet بتكوين بسيط لعدد المراجعات. يمكنك تكوين عدد الموافقات التي يحتاجها الطلب على اتصال معين قبل أن يتم تنفيذه.
يتم حساب حالة الموافقة للطلب بناءً على أحدث إجراء لكل مراجع. إذا وافق مراجع ثم طلب تغييرات، يتم احتساب طلب التغيير فقط — وتُلغى موافقته السابقة. يؤدي تحرير الطلب دائمًا إلى إعادة تعيين جميع الموافقات السابقة، مما يضمن عدم تنفيذ أي تغييرات دون مراجعتها أولاً. وبالمثل، إذا فشل التنفيذ (مثلًا بسبب خطأ في بناء جملة SQL)، يتم إعادة تعيين الموافقات بحيث يمكن تصحيح الطلب وإعادة الموافقة عليه دون الحاجة إلى إنشاء طلب جديد.
يمكنك أيضًا تكوين حد **أقصى لعمليات التنفيذ** لكل اتصال للتحكم في عدد المرات التي يمكن فيها تنفيذ طلب موافق عليه. القيمة الافتراضية هي 1. تعيين هذا على 0 يسمح بعمليات تنفيذ غير محدودة. عمليات التنفيذ الفاشلة لا تُحتسب ضمن هذا الحد.
#### متطلبات مراجعة قائمة على الأدوار (Enterprise)
مع ترخيص Kviklet Enterprise، يمكنك تكوين اتصالات فردية لتتطلب موافقات من مستخدمين بأدوار محددة. يتيح لك هذا، على سبيل المثال، طلب موافقة من الفريق الذي يحافظ على قاعدة بيانات معينة أو حماية الاتصالات الحساسة خلف موافقات مسؤول قاعدة البيانات أو الإدارة.
**كيف يعمل:**
لكل اتصال عدد **إجمالي للمراجعات المطلوبة** (`numTotalRequired`) يعمل كحد أدنى — وهو الحد الأدنى لعدد الموافقات المتميزة المطلوبة بغض النظر عن الأدوار. بالإضافة إلى ذلك، يمكنك إضافة **متطلبات الدور** التي تحدد عدد الموافقات التي يجب أن تأتي من مستخدمين بدور معين (مثلًا، "1 من مسؤول قاعدة البيانات، 1 من الأمن").
تتم الموافقة على الطلب فقط عند استيفاء كلا **الشرطين**:
- يفي العدد الإجمالي للموافقات المتميزة بـ `numTotalRequired`
- يتم تلبية كل متطلب دور بشكل فردي
إذا كان المستخدم ينتمي إلى أدوار متعددة، فإن موافقة واحدة من ذلك المستخدم تُحتسب لجميع متطلبات الدور المتطابقة. ومع ذلك، فإنها لا تزال تُحتسب كموافقة واحدة فقط تجاه العدد الإجمالي.
**مثال:** يتطلب اتصال 3 موافقات إجمالية بما في ذلك 1 من مسؤول قاعدة البيانات و1 من الأمن. مستخدم لديه كل من دوري مسؤول قاعدة البيانات والأمن يوافق — هذا يلبي كلا متطلبي الدور لكنه يُحتسب فقط كـ 1 من الموافقات الثلاث الإجمالية المطلوبة. لا تزال هناك حاجة لموافقتين إضافيتين من أي مستخدمين.
إذا انتهت صلاحية ترخيص المؤسسة الخاص بك، تظل متطلبات المراجعة القائمة على الأدوار الحالية مفروضة ولكن لا يمكن تعديلها بعد الآن. يمكنك فقط إزالتها للعودة إلى تكوين المراجعات الإجمالي البسيط.
### الأدوار
يأتي Kviklit مزودًا بـ 3 أدوار: الافتراضي، المسؤولون، والمطورون.
- يوفر الدور الافتراضي وصول قراءة إلى جميع الاتصالات والطلبات. يتم تعيين هذا الدور لكل مستخدم ولا يمكن إزالته. يمكنك مع ذلك تغيير أذونات هذا الدور كما تريد.
- يتمتع المسؤولون بصلاحية إنشاء وتحرير الاتصالات، بالإضافة إلى إضافة مستخدمين جدد وتعيين أذوناتهم.
- يمكن للمطورين إنشاء الطلبات وكذلك الموافقة عليها والتعليق عليها وبالطبع تنفيذ العبارات الفعلية.
يمكنك تخصيص الأدوار، على سبيل المثال، إعطاء دور وصولًا فقط إلى اتصال معين أو مجموعة من اتصالات قواعد البيانات.
هذا مفيد، على سبيل المثال، إذا كان لديك فرق مختلفة مع قواعد بيانات مختلفة وتريد التحكم في الوصول إلى تلك القواعد بشكل أكثر دقة.
#### إنشاء دور جديد
يعمل إنشاء دور جديد على النحو التالي. اذهب إلى الإعدادات -> الأدوار -> إضافة دور.
الإعدادات الافتراضية ليست ذات صلة بمعظم الأدوار، ويمكنك فقط منح المستخدم وصول قراءة وواجهة عرض الأدوار واترك الأمر عند هذا الحد.
الأكثر إثارة للاهتمام هو إضافة أذونات فردية للاتصالات. هنا تقوم أولاً بإضافة محدد لتحديد اتصالات معينة. يمكن أن يكون هذا إما معرفًا محددًا أو يمكنك استخدام أحرف البدل مع `*` لمطابقة اتصالات متعددة. على سبيل المثال، إذا كنت تريد دورًا لديه وصول إلى جميع قواعد بيانات التطوير (في حال كنت تدير الوصول إليها أيضًا باستخدام kviklet)، فستستخدم محددًا مثل `dev-*` وتأكد من تعيين معرفات الاتصالات بشكل صحيح.
يمكنك بالطبع أيضًا ابتكار نظام تستخدمه لفرقك المختلفة داخل مؤسستك.
### مزامنة الأدوار (Enterprise)
مزامنة أدوار المستخدمين تلقائيًا من مجموعات موفر الهوية الخاص بك. تتطلب هذه الميزة ترخيص Enterprise.
**التكوين** يتم في الإعدادات > مزامنة الأدوار:
- **تمكين مزامنة الأدوار**: تشغيل/إيقاف المزامنة
- **وضع المزامنة**:
- **مزامنة كاملة** - تتطابق أدوار المستخدم تمامًا مع تعيينات مجموعات IdP (بالإضافة إلى الدور الافتراضي)
- **إضافي** - تضيف مجموعات IdP أدوارًا ولكنها لا تزيل الأدوار الموجودة
- **تسجيل الدخول الأول فقط** - تتم مزامنة الأدوار فقط عند تسجيل الدخول الأول، ويتم الاحتفاظ بالتغييرات اليدوية بعد ذلك
- **سمة المجموعات**: سمة IdP التي تحتوي على عضويات المجموعة (الافتراضي: `groups`)
- **تعيينات الأدوار**: قم بتعيين أسماء مجموعات IdP (مثلًا، `engineering`) إلى أدوار Kviklet
#### إعداد OIDC
قم بتكوين موفر OIDC الخاص بك ليشمل مطالبة `groups` في الرمز المميز للهوية:
- **Keycloak**:
لا يتضمن Keycloak المجموعات في الرموز المميزة افتراضيًا، لذا ستحتاج إلى إضافة مخطط للعميل.
1. انتقل إلى **Clients** في القائمة اليسرى
2. حدد عميل Kviklet الخاص بك
3. اذهب إلى علامة التبويب **Client scopes**
4. انقر على النطاق المخصص (مثلًا، `kviklet-dedicated`)
5. اذهب إلى علامة التبويب **Mappers**
6. انقر على **Add mapper** → **By configuration**
7. حدد **Group Membership**
8. قم بتكوين المخطط:
| الإعداد | القيمة |
|---------|-------|
| الاسم | `groups` |
| اسم مطالبة الرمز المميز | `groups` |
| مسار المجموعة الكامل | **إيقاف** |
| إضافة إلى رمز الهوية | **تشغيل** |
| إضافة إلى رمز الوصول | **تشغيل** |
| إضافة إلى معلومات المستخدم | **تشغيل** |
9. انقر على **Save**
> **هام:** يجب أن يتطابق "اسم مطالبة الرمز المميز" مع "سمة المجموعات" المكونة في إعدادات مزامنة الأدوار في Kviklet (الافتراضي: `groups`).
- **موفرو OIDC الآخرون**: أضف مخططًا/مطالبة للمجموعات تتضمن عضويات مجموعة المستخدم في الرمز المميز للهوية. يتم ذلك عادةً في واجهة إدارة الموفر.
إذا واجهت مشكلات، فلا تتردد في إنشاء مشكلة، لم نجرب كل موفر OIDC موجود (حتى الآن) وقد تكون هناك اختلافات طفيفة في التنفيذ قد تتطلب تحديثات من جانب Kviklet.
#### إعداد LDAP
تستخدم مزامنة أدوار LDAP السمة `memberOf`:
1. تأكد من أن خادم LDAP الخاص بك لديه وظيفة `memberOf` الإضافية ممكّنة
2. قم بتعيين **سمة المجموعات** إلى `memberOf` في Kviklet
3. ثم يتم استخراج أسماء المجموعات من سمة `memberOf` في سمات المستخدمين.
#### إعداد SAML
قم بتكوين موفر هوية SAML الخاص بك ليشمل المجموعات في التأكيد:
1. أضف بيان سمة يقوم بتعيين عضويات مجموعة المستخدم
2. قم بتعيين **سمة المجموعات** في Kviklet لتطابق اسم سمة SAML الخاصة بك
3. ثم يتم استخراج أسماء المجموعات من سمة SAML في سمات المستخدمين.
### الإشعارات
يمكنك تكوين Kviklet لإرسال الإشعارات إلى قناة في Slack أو Teams. هذا مفيد لإخطار فريقك بالطلبات الجديدة التي تحتاج إلى مراجعة. يمكنك تكوين ذلك في الإعدادات -> عام -> إعدادات الإشعارات.
#### Slack
لتكوين إشعارات Slack، تحتاج إلى إنشاء تطبيق Slack وتمكين webhooks له. يمكنك اتباع التعليمات هنا: https://api.slack.com/messaging/webhooks
#### Teams
تستخدم إشعارات Teams webhook **سير عمل** Power Automate. يرسل Kviklet بطاقة تكيفية (Adaptive Card) ينشرها قالب webhook في قناتك.
**موصى به: استخدم قالب سير العمل**
1. في Teams، افتح القناة التي تريد الإشعارات فيها، وانقر على **...** بجانب اسم القناة واختر **Workflows** (أو أضف تطبيق **Workflows**).
2. ابحث عن قالب **"Send webhook alerts to a channel"** وأنشئه.
3. سجل الدخول عند الطلب، ثم حدد الفريق والقناة الهدف وأنشئ سير العمل.
4. افتح خطوة المشغل وانسخ عنوان **HTTP POST URL** الذي تم إنشاؤه.
5. الصق عنوان URL في Kviklet ضمن الإعدادات -> عام -> إعدادات الإشعارات وانقر على حفظ.
**بديل: قم ببناء سير العمل يدويًا**
إذا كنت تفضل بناء التدفق بنفسك (أو إذا كان القالب غير متاح):
1. القناة **...** -> **Workflows** -> أنشئ تدفقًا مع المشغل **"When a Teams webhook request is received"**.
2. أضف الإجراء **Microsoft Teams -> "Post card in a chat or channel"**.
3. عيّن حقل **Adaptive Card** للإجراء إلى التعبير `string(triggerBody())` بحيث ينشر البطاقة التي يرسلها Kviklet.
4. حدد الفريق والقناة الهدف، ثم **Save**، وانسخ عنوان **HTTP POST URL** من خطوة المشغل.
توجد حاليًا إشعارات لـ:
- الطلبات الجديدة التي تحتاج إلى موافقات
- الموافقات الجديدة على الطلبات
#### تكوين عنوان URL الأساسي
عند تشغيل Kviklet خلف وكيل عكسي أو Kubernetes Ingress، قد تستخدم روابط الإشعارات عنوان IP الداخلي بدلاً من النطاق العام الخاص بك. يحاول Kviklet تتبع عنوان URL الصحيح من خلال النظر في الطلبات الواردة ولكن بعض الوكلاء العكسيين لا يقومون بتعيين رؤوس Forwarded بشكل صحيح. لإصلاح ذلك، قم بتعيين عنوان URL الأساسي بشكل صريح:```
KVIKLET_BASE_URL=https://kviklet.example.com
يضمن ذلك أن جميع روابط الإشعارات تشير إلى عنوان URL العام الصحيح.
التسجيل
بشكل افتراضي، يكتب Kviklet سجلات قابلة للقراءة البشرية (جميلة) إلى stdout، وهو مناسب عند قراءتها مباشرة أو عبر docker logs.
إذا قمت بإرسال السجلات إلى نظام مركزي (Elasticsearch، Loki، Datadog، CloudWatch، ...) يمكنك التبديل إلى سجلات JSON المنظمة بدلاً من ذلك، وهي أسهل في الفهرسة والاستعلام. اضبط التنسيق عبر متغير بيئة:```
One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs
## التشفير
إذا كنت لا ترغب في تخزين بيانات الاعتماد كنص واضح في قاعدة البيانات، فمن المستحسن أن تقوم بتمكين تشفير قاعدة البيانات على قاعدة بيانات Kviklet postgres نفسها. بالنسبة لمعظم مقدمي الخدمات المستضافة، هذا مجرد مربع اختيار بسيط للنقر عليه.
ومع ذلك، إذا تم اختراق قاعدة بيانات Kviklet بأي شكل من الأشكال، فهذا يشكل خطرًا أمنيًا كبيرًا. لأنها تحتوي على بيانات اعتماد قاعدة البيانات لجميع مخازن البيانات الإنتاجية المحتملة لديك. لذا يمكنك تمكين تشفير بيانات الاعتماد في حالة السكون.
لفعل ذلك، ببساطة قم بتعيين متغيري البيئة.```
ENCRYPTION_ENABLED=true
ENCRYPTION_KEY_CURRENT=some-secret
سوف يقوم Kviklet بتشفير جميع بيانات الاعتماد الحالية لديك عند بدء التشغيل، وسيستخدم السر للاتصالات المستقبلية التي تقوم بإنشائها.
تدوير المفتاح
إذا كنت ترغب في تدوير المفتاح، يمكنك ببساطة إضافة متغير آخر للمفتاح السابق وتغيير المفتاح الحالي:``` ENCRYPTION_KEY_PREVIOUS=some-secret ENCRYPTION_KEY_CURRENT=another-secret
سوف يقوم Kviklet بإعادة تشفير جميع الاتصالات عند بدء التشغيل، بحيث يمكنك بعد ذلك إعادة تشغيل الحاوية مع إزالة المفتاح السابق.
## مفاتيح API
يدعم Kviklet مفاتيح API للوصول البرمجي إلى النظام. هذه ميزة خاصة بالمؤسسات وتتطلب ترخيصًا صالحًا. يمكنك إنشاء مفاتيح API في قسم الإعدادات -> مفاتيح API.
استخدمها على النحو التالي:```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 في الإصدارات المستقبلية.
في النهاية، الحقيقة في الكود، لذا يمكنك دائمًا النظر إلى المتحكم (controller) لترى كيف يتم تعريف API. إذا كان لديك أي أسئلة، فلا تتردد في فتح مشكلة (issue).
الميزات التجريبية
يوجد حاليًا ميزتان تجريبيتان. تم بناؤها في الغالب بناءً على ملاحظات المجتمع. لا تتردد في تجربتها وترك أي مدخلات قد تكون لديك. نأمل في تطوير هذا الأمر في المستقبل وجعله يعمل بشكل جيد مع تدفق الموافقة الأساسي.
Kubernetes Exec
إذا كنت ترغب في استخدام ميزة Kubernetes Exec، فيجب عليك إنشاء اتصال Kubernetes منفصل. سيستخدم Kviklet مستخدم pod المنشور لتنفيذ الأمر. لذا تأكد من أن المستخدم لديه الأذونات اللازمة لتنفيذ الأوامر على pods التي تريد الوصول إليها.
يستخدم Kviklet أيضًا /bin/sh لتنفيذ الأمر، لذا ستحتاج إلى التأكد من أن pods لديك تحتوي على shell أو على الأقل رابط رمزي (symlink) في /bin/sh. إذا كان هذا يزعجك، فلا تتردد في فتح مشكلة (issue)، يمكننا جعل هذا قابلاً للتكوين أو إيجاد حل آخر.
تنتظر أوامر Kubernetes 5 ثوانٍ فقط للحصول على مخرجات؛ إذا استغرق الأمر أكثر من ذلك، سينتظر Kviklet لمدة تصل إلى ساعة قبل انتهاء مهلة الأمر. هذا حل مؤقت، ونحن نبحث في websockets لجعل هذا أكثر استجابة وربما تمكين جلسات الطرفية.
الوكيل (Proxy)، Postgres فقط
إذا قمت بإنشاء طلبات للوصول المؤقت، يمكنك - بدلاً من استخدام الواجهة web - تشغيل استعلاماتك من خلال وكيل (proxy) مُدار بواسطة kviklet واستخدام عميل قاعدة البيانات الذي تختاره. لهذا، يستخدم الحاوية المنافذ 5438-6000، لذا تحتاج إلى فضحها. يمكن للمستخدم بعد ذلك إنشاء طلب وصول مؤقت، والنقر على "Start Proxy" بمجرد الموافقة عليه. سيحصل كل طلب على منفذ ومستخدم + كلمة مرور مؤقتة. بهذا يمكنهم الاتصال بقاعدة البيانات. يتحقق Kviklet من صحة المستخدم وكلمة المرور المؤقتين ويوكل (proxies) جميع الطلبات إلى المستخدم الأساسي على قاعدة البيانات. يتم تسجيل أي تعليمات منفذة في سجل التدقيق (auditlog) كما لو تم تشغيلها عبر الواجهة web. لاحظ أن تحليل الرسائل على جانب الوكيل لم يتم اختباره مع جميع العملاء، لذا إذا واجهت مشاكل مثل عدم تسجيل التعليمات، فلا تتردد في فتح مشكلة (issue).
وكيل Postgres - 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.
أسئلة؟ مساهمات؟
إذا كانت لديك أي أسئلة، أو تريد تقديم ملاحظات، أو تحتاج إلى مساعدة في الإعداد، انضم إلى مجتمع Discord. يمكنك أيضًا إنشاء مشكلة على GitHub للإبلاغ عن الأخطاء وطلب الميزات.
إذا كنت ترغب في المساهمة، فلا تتردد في عمل fork وإنشاء PRs للأشياء الصغيرة. إذا كنت تخطط لميزات أكبر، فسأقدر بعض النقاش المسبق في مشكلة على GitHub أو على Discord.
يمكنك أيضًا الاتصال بي على [email protected].