dex app
v1.42.13
Dex هي خدمة هوية تستخدم OpenID Connect للتعامل مع مصادقة Kubernetes. وهو يتصل بموفري هوية الطرف الثالث مثل Active Directory وLDAP وGitHub. في حين أن خادم Kubernetes API يدعم فقط موفر هوية واحد ومصدر رمز OIDC، فإن استخدام Dex يسمح باستخدام الهويات من موفري خدمات مختلفين عند المصادقة لـ Kubernetes.
يتم تثبيت هذا التطبيق في مجموعات إدارة Giant Swarm بشكل افتراضي وهو جاهز أيضًا للنشر في مجموعات عبء العمل.
بالإضافة إلى Dex نفسه، يوفر هذا التطبيق Dex K8s Authenticator، الذي يساعد في تكوين kubectl للمجموعات التي تمت مصادقتها عبر Dex.
هناك عدة طرق لتثبيت هذا التطبيق.
يمكنك تقديم التكوين الخاص بك عبر ملف values.yaml المخصص. فيما يلي مثال لاستخدام الموصل لـ Azure Active Directory. يمكن العثور على المزيد من أمثلة الموصلات أدناه.
isWorkloadCluster : true
services :
kubernetes :
api :
caPem : |
-----BEGIN CERTIFICATE-----
M...=
-----END CERTIFICATE-----
oidc :
expiry :
signingKeys : 6h
idTokens : 30m
customer :
connectors :
- id : customer
connectorName : test
connectorType : microsoft
connectorConfig : |-
clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
tenant: <TENANT-SET-SET-IN--YOUR-IdP>
redirectURI: https://dex.<CLUSTER>.<BASEDOMAIN>/callbackبعض الملاحظات:
.service.kubernetes.api.caPem هي شهادة CA لمجموعة أحمال العمل الخاصة بك بتنسيق PEM. في Giant Swarm، يمكنك استرداد هذه الشهادة عبر أمر تسجيل الدخول kubectl gs، عند إنشاء شهادة عميل لمجموعة أحمال العمل. وينتهي الأمر في نموذج مشفر بـ Base46 في ملف التكوين kubectl الخاص بك. شهادة CA مطلوبة بواسطة Dex K8s Authenticator.
يجب أن يحتوي redirectURI الموجود في تكوين الموصل على اسم المضيف المناسب لإدخال Dex الخاص. في النموذج الافتراضي، يحتوي على اسم مجموعة حمل العمل (استبدل <CLUSTER> بالاسم الفعلي) ومجال أساسي (استبدل <BASEDOMAIN> بالمجال الأساسي المناسب).
إذا قمت بتكوين أكثر من موصل واحد، فتأكد من تعيين id فريد لكل موصل. انتبه إلى أن هذا الإصدار من Dex تم تكوينه ليبدأ كافة أسماء مجموعات المستخدمين بمعرف الموصل. لذا، إذا كان id الموصل الخاص بك هو customer ، فستظهر العضوية في مجموعة devops كـ customer:devops .
مثال لتكوين الموصل لـ Keycloak:
- id : customer
connectorName : test
connectorType : oidc
connectorConfig : |-
clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
insecureEnableGroups: true
scopes:
- email
- groups
- profile
issuer: https://<IDP_ENDPOINT>/auth/realms/master
redirectURI: https://dex.<CLUSTERID>.<BASEDOMAIN>/callbackمثال لتكوين الموصل لـ GitHub:
- id : customer
connectorName : test
connectorType : github
connectorConfig : |-
clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
loadAllGroups: false
teamNameField: slug
orgs:
- name: <GITHUB_ORG_NAME>
teams:
- <GITHUB_TEAM_SLUG>
redirectURI: https://dex.<CLUSTERID>.<BASEDOMAIN>/callbackملحوظة:
<GITHUB_ORG_NAME> هو اسم مؤسستك في GitHub. على سبيل المثال، الجزء myorg في https://github.com/myorg .<GITHUB_TEAM_SLUG> هو جزء من عنوان URL للفريق الذي يمثل اسم الفريق. على سبيل المثال، جزء my-team في https://github.com/orgs/myorg/teams/my-team . يتم تثبيت التطبيق في مجموعات عبء العمل، عبر النظام الأساسي للتطبيق الخاص بنا. قبل القيام بذلك، يرجى إنشاء مورد ConfigMap التالي في مساحة الاسم المسماة بعد مجموعة حمل العمل لتوفير محتويات ملف values.yaml الخاص بك.
apiVersion : v1
kind : ConfigMap
metadata :
name : dex-app-user-values
namespace : <CLUSTER>
data :
values : |
<content of values.yaml>بعد ذلك، يمكنك إما تثبيت التطبيق عبر واجهة مستخدم الويب الخاصة بنا، أو ستقوم بإنشاء مورد التطبيق بالتنسيق التالي:
apiVersion : application.giantswarm.io/v1alpha1
kind : App
metadata :
labels :
app.kubernetes.io/name : dex-app
name : dex-app
namespace : <CLUSTER>
spec :
catalog : giantswarm-playground
name : dex-app
namespace : dex
userConfig :
configMap :
name : <CONFIGMAPNAME>
namespace : <CLUSTER>ملحوظات:
<CONFIGMAPNAME> باسم مورد ConfigMap الموضح أعلاه.<CLUSTER> باسم مجموعة حمل العمل الخاصة بك.ونتيجة لذلك، من المفترض أن ترى Dex منتشرًا في مجموعة أحمال العمل الخاصة بك.
يعرض تطبيق Dex واجهة ويب يمكن الوصول إليها عبر https. ولذلك، فإنه يقوم بإنشاء مدخل، والذي يحتاج إلى تكوينه باستخدام شهادة TLS موقعة من قبل مرجع مصدق، والذي يجب أن تثق به المتصفحات. يتكون التطبيق من عدة مكونات، والتي تحتاج أيضًا إلى أن تكون قادرة على التواصل مع بعضها البعض داخليًا عبر https. لذا فإن المرجع المصدق الذي يوقع الشهادات يجب أن تكون موثوقًا به من خلال مكونات التطبيق الفردية أيضًا.
في حالة استخدام مرجع مصدق مخصص، يجب أن يتم عرضه على مكونات التطبيق الفردية وتعيينه كموثوق، وإلا فلن تتمكن المكونات من التواصل مع بعضها البعض وقد لا يعمل التطبيق كما هو متوقع. استنادًا إلى إعداد المجموعة، يمكن تحقيق ذلك من خلال توفير مجموعة إضافية من القيم لتكوين التطبيق:
ingress :
tls :
letsencrypt : false
caPemB64 : " base64-encoded CA certificate " ingress :
tls :
letsencrypt : false
trustedRootCA :
name : " name-of-the property-in-the-secret "
secretName : " name-of-the-custom-ca-secret "letsencrypt ، سيتم إنشاء سر يسمى dex-tls ونشره باستخدام القيم المشفرة بـ b64 التي يقدمها المستخدم. وبدلاً من ذلك، يمكن للمستخدم إدارة إنشاء هذا السر بنفسه وتمكين استخدامه على النحو التالي: ingress :
tls :
letsencrypt : false
externalSecret :
enabled : true يجب بعد ذلك تطبيق السر التالي على مساحة الاسم التي يعمل بها dex :
apiVersion : v1
kind : Secret
type : kubernetes.io/tls
metadata :
name : dex-tls
data :
ca.crt : ...
tls.crt : ...
tls.key : ...في حالة احتياج حركة المرور إلى Dex إلى المرور عبر وكيل (على سبيل المثال، عند تثبيت التطبيق في مجموعة خاصة)، يجب إعداد المكونات الفردية للتطبيق لاستخدام الوكيل.
يمكن توفير إعداد الوكيل للتطبيق في قسم محدد من خريطة تكوين قيم المستخدم أو السر مع تكوين التطبيق:
cluster :
proxy :
http : " https://proxy.host:4040 " # hostname of the proxy for HTTP traffic
https : " https://proxy.host:4040 " # hostname of the proxy for HTTPS traffic
noProxy : " kubernetes-api-ip-range " # comma-separated list of hostnames and IP ranges, whose traffic should not go through the proxy. # Kubernetes API IP range needs to be defined here in order for Dex to work correctly بالإضافة إلى عدد قليل من العملاء الثابتين المحددين مسبقًا، يدعم تطبيق Dex إمكانية تحديد عملاء ثابتين مخصصين أيضًا. يجب تعريفها على أنها مصفوفة من الكائنات في خاصية محددة لملف التكوين yaml المسمى extraStaticClients . بنية كل كائن عميل ثابت مخصص هي نفسها تمامًا كما في Dex المنبع:
extraStaticClients :
- id : " client-id "
secret : " client-secret "
trustedPeers :
- " https://example.com "
public : true
name : " client-name-1 "
logoURL : " https://example.com/logo "
- idEnv : " CLIENT_ID "
secretEnv : " CLIENT_SECRET "
redirectURIs :
- " https://example.com/redirect "
name : " client-name-2 "ملحوظات:
id و idEnv متنافيةsecret و secretEnv متنافيةnameid أو idEnvsecret أو secretEnvيمكن أيضًا تكوين العملاء الثابتين الإضافيين كأقران موثوقين للعملاء الثابتين المحددين مسبقًا:
أضف معرف العميل الثابت الإضافي إلى قائمة trustedPeers في العميل الثابت المحدد مسبقًا:
staticClients :
dexK8SAuthenticator :
clientAddress : " dex.installation.basedomain.io "
clientSecret : " default-client-dex-authenticator-secret "
trustedPeers :
- " client-id "
extraStaticClients :
- id : " client-id "
name : " client-name-1 "
secret : " client-secret "سوف ينتج نفس التكوين:
staticClients :
- id : dex-k8s-authenticator
name : dex-k8s-authenticator
secret : default-client-dex-authenticator-secret
trustedPeers :
- client-id
- id : client-id
name : client-name-1
secret : client-secret
public : trueيتم منع التكرارات في حالة تساوي معرف أي نظير موثوق به مع معرف نظير موثوق به يتم تعبئته مسبقًا تلقائيًا.
يقوم Giant Swarm حاليًا ببناء تطبيق dex من شوكة المشروع الأصلي. نقوم بتنفيذ منطق إضافي يضيف معرف الموصل كبادئة لمجموعات المستخدمين. من أجل تحديث الصورة المستخدمة في هذا المخطط، يلزم حاليًا القيام بالخطوات التالية في مستودع الشوكة الخاص بنا:
ثم في هذا الريبو:
values.yaml ، تأكد من تحديث values.schema.json ليعكس جميع القيم وأنواعها بشكل صحيح.master#release#v<major.minor.patch> ، وانتظر حتى يتم إنشاء الإصدار المطابق PR، ثم وافق عليه، ثم ادمجه.
