استخدام Azure RBAC على مجموعات Kubernetes الممكنة في Azure Arc
تساعد أنواع كائنات Kubernetes ClusterRoleBinding و RoleBinding على تحديد التخويل في Kubernetes أصلا. باستخدام هذه الميزة، يمكنك استخدام معرف Microsoft Entra وتعيينات الأدوار في Azure للتحكم في عمليات التحقق من التخويل على نظام المجموعة. تتيح لك تعيينات دور Azure التحكم بشكل دقيق في المستخدمين الذين يمكنهم قراءة كائنات Kubernetes وكتابتها وحذفها مثل النشر والجراب والخدمة.
للحصول على نظرة عامة تصورية لهذه الميزة، راجع Azure RBAC على Kubernetes التي تدعم Azure Arc.
المتطلبات الأساسية
تثبيت أو ترقية Azure CLI إلى أحدث إصدار.
تثبيت أحدث إصدار من
connectedk8s
ملحق Azure CLI:az extension add --name connectedk8s
إذا كان الملحق
connectedk8s
مثبتا بالفعل، يمكنك تحديثه إلى أحدث إصدار باستخدام الأمر التالي:az extension update --name connectedk8s
الاتصال مجموعة Kubernetes موجودة ممكنة ل Azure Arc:
- إذا لم تكن قد قمت بتوصيل نظام مجموعة حتى الآن، فاستخدم تشغيل سريع الخاص بنا.
- ترقية وكلائك إلى أحدث إصدار.
إشعار
لا يمكنك إعداد هذه الميزة ل Red Hat OpenShift، أو لعروض Kubernetes المدارة لموفري السحابة مثل Elastic Kubernetes Service أو Google Kubernetes Engine حيث لا يمتلك المستخدم حق الوصول إلى خادم API للمجموعة. بالنسبة لمجموعات Azure Kubernetes Service (AKS)، تتوفر هذه الميزة في الأصل ولا تتطلب توصيل نظام مجموعة AKS ب Azure Arc.
تمكين Azure RBAC على نظام المجموعة
احصل على هوية MSI لنظام المجموعة عن طريق تشغيل الأمر التالي:
az connectedk8s show -g <resource-group> -n <connected-cluster-name>
احصل على المعرف (
identity.principalId
) من الإخراج وقم بتشغيل الأمر التالي لتعيين دور قارئ الهوية المدارة لنظام المجموعة الاتصال على نظام المجموعة CheckAccess Reader إلى نظام المجموعة MSI:az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
تمكين التحكم في الوصول المستند إلى الدور Azure (RBAC) على مجموعة Kubernetes الممكنة في Azure Arc عن طريق تشغيل الأمر التالي:
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
إشعار
قبل تشغيل الأمر السابق، تأكد من أن
kubeconfig
الملف على الجهاز يشير إلى المجموعة التي ستقوم بتمكين ميزة Azure RBAC عليها.استخدم
--skip-azure-rbac-list
مع الأمر السابق لقائمة مفصولة بفاصلة من أسماء المستخدمين ورسائل البريد الإلكتروني واتصالات OpenID التي تخضع لعمليات التحقق من التخويل باستخدام Kubernetes الأصليClusterRoleBinding
والعناصرRoleBinding
بدلا من Azure RBAC.
نظام مجموعة عام حيث لا يعمل أي تسوية على المواصفات apiserver
SSH في كل عقدة رئيسية من نظام المجموعة واتخذ الخطوات التالية:
إذا كان الخاص بك
kube-apiserver
هو جراب ثابت:azure-arc-guard-manifests
يحتوي السر في مساحة الاسم علىkube-system
ملفين:guard-authn-webhook.yaml
وguard-authz-webhook.yaml
. انسخ هذه الملفات إلى/etc/guard
دليل العقدة.sudo mkdir -p /etc/guard kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml
apiserver
افتح البيان في وضع التحرير:sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
أضف المواصفات التالية ضمن
volumes
:- name: azure-rbac hostPath: path: /etc/guard type: Directory
أضف المواصفات التالية ضمن
volumeMounts
:- mountPath: /etc/guard name: azure-rbac readOnly: true
إذا كان الخاص بك
kube-apiserver
ليس جراب ثابت:apiserver
افتح البيان في وضع التحرير:sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
أضف المواصفات التالية ضمن
volumes
:- name: azure-rbac secret: secretName: azure-arc-guard-manifests
أضف المواصفات التالية ضمن
volumeMounts
:- mountPath: /etc/guard name: azure-rbac readOnly: true
أضف الوسيطات التالية
apiserver
:- --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml - --authentication-token-webhook-cache-ttl=5m0s - --authorization-webhook-cache-authorized-ttl=5m0s - --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml - --authorization-webhook-version=v1 - --authorization-mode=Node,RBAC,Webhook
إذا كان نظام مجموعة Kubernetes هو الإصدار 1.19.0 أو أحدث، فستحتاج أيضا إلى تعيين الوسيطة التالية
apiserver
:- --authentication-token-webhook-version=v1
احفظ المحرر وأغلقه لتحديث الحاوية
apiserver
.
المجموعة التي تم إنشاؤها باستخدام واجهة برمجة تطبيقات نظام المجموعة
انسخ سر الحماية الذي يحتوي على ملفات تكوين إخطار على الويب للمصادقة والتخويل من مجموعة حمل العمل على جهازك:
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
namespace
قم بتغيير الحقل في ملف azure-arc-guard-manifests.yaml إلى مساحة الاسم داخل مجموعة الإدارة حيث تقوم بتطبيق الموارد المخصصة لإنشاء مجموعات حمل العمل.تطبيق هذا البيان:
kubectl apply -f azure-arc-guard-manifests.yaml
تحرير الكائن
KubeadmControlPlane
عن طريق تشغيلkubectl edit kcp <clustername>-control-plane
:أضف القصاصة البرمجية التالية ضمن
files
:- contentFrom: secret: key: guard-authn-webhook.yaml name: azure-arc-guard-manifests owner: root:root path: /etc/kubernetes/guard-authn-webhook.yaml permissions: "0644" - contentFrom: secret: key: guard-authz-webhook.yaml name: azure-arc-guard-manifests owner: root:root path: /etc/kubernetes/guard-authz-webhook.yaml permissions: "0644"
أضف القصاصة البرمجية التالية ضمن
apiServer
>extraVolumes
:- hostPath: /etc/kubernetes/guard-authn-webhook.yaml mountPath: /etc/guard/guard-authn-webhook.yaml name: guard-authn readOnly: true - hostPath: /etc/kubernetes/guard-authz-webhook.yaml mountPath: /etc/guard/guard-authz-webhook.yaml name: guard-authz readOnly: true
أضف القصاصة البرمجية التالية ضمن
apiServer
>extraArgs
:authentication-token-webhook-cache-ttl: 5m0s authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml authentication-token-webhook-version: v1 authorization-mode: Node,RBAC,Webhook authorization-webhook-cache-authorized-ttl: 5m0s authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml authorization-webhook-version: v1
حفظ وإغلاق لتحديث
KubeadmControlPlane
الكائن. انتظر حتى تظهر هذه التغييرات على مجموعة حمل العمل.
إنشاء تعيينات دور للمستخدمين للوصول إلى نظام المجموعة
يمكن لمالكي مورد Kubernetes الذي يدعم Azure Arc استخدام أدوار مضمنة أو أدوار مخصصة لمنح المستخدمين الآخرين حق الوصول إلى مجموعة Kubernetes.
أدوار مدمجة
الدور | الوصف |
---|---|
عارض Azure Arc Kubernetes | يسمح بالوصول للقراءة فقط لرؤية معظم العناصر في مساحة الاسم. لا يسمح هذا الدور بعرض البيانات السرية، لأن read الإذن على الأسرار سيمكن الوصول إلى ServiceAccount بيانات الاعتماد في مساحة الاسم. ستسمح بيانات الاعتماد هذه بدورها بالوصول إلى واجهة برمجة التطبيقات من خلال تلك ServiceAccount القيمة (شكل من أشكال تصعيد الامتيازات). |
Azure Arc Kubernetes Writer | يسمح بالوصول للقراءة/الكتابة إلى معظم العناصر في مساحة الاسم. لا يسمح هذا الدور بعرض الأدوار أو روابط الأدوار أو تعديلها. ومع ذلك، يسمح هذا الدور بالوصول إلى الأسرار وتشغيل الحجيرات كأي ServiceAccount قيمة في مساحة الاسم، بحيث يمكن استخدامه للحصول على مستويات الوصول إلى واجهة برمجة التطبيقات لأي ServiceAccount قيمة في مساحة الاسم. |
مسؤول Azure Arc Kubernetes | يسمح بالوصول إلى المسؤول. يهدف إلى منحه داخل مساحة اسم من خلال RoleBinding . إذا كنت تستخدمه في RoleBinding ، فإنه يسمح بالوصول للقراءة/الكتابة إلى معظم الموارد في مساحة الاسم، بما في ذلك القدرة على إنشاء أدوار وروابط الأدوار داخل مساحة الاسم. لا يسمح هذا الدور بالوصول للكتابة إلى الحصة النسبية للمورد أو إلى مساحة الاسم ذاتها. |
مسؤول مجموعة Azure Arc Kubernetes | يسمح بوصول المستخدم الفائق لتنفيذ أي إجراء على أي مورد. عند استخدامه في ClusterRoleBinding ، فإنه يعطي التحكم الكامل في كل مورد في نظام المجموعة وفي جميع مساحات الأسماء. عند استخدامه في RoleBinding ، فإنه يمنح التحكم الكامل في كل مورد في مساحة اسم ربط الدور، بما في ذلك مساحة الاسم نفسها. |
يمكنك إنشاء تعيينات دور محددة النطاق إلى مجموعة Kubernetes الممكنة في Azure Arc في مدخل Microsoft Azure في جزء التحكم في الوصول (IAM) لمورد نظام المجموعة. يمكنك أيضا استخدام أوامر Azure CLI التالية:
az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID
في هذه الأوامر، AZURE-AD-ENTITY-ID
يمكن أن يكون اسم مستخدم (على سبيل المثال، testuser@mytenant.onmicrosoft.com
) أو حتى appId
قيمة كيان الخدمة.
فيما يلي مثال آخر لإنشاء تعيين دور محدد النطاق لمساحة اسم معينة داخل نظام المجموعة:
az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>
إشعار
يمكنك إنشاء تعيينات دور محددة النطاق إلى نظام المجموعة باستخدام إما مدخل Azure أو Azure CLI. ومع ذلك، يمكن استخدام Azure CLI فقط لإنشاء تعيينات دور محددة النطاق لمساحات الأسماء.
أدوار مخصصة
يمكنك اختيار إنشاء تعريف الدور الخاص بك للاستخدام في تعيينات الأدوار.
اطلع على المثال التالي لتعريف دور يسمح للمستخدم بقراءة عمليات النشر فقط. لمزيد من المعلومات، راجع القائمة الكاملة لإجراءات البيانات التي يمكنك استخدامها لإنشاء تعريف دور.
انسخ كائن JSON التالي في ملف يسمى custom-role.json. <subscription-id>
استبدل العنصر النائب بمعرف الاشتراك الفعلي. يستخدم الدور المخصص أحد إجراءات البيانات ويتيح لك عرض جميع عمليات النشر في النطاق (نظام المجموعة أو مساحة الاسم) حيث يتم إنشاء تعيين الدور.
{
"Name": "Arc Deployment Viewer",
"Description": "Lets you view all deployments in cluster/namespace.",
"Actions": [],
"NotActions": [],
"DataActions": [
"Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
],
"NotDataActions": [],
"assignableScopes": [
"/subscriptions/<subscription-id>"
]
}
إنشاء تعريف الدور عن طريق تشغيل الأمر التالي من المجلد حيث قمت بحفظ custom-role.json:
az role definition create --role-definition @custom-role.json
إنشاء تعيين دور باستخدام تعريف الدور المخصص هذا:
az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>
تكوين kubectl باستخدام بيانات اعتماد المستخدم
هناك طريقتان للحصول على ملف kubeconfig الذي تحتاج إليه للوصول إلى نظام المجموعة:
- يمكنك استخدام ميزة الاتصال المجموعة (
az connectedk8s proxy
) لمجموعة Kubernetes الممكنة في Azure Arc. - يشارك مسؤول نظام المجموعة ملف kubeconfig مع كل مستخدم آخر.
استخدام اتصال نظام المجموعة
قم بتشغيل الأمر التالي لبدء عملية الوكيل:
az connectedk8s proxy -n <clusterName> -g <resourceGroupName>
بعد تشغيل عملية الوكيل، يمكنك فتح علامة تبويب أخرى في وحدة التحكم لبدء إرسال طلباتك إلى نظام المجموعة.
استخدام ملف kubeconfig مشترك
يتطلب استخدام kubeconfig مشترك خطوات مختلفة قليلا اعتمادا على إصدار Kubernetes الخاص بك.
قم بتشغيل الأمر التالي لتعيين بيانات الاعتماد للمستخدم. حدد
serverApplicationId
ك6256c85f-0aad-4d50-b960-e6e9b21efe35
وclientApplicationId
ك3f4439ff-e698-4d6d-84fe-09c9d574f06b
:kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \ --auth-provider=azure \ --auth-provider-arg=environment=AzurePublicCloud \ --auth-provider-arg=client-id=<clientApplicationId> \ --auth-provider-arg=tenant-id=<tenantId> \ --auth-provider-arg=apiserver-id=<serverApplicationId>
افتح ملف kubeconfig الذي قمت بإنشائه سابقا. ضمن
contexts
، تحقق من أن السياق المقترن بالمجموعة يشير إلى بيانات اعتماد المستخدم التي قمت بإنشائها في الخطوة السابقة. لتعيين السياق الحالي إلى بيانات اعتماد المستخدم هذه، قم بتشغيل الأمر التالي:kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
أضف إعداد وضع التكوين ضمن
user
>config
:name: testuser@mytenant.onmicrosoft.com user: auth-provider: config: apiserver-id: $SERVER_APP_ID client-id: $CLIENT_APP_ID environment: AzurePublicCloud tenant-id: $TENANT_ID config-mode: "1" name: azure
إشعار
المكون الإضافي Exec هو استراتيجية مصادقة Kubernetes التي تسمح
kubectl
بتنفيذ أمر خارجي لتلقي بيانات اعتماد المستخدم لإرسالها إلىapiserver
. بدءا من Kubernetes الإصدار 1.26، لم يعد المكون الإضافي الافتراضي للتخويل Azure مضمنا فيclient-go
وkubectl
. مع الإصدارات الأحدث، من أجل استخدام المكون الإضافي exec لتلقي بيانات اعتماد المستخدم، يجب عليك استخدام Azure Kubelogin، وهو مكونclient-go
إضافي لبيانات الاعتماد (exec) يقوم بتنفيذ مصادقة Azure.تثبيت Azure Kubelogin:
بالنسبة إلى Windows أو Mac، اتبع إرشادات تثبيت Azure Kubelogin.
بالنسبة إلى Linux أو Ubuntu، قم بتنزيل أحدث إصدار من kubelogin، ثم قم بتشغيل الأوامر التالية:
curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip unzip kubelogin-linux-amd64.zip sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ sudo chmod +x /usr/local/bin/kubelogin
يمكن استخدام Kubelogin للمصادقة مع المجموعات التي تدعم Azure Arc عن طريق طلب رمز إثبات الحيازة (PoP). قم بتحويل kubeconfig باستخدام kubelogin لاستخدام وضع تسجيل الدخول المناسب. على سبيل المثال، لتسجيل الدخول إلى رمز الجهاز مع مستخدم Microsoft Entra، ستكون الأوامر كما يلي:
export KUBECONFIG=/path/to/kubeconfig kubelogin convert-kubeconfig --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
إرسال طلبات إلى نظام المجموعة
تشغيل أي
kubectl
أمر. على سبيل المثال:kubectl get nodes
kubectl get pods
بعد مطالبتك بالمصادقة المستندة إلى المستعرض، انسخ عنوان URL لتسجيل دخول الجهاز (
https://microsoft.com/devicelogin
) وافتحه في مستعرض الويب الخاص بك.أدخل التعليمات البرمجية المطبوعة على وحدة التحكم الخاصة بك. انسخ التعليمة البرمجية والصقها على المحطة الطرفية في المطالبة بإدخال مصادقة الجهاز.
أدخل اسم المستخدم (
testuser@mytenant.onmicrosoft.com
) وكلمة المرور المقترنة.إذا رأيت رسالة خطأ مثل هذه، فهذا يعني أنك غير مصرح لك بالوصول إلى المورد المطلوب:
Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.
يحتاج المسؤول إلى إنشاء تعيين دور جديد يخول هذا المستخدم الوصول إلى المورد.
استخدام الوصول المشروط مع معرف Microsoft Entra
عند دمج معرف Microsoft Entra مع مجموعة Kubernetes التي تدعم Azure Arc، يمكنك أيضا استخدام الوصول المشروط للتحكم في الوصول إلى مجموعتك.
إشعار
الوصول المشروط من Microsoft Entra هو إمكانية Microsoft Entra ID P2.
لإنشاء مثال نهج الوصول المشروط لاستخدامه مع نظام المجموعة:
في أعلى مدخل Microsoft Azure، ابحث عن Microsoft Entra ID وحدده.
في القائمة الخاصة ب Microsoft Entra ID على الجانب الأيسر، حدد Enterprise applications.
في القائمة لتطبيقات المؤسسة على الجانب الأيسر، حدد الوصول المشروط.
في قائمة الوصول المشروط على الجانب الأيسر، حدد Policies>New policy.
أدخل اسما للنهج، مثل arc-k8s-policy.
حدد المستخدمين والمجموعات. ضمن تضمين، اختر تحديد المستخدمين والمجموعات. ثم اختر المستخدمين والمجموعات حيث تريد تطبيق النهج. على سبيل المثال، اختر نفس مجموعة Microsoft Entra التي لديها حق الوصول الإداري إلى نظام المجموعة الخاص بك.
حدد "Cloud apps or actions". ضمن تضمين، اختر تحديد التطبيقات. ثم ابحث عن تطبيق الخادم الذي أنشأته سابقا وحدده.
ضمن "Access controls"، حدد "Grant". حدد Grant access>Require device to be marked as compliant.
ضمن Enable policy، حدد On>Create.
الوصول إلى نظام المجموعة مرة أخرى. على سبيل المثال، قم بتشغيل kubectl get nodes
الأمر لعرض العقد في نظام المجموعة:
kubectl get nodes
اتبع الإرشادات لتسجيل الدخول مرة أخرى. تشير رسالة الخطأ إلى أنك قمت بتسجيل الدخول بنجاح، ولكن المسؤول يتطلب أن تتم إدارة الجهاز الذي يطلب الوصول بواسطة معرف Microsoft Entra للوصول إلى المورد. اتبع الخطوات التالية:
في مدخل Microsoft Azure، انتقل إلى معرف Microsoft Entra.
حدد تطبيقات Enterprise. ثم ضمن Activity، حدد Sign-ins.
يظهر الإدخال في الأعلى فشل الحالة والنجاح للوصول المشروط. حدد الإدخال، ثم حدد الوصول المشروط في التفاصيل. لاحظ أن نهج الوصول المشروط مدرج.
تكوين الوصول إلى نظام المجموعة في الوقت المناسب باستخدام معرف Microsoft Entra
هناك خيار آخر للتحكم في الوصول إلى نظام المجموعة وهو استخدام إدارة الهويات المتميزة (PIM) للطلبات في الوقت المناسب.
إشعار
Microsoft Entra PIM هي إمكانية Microsoft Entra ID P2. لمزيد من الإرشادات حول وحدات SKU لمعرف Microsoft Entra، راجع دليل التسعير.
لتكوين طلبات الوصول في الوقت المناسب للمجموعة الخاصة بك، أكمل الخطوات التالية:
في أعلى مدخل Microsoft Azure، ابحث عن Microsoft Entra ID وحدده.
دون معرف المستأجر. بالنسبة لبقية هذه الإرشادات، سنشير إلى هذا المعرف على أنه
<tenant-id>
.في القائمة الخاصة ب Microsoft Entra ID على الجانب الأيمن، ضمن Manage، حدد Groups>New group.
تأكد من تحديد الأمان لنوع المجموعة. أدخل اسم مجموعة، مثل myJITGroup. ضمن Microsoft Entra roles can be assigned to this group (Preview), select Yes. وأخيراً، حدد "Create".
يتم إرجاعك إلى صفحة المجموعات . حدد المجموعة التي تم إنشاؤها حديثا وقم بتدوين معرف الكائن. بالنسبة لبقية هذه الإرشادات، سنشير إلى هذا المعرف على أنه
<object-id>
.مرة أخرى في مدخل Microsoft Azure، في قائمة النشاط على الجانب الأيسر، حدد الوصول المتميز (معاينة). ثم حدد Enable Privileged Access.
حدد Add assignments لبدء منح حق الوصول.
حدد دور العضو، وحدد المستخدمين والمجموعات الذين تريد منحهم حق الوصول إلى نظام المجموعة. يمكن لمسؤول المجموعة تعديل هذه التعيينات في أي وقت. عندما تكون جاهزا للانتقال، حدد التالي.
اختر نوع تعيين نشط، واختر المدة المطلوبة، وقدم مبررا. عندما تكون جاهزًا لتزويد الخدمات، حدد «تعيين». لمزيد من الاطلاع على أنواع التعيينات، راجع تعيين أحقية الوصول المميز للمجموعة (معاينة) في إدارة الهويات المتميزة.
بعد إجراء التعيينات، تحقق من أن الوصول في الوقت المناسب يعمل عن طريق الوصول إلى نظام المجموعة. على سبيل المثال، استخدم kubectl get nodes
الأمر لعرض العقد في نظام المجموعة:
kubectl get nodes
لاحظ متطلبات المصادقة واتبع الخطوات لإجراء المصادقة. إذا نجحت المصادقة، يجب أن تشاهد إخراجا مشابها لهذا:
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.
NAME STATUS ROLES AGE VERSION
node-1 Ready agent 6m36s v1.18.14
node-2 Ready agent 6m42s v1.18.14
node-3 Ready agent 6m33s v1.18.14
الخطوات التالية
- الاتصال بشكل آمن بالمجموعة باستخدام نظام المجموعة الاتصال.
- اقرأ عن بنية Azure RBAC على Kubernetes التي تدعم Arc.
الملاحظات
https://aka.ms/ContentUserFeedback.
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجعإرسال الملاحظات وعرضها المتعلقة بـ