مشاركة عبر

موثوقية المحتوى في سجل حاويات Azure

  • مقالة

ينفِّذ سجل حاويات Azure نموذج موثوقية محتوي Docker مما يتيح دفع الصور الموقعة وسحبها. تمكنك هذه المقالة من البدء في تمكين موثوقية المحتوى في سجلات الحاوية.

إشعار

موثوقية المحتوى هي ميزة من ميزات مستويات خدمة Premium من سجل حاويات Azure.

القيود

  • لا يدعم الرمز المميز مع أذونات نطاق المستودع حاليا دفع وسحب docker للصور الموقعة.

كيفية عمل موثوقية المحتوى

إن التحقق من مصدروتكامل البيانات التي تدخل النظام أمر مهم لأي نظام موزع مصمم مع وضع الأمن. يجب أن يكون مستهلكو البيانات قادرين على التحقق من ناشر (مصدر) البيانات، بالإضافة إلى التأكد من عدم تعديلها بعد نشرها (التكامل).

بصفتك ناشراً للصور، تسمح لك موثوقية المحتوى بتوقيع الصور التي تدخلها في السجل. يمكن أن يكوِّن مستهلكو الصور (الأشخاص أو أنظمة سحب الصور من سجلك) عملائهم لسحب الصور الموقعة فقط. عندما يخرج مستهلك الصورة صورة موقعة، يتحقق عميل Docker من تكامل بيانات الصورة. في هذا النموذج، يتأكد المستهلكون أنك نشرت الصور الموقعة في سجلك بالفعل، ولم يتم تعديلها منذ نشرها.

إشعار

لا يدعم acr import Azure Container Registry (ACR) استيراد الصور الموقعة باستخدام Docker Content Trust (DCT). حسب التصميم، لا تكون التواقيع مرئية بعد الاستيراد، ويخزن كاتب العدل v2 هذه التواقيع كقطع أثرية.

صور موثوقة

تعمل موثوقية المحتوى باستخدام العلامات الموجودة في مستودع. يمكن أن تحتوي مستودعات الصور على صور تحمل علامات موقعة وغير موقعة. على سبيل المثال، قد توقِّع الصورتين myimage:stable وmyimage:latest فقط، وليس myimage:dev.

مفاتيح التوقيع

تُدار موثوقية المحتوى باستخدام مجموعة من مفاتيح التوقيع المشفرة. ترتبط هذه المفاتيح بمستودع معين في التسجيل. ثمة عدة أنواع من مفاتيح التوقيع التي يستخدمها عملاء Docker وسجلك في إدارة الموثوقية للعلامات في المستودع. عند تمكين موثوقية المحتوى ودمجها في حاوية النشر ومسار الاستهلاك، يجب إدارة هذه المفاتيح بعناية. لمزيد من المعلومات، راجع إدارة المفتاح لاحقاً في هذه المقالة وإدارة مفاتيح موثوقية المحتوى في وثائق Docker.

تلميح

كانت نظرة عامة عالية المستوى عن نموذج موثوقية محتوى Docker. للاطلاع على مناقشة تفسيرية عن موثوقية المحتوى، راجع موثوقية المحتوى في Docker.

تمكين موثوقية محتوى السجل

الخطوة الأولى هي تمكين موثوقية المحتوى على مستوى السجل. بمجرد تمكين موثوقية المحتوى، يمكن أن يدخل العملاء (المستخدمون أو الخدمات) الصور الموقعة إلى سجلك. لا يؤدي تمكين موثوقية المحتوى في السجل إلى اقتصار استخدام السجل على المستهلكين الذي مكّنوا موثوقية المحتوى. يمكن أن يتابع المستهلكون الذين لم يمكِّنوا موثوقية المحتوى استخدام السجل بشكل طبيعي. ومع ذلك، سيتمكّن المستهلكون الذين مكّنوا موثوقية المحتوى لدى عملائهم من مشاهدة الصور الموقّعة فقط في سجلك.

لتمكين موثوقية المحتوى لسجلك، انتقل السجل في مدخل Azure أولاً. ضمن النُهج، حدد تمكين موثوقية>المحتوى>ثم حفظ. يمكنك أيضاً استخدام أمر تحديث موثوقية المحتوى az acr config في Azure CLI.

Screenshot shows enabling content trust for a registry in the Azure portal.

تمكين موثوقية محتوى العميل

للعمل مع الصور الموثوقة، يحتاج ناشرو الصور والمستهلكون على حد سواء إلى تمكين موثوقية المحتوى لدى عملائهم من Docker. وبصفتك ناشراً، يمكنك توقيع الصور التي تُدخلها في سجل به خاصية موثوقية المحتوى ممكنة. بصفتك مستهلكاً، يؤدي تمكين موثوقية المحتوى إلى تقييد طريقة عرض السجل إلى الصور الموقعة فقط. تُعطَل موثوقية المحتوى في عملاء Docker افتراضياً، لكن يمكنك تمكينها في كل جلسة عمل shell أو في كل أمر.

لتمكين موثوقية المحتوى في جلسة عمل shell، عيِّن متغير البيئة DOCKER_CONTENT_TRUST على 1. على سبيل المثال، في Bash shell:

# Enable content trust for shell session
export DOCKER_CONTENT_TRUST=1

إذا كنت ترغب في تمكين موثوقية المحتوي أو تعطيلها لأمر واحد بدلاً من ذلك، فإن العديد من أوامر Docker تدعم الوسيطة --disable-content-trust. لتمكين موثوقية المحتوى لأمر واحد:

# Enable content trust for single command
docker build --disable-content-trust=false -t myacr.azurecr.io/myimage:v1 .

في حالة تمكين موثوقية المحتوى لجلسة عمل shell وكنت تريد تعطيلها لأمر واحد:

# Disable content trust for single command
docker build --disable-content-trust -t myacr.azurecr.io/myimage:v1 .

منح أذونات توقيع الصور

غير مسموح بدفع الصور الموثوقة إلى سجلك إلا للمستخدمين أو الأنظمة التي منحتها الإذن فقط. لمنح إذن دفع صورة موثوق به لمستخدم (أو نظام يستخدم كيان خدمة)، امنح هويات AcrImageSigner Microsoft Entra الدور. فضلاً عن الدور AcrPush (أو ما يعادله) المطلوب لدفع الصور إلى السجل. للحصول على التفاصيل، راجع أدوار وأذونات سجل حاويات Azure.

هام

لا يمكنك منح إذن دفع الصور الموثوقة للحسابات الإدارية التالية:

  • حساب المسؤول لسجل حاويات Azure
  • حساب مستخدم في معرف Microsoft Entra مع دور مسؤول النظام الكلاسيكي.

إشعار

بدءاً من تموز (يوليو) 2021، يشتمل الدور AcrImageSigner على كل من إجراء Microsoft.ContainerRegistry/registries/sign/write وإجراء البيانات Microsoft.ContainerRegistry/registries/trustedCollections/write.

تفاصيل منح الدور AcrImageSigner في مدخل Azure ومتابعة Azure CLI.

مدخل Azure

  1. حدد Access control (IAM).

  2. حدد Add>Add role assignment لفتح صفحة إضافة تعيين الدور.

  3. تعيين الدور التالي. في هذا المثال، يُعيَن الدور إلى مستخدم فردي. للحصول على خطوات تفصيلية، راجع تعيين أدوار Azure باستخدام مدخل Azure.

    الإعداد القيمة‬
    الدور AcrImageSigner
    تعيين الوصول إلى المستخدم
    الأعضاء Alain

    Add role assignment page in Azure portal.

Azure CLI

لمنح أذونات التوقيع لمستخدم مع CLI Azure، عيِّن الدور AcrImageSigner للمستخدم المحدد في نطاق سجلك. تنسيق الأمر هو:

az role assignment create --scope <registry ID> --role AcrImageSigner --assignee <user name>

على سبيل المثال، لمنح مستخدم غير إداري الدور، يمكنك تشغيل الأوامر التالية في جلسة عمل Azure CLI معتمدة. عدِّل القيمة REGISTRY لتوضيح اسم سجل حاويات Azure.

# Grant signing permissions to authenticated Azure CLI user
REGISTRY=myregistry
REGISTRY_ID=$(az acr show --name $REGISTRY --query id --output tsv)

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee azureuser@contoso.com

يمكنك أيضاً منح كيان الخدمة حقوق دفع الصور الموثوقة في سجلك. إن استخدام كيان الخدمة أمر مفيد لبناء الأنظمة والأنظمة الأخرى غير المراقبة التي تحتاج إلى دفع الصور الموثوقة في سجلك. يشبه التنسيق منح إذن مستخدم، لكن ينبغي تحديد معرف كيان الخدمة للقيمة --assignee.

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee <service principal ID>

يمكن أن يكون <service principal ID>appId أو objectId أو أحد أسماء servicePrincipalNames لكيان الخدمة. لمزيد من المعلومات عن العمل مع كيانات الخدمة وسجل حاويات Azure، راجع مصادقة سجل حاويات Azure مع كيانات الخدمة.

هام

بعد إجراء تغييرات الدور، شغِّل az acr login لتحديث رمز التعريف المحلي لـ Azure CLI بحيث يتم تطبيق الأدوار الجديدة. للحصول على معلومات عن التحقق من أدوار الهوية، راجع إضافة تعيينات دور Azure أو إزالتها باستخدام Azure CLIواستكشاف أخطاء Azure RBAC وإصلاحها.

دفع صورة موثوقة

لدفع علامة صورة موثوقة إلى سجل حاويتك، مكِّن موثوقية المحتوى وأدخل الصورة باستخدام docker push. بعد اكتمال الدفع مع علامة موقعة في المرة الأولى، يطلب منك إنشاء عبارة مرور لكلٍّ من مفتاح توقيع الجذر ومفتاح توقيع المستودع. يتم إنشاء كلٍّ من مفاتيح الجذر والمستودع وتخزينها محلياً على جهازك.

$ docker push myregistry.azurecr.io/myimage:v1
[...]
The push refers to repository [myregistry.azurecr.io/myimage]
ee83fc5847cb: Pushed
v1: digest: sha256:aca41a608e5eb015f1ec6755f490f3be26b48010b178e78c00eac21ffbe246f1 size: 524
Signing and pushing trust metadata
You are about to create a new root signing key passphrase. This passphrase
will be used to protect the most sensitive key in your signing system. Please
choose a long, complex passphrase and be careful to keep the password and the
key file itself secure and backed up. It is highly recommended that you use a
password manager to generate the passphrase and keep it safe. There will be no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new root key with ID 4c6c56a:
Repeat passphrase for new root key with ID 4c6c56a:
Enter passphrase for new repository key with ID bcd6d98:
Repeat passphrase for new repository key with ID bcd6d98:
Finished initializing "myregistry.azurecr.io/myimage"
Successfully signed myregistry.azurecr.io/myimage:v1

بعد تحديد docker push الأول لك مع تمكين موثوقية المحتوى، يستخدم عميل Docker المفتاح الجذر نفسه لعمليات الدفع اللاحقة. في كل دفع لاحق إلى المستودع نفسه، يطلب منك مفتاح المستودع فقط. في كل مرة تدخل فيها صورة موثوقة في مستودع جديد، يُطلب منك توفير عبارة مرور لمفتاح مستودع جديد.

سحب صورة موثوقة

لسحب صورة موثوقة، مكِّن موثوقية المحتوى وشغّل الأمر docker pull بشكل طبيعي. لسحب الصور الموثوقة، يكفي استخدام الدور AcrPull للمستخدمين العاديين. لا يلزم وجود أدوار إضافية مثل AcrImageSigner. لا يمكن أن يخرج المستهلكون الذين مكّنوا موثوقية المحتوى سوى الصور التي تحمل علامات موقعة فقط. فيما يلي مثال على سحب علامة موقعة:

$ docker pull myregistry.azurecr.io/myimage:signed
Pull (1 of 1): myregistry.azurecr.io/myimage:signed@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b: Pulling from myimage
8e3ba11ec2a2: Pull complete
Digest: sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
Status: Downloaded newer image for myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
Tagging myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b as myregistry.azurecr.io/myimage:signed

إذا حاول عميل مكّن موثوقية المحتوى سحب علامة غير موقعة، تفشل العملية مع حدوث خطأ مشابه لما يلي:

$ docker pull myregistry.azurecr.io/myimage:unsigned
Error: remote trust data does not exist

خلف الكواليس

عند تشغيل docker pull، يستخدم عميل Docker المكتبة نفسها كما في Notary CLI لطلب تعيين ملخص الرسالة tag-to-SHA-256 للعلامة التي تخرجها. بعد التحقق من صحة التواقيع على بيانات الثقة، يوجه العميل Docker Engine لإجراء "سحب حسب الملخص". أثناء السحب، يستخدم المحرك المجموع الاختباري SHA-256 كعنوان محتوى لطلب بيان الصورة والتحقق منه من Azure Container Registry.

إشعار

لا يدعم سجل حاويات Azure رسمياً Notary CLI لكنه متوافق مع واجهة برمجة تطبيقات خادم Notary الذي يُدرج في Docker Desktop. يوصى باستخدام الإصدار 0.6.0 من Notary حالياً.

إدارة المفاتيح

كما هو مذكور في إخراج docker push عند دفع أول صورة موثوقة، إن المفتاح الجذر هو الأكثر حساسية. تأكد من إجراء نسخة احتياطية من المفتاح الجذر وتخزينه في مكان آمن. يخزِّن عميل Docker بتخزين مفاتيح التوقيع في الدليل التالي افتراضياً:

~/.docker/trust/private

انسخ المفتاح الجذر ومفتاح المستودع احتياطياً عن طريق ضغطها في أرشيف وتخزينها في مكان آمن. على سبيل المثال، في Bash:

umask 077; tar -zcvf docker_private_keys_backup.tar.gz ~/.docker/trust/private; umask 022

بجانب المفتاح الجذر ومفتاح المستودع المكوّنين محلياً، يُكوِن سجل حاويات Azure عدة مفاتيح أخرى ويخزِّنها عند دفع صورة موثوقة. للاطلاع على مناقشة مفصلة للمفاتيح المختلفة في تنفيذ موثوقية محتوى Docker، بما فيها إرشادات الإدارة الإضافية، راجع إدارة مفاتيح موثوقية المحتوى في وثائق Docker.

فقدان المفتاح الجذر

في حالة فقدان الوصول إلى المفتاح الجذر، تفقد الوصول إلى العلامات الموقعة في أي مستودع به علامات موقعة بهذا المفتاح. لا يمكن أن يستعيد سجل حاويات Azure الوصول إلى علامات الصور الموقعة بالمفتاح الجذر المفقود. لإزالة جميع بيانات الثقة (التوقيعات) لسجلك، عطِّل موثوقية المحتوى لسجلك أولاً ثم أعد تمكينها.

التحذير

يؤدي تعطيل موثوقية المحتوى لسجلك وإعادة تمكينها إلى حذف جميع بيانات الثقة لجميع العلامات الموقعة في كل مستودع في السجل. لا يمكن الرجوع في هذا الإجراء--لا يتمكن سجل حاويات Azure من استرداد بيانات الثقة المحذوفة. لا يؤدي تعطيل موثوقية المحتوى إلى حذف الصور نفسها.

لتعطيل موثوقية المحتوى لسجلك، انتقل إلى السجل في مدخل Azure. ضمن النُهج، حدد تعطيل موثوقية>المحتوى>ثم حفظ. نحذِّرك من فقدان جميع التوقيعات في السجل. حدد "OK" لحذف جميع التوقيعات في السجل نهائياً.

Disabling content trust for a registry in the Azure portal

الخطوات التالية

  • راجع موثوقية المحتوى في Docker للحصول على معلومات إضافية حول موثوقية المحتوى، بما فيها أوامر موثوقية dockerوتفويضات الثقة. بينما تطرقنا إلى العديد من النقاط الرئيسية في هذه المقالة، إلا أن موثوقية المحتوى موضوع كبير ويُعرض بشكل أكثر استفاضة في وثائق Docker.

  • راجع وثائق مسارات Azure للاطلاع على مثال عن استخدام موثوقية المحتوى عند إنشاء صورة Docker ودفعها.