عمليات نشر القيود باستخدام المصادقة الثنائية

1. مقدمة

"التفويض الثنائي" هو عنصر تحكّم أمني في وقت النشر يضمن نشر صور الحاويات الموثوق بها فقط على Google Kubernetes Engine أو Cloud Run. باستخدام "الترخيص الثنائي"، يمكنك طلب توقيع الصور من جهات موثوق بها أثناء عملية التطوير، ثم فرض التحقّق من صحة التوقيع عند النشر. من خلال فرض التحقق من الصحة، يمكنك التحكم بشكل أكبر في بيئة الحاوية عن طريق ضمان دمج الصور التي تم التحقق من صحتها فقط في عملية الإنشاء والإصدار.

يوضِّح المخطّط البياني التالي المكوّنات في إعداد التفويض الثنائي أو Cloud Build:

**الشكل 1.**مسار Cloud Build الذي ينشئ مصادقة التفويض الثنائي.

في هذا المسار:

1. يتم إرسال الرمز لإنشاء صورة الحاوية إلى مستودع مصدر، مثل مستودعات Cloud Source.
2. تعمل Cloud Build على إنشاء الحاوية واختبارها، وهي أداة للتكامل المستمر (CI).
3. ينقل الإصدار صورة الحاوية إلى Container Registry أو سجلّ آخر يخزِّن صورك المنشأة.
4. خدمة إدارة المفاتيح في السحابة الإلكترونية: توقيع صورة الحاوية، وهي خدمة توفّر إدارة المفاتيح لزوج مفاتيح التشفير. بعد ذلك، يتم تخزين التوقيع الناتج في مصادقة تم إنشاؤها حديثًا.
5. في وقت النشر، يتحقّق المُصدِّق من المصادقة باستخدام المفتاح العام من مفتاحَي التشفير. يفرض الترخيص الثنائي السياسة من خلال طلب شهادات موقَّعة لنشر صورة الحاوية.

سوف تركِّز في هذا التمرين المعملي على الأدوات والتقنيات اللازمة لتأمين العناصر المنشورة. يركّز هذا التمرين على العناصر (الحاويات) بعد إنشائها ولكن لم يتم نشرها في أي بيئة معيّنة.

المعلومات التي ستطّلع عليها

• توقيع الصور
• سياسات مراقبة الدخول
• توقيع الصور الممسوحة ضوئيًا
• السماح بالصور الموقَّعة
• تم حظر الصور غير الموقَّعة.

2. الإعداد والمتطلبات

إعداد بيئة ذاتية

1. سجِّل الدخول إلى Google Cloud Console وأنشئ مشروعًا جديدًا أو أعِد استخدام مشروع حالي. إذا لم يكن لديك حساب على Gmail أو Google Workspace، عليك إنشاء حساب.

• اسم المشروع هو الاسم المعروض للمشاركين في هذا المشروع. وهي سلسلة أحرف لا تستخدمها Google APIs. ويمكنك تعديله في أي وقت.
• يكون رقم تعريف المشروع فريدًا في جميع مشاريع Google Cloud وغير قابل للتغيير (لا يمكن تغييره بعد تحديده). تنشئ Cloud Console سلسلة فريدة تلقائيًا. فعادةً لا تهتم بما هو. في معظم الدروس التطبيقية حول الترميز، يجب الإشارة إلى رقم تعريف المشروع (يتم تحديده عادةً على أنّه PROJECT_ID). وإذا لم يعجبك المعرّف الذي تم إنشاؤه، يمكنك إنشاء رقم تعريف عشوائي آخر. ويمكنك بدلاً من ذلك تجربة طلبك الخاص ومعرفة ما إذا كان متوفّرًا. ولا يمكن تغييره بعد هذه الخطوة وسيبقى طوال مدة المشروع.
• لمعلوماتك، هناك قيمة ثالثة، وهي رقم المشروع الذي تستخدمه بعض واجهات برمجة التطبيقات. اطّلِع على مزيد من المعلومات حول هذه القيم الثلاث في المستندات.

تنبيه: يكون رقم تعريف المشروع فريدًا عالميًا ولا يمكن لأي شخص آخر استخدامه بعد اختياره. أنت المستخدم الوحيد لرقم التعريف هذا. لا يمكن استخدام رقم التعريف مرة أخرى، حتى في حال حذف مشروع.

ملاحظة: إذا كنت تستخدم حساب Gmail، يمكنك ترك الموقع الجغرافي التلقائي معيّنًا على بدون مؤسسة. إذا كنت تستخدم حسابًا على Google Workspace، اختَر موقعًا جغرافيًا منطقيًا لمؤسستك.

2. بعد ذلك، عليك تفعيل الفوترة في Cloud Console لاستخدام الموارد/واجهات برمجة التطبيقات في Cloud. إنّ تنفيذ هذا الدرس التطبيقي حول الترميز لن يكون مكلفًا أو مكلفًا على الإطلاق. لإيقاف تشغيل الموارد حتى لا تتحمل الفوترة بعد هذا البرنامج التعليمي، يمكنك حذف الموارد التي أنشأتها أو حذف المشروع بالكامل. يكون مستخدمو Google Cloud الجدد مؤهَّلون للانضمام إلى برنامج فترة تجريبية مجانية بقيمة 300 دولار أمريكي.

إعداد البيئة

في Cloud Shell، يمكنك ضبط رقم تعريف مشروعك ورقمه. حفظها كمتغيّرات PROJECT_ID وPROJECT_ID

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

تفعيل الخدمات

تفعيل جميع الخدمات اللازمة:

gcloud services enable \
  cloudkms.googleapis.com \
  cloudbuild.googleapis.com \
  container.googleapis.com \
  containerregistry.googleapis.com \
  artifactregistry.googleapis.com \
  containerscanning.googleapis.com \
  ondemandscanning.googleapis.com \
  binaryauthorization.googleapis.com 

إنشاء مستودع Artifact Registry

ستستخدم في هذا التمرين المعملي Artifact Registry لتخزين الصور ومسحها ضوئيًا. أنشئ المستودع باستخدام الأمر التالي.

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

اضبط إعدادات Docker لاستخدام بيانات اعتماد gcloud الخاصة بك عند الوصول إلى Artifact Registry.

gcloud auth configure-docker us-central1-docker.pkg.dev

إنشاء دليل عمل وتغييره

mkdir vuln-scan && cd vuln-scan

تحديد نموذج صورة

أنشئ ملفًا باسم Dockerfile يتضمن المحتوى التالي.

cat > ./Dockerfile << EOF
from python:3.8-slim  

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app

EOF

أنشئ ملفًا باسمMain.py يتضمن المحتوى التالي

cat > ./main.py << EOF
import os
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    name = os.environ.get("NAME", "Worlds")
    return "Hello {}!".format(name)

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF

إنشاء الصورة ودفعها إلى الواقع المعزّز

يمكنك استخدام Cloud Build لإنشاء الحاوية وإرسالها تلقائيًا إلى Artifact Registry.

gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

3- توقيع الصور

ما هي المصادقة

المُصدِّق

• هذا الشخص/العملية مسؤول عن رابط واحد في سلسلة الثقة للنظام.
• ويحمل مفتاح تشفير ويوقّع صورة إذا اجتازت عملية الموافقة.
• في حين أنّ "صانع السياسات" يحدّد السياسة بطريقة مختصرة وعالية المستوى، يكون المصدِّق مسؤولاً بشكل ملموس عن تنفيذ جانب من جوانب السياسة.
• وقد يكون شخصًا حقيقيًا، مثل أحد مختبِري تأكيد الجودة أو المدير، أو قد يكون برنامج تتبُّع في نظام CI.
• يعتمد أمان النظام على مدى مصداقيته، لذا من المهم الحفاظ على أمان مفاتيحه الخاصة.

ويمكن أن يمثل كل دور من هذه الأدوار شخصًا منفردًا أو فريقًا من الأشخاص في مؤسستك. في بيئة الإنتاج، من المحتمل أن تُدار هذه الأدوار من خلال مشاريع منفصلة في Google Cloud Platform (GCP)، وستتم مشاركة الوصول إلى الموارد فيما بينها بطريقة محدودة باستخدام Cloud IAM.

يتم تنفيذ المُصادقين في "التفويض الثنائي" بالإضافة إلى Cloud Container Analysis API، لذلك من المهم وصف كيفية عمل ذلك قبل المتابعة. تم تصميم Container Analysis API للسماح لك بربط البيانات الوصفية بصور حاويات معيّنة.

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

إلى جانب الثغرات الأمنية في التتبُّع، تم تصميم Container Analysis لتكون واجهة برمجة تطبيقات عامة للبيانات الوصفية. يستخدم التفويض الثنائي Container Analysis من أجل ربط التوقيعات بصور الحاوية التي يتحقّقون منها**.** يتم استخدام ملاحظة تحليل الحاوية لتمثيل جهة مصادقة واحدة، ويتم إنشاء مواضع الورود وربطها بكل حاوية توافق عليها جهة المصادقة.

تستخدم واجهة برمجة تطبيقات التفويض الثنائي مفاهيم "الممثلون" و"المصادقة"، ولكن يتم تنفيذها باستخدام Notes (الملاحظات) و"أحداث الورود" المقابلة في Container Analysis API.

إنشاء ملاحظة مصادق

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

إنشاء ملاحظة

cat > ./vulnz_note.json << EOM
{
  "attestation": {
    "hint": {
      "human_readable_name": "Container Vulnerabilities attestation authority"
    }
  }
}
EOM

تخزين الملاحظة

NOTE_ID=vulnz_note

curl -vvv -X POST \
    -H "Content-Type: application/json"  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @./vulnz_note.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

إثبات صحة الملاحظة

curl -vvv  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

تم حفظ ملاحظتك الآن في Container Analysis API.

إنشاء مصادق

يتم استخدام المصدّقين لتنفيذ عملية توقيع الصورة الفعلية، وسيتم إرفاق موضع ورود الملاحظة بالصورة للتحقّق منها لاحقًا. لاستخدام المصدِّر، يجب أيضًا تسجيل الملاحظة في "التفويض الثنائي":

إنشاء مصادق

ATTESTOR_ID=vulnz-attestor

gcloud container binauthz attestors create $ATTESTOR_ID \
    --attestation-authority-note=$NOTE_ID \
    --attestation-authority-note-project=${PROJECT_ID}

إثبات هوية المُصدِّق

gcloud container binauthz attestors list

يُرجى ملاحظة أنّ السطر الأخير يشير إلى أنّ NUM_PUBLIC_KEYS: 0 ستوفّر المفاتيح في خطوة لاحقة.

تجدر الإشارة أيضًا إلى أنّ Cloud Build تنشئ تلقائيًا أداة المصادقة built-by-cloud-build في مشروعك عند تنفيذ إصدار ينشئ الصور. بالتالي، يعرض الأمر أعلاه مصادقتين، vulnz-attestor وbuilt-by-cloud-build. بعد إنشاء الصور بنجاح، تُوقِّع Cloud Build تلقائيًا وتنشئ شهادات لها.

جارٍ إضافة دور "إدارة الهوية وإمكانية الوصول"

سيحتاج حساب خدمة التفويض الثنائي إلى حقوق لعرض ملاحظات المصادقة. توفير إمكانية الوصول من خلال طلب البيانات التالي من واجهة برمجة التطبيقات

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}"  --format="value(projectNumber)")

BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"


cat > ./iam_request.json << EOM
{
  'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${BINAUTHZ_SA_EMAIL}'
        ]
      }
    ]
  }
}
EOM

استخدام الملف لإنشاء سياسة إدارة الهوية وإمكانية الوصول

curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @./iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

إضافة مفتاح KMS

قبل أن تتمكّن من استخدام أداة المصادقة هذه، يجب أن تُنشئ سلطتك زوجًا من مفاتيح التشفير يمكن استخدامه لتوقيع صور الحاوية. ويمكن إجراء ذلك من خلال خدمة إدارة المفاتيح في Google Cloud (KMS).

أضف أولاً بعض متغيرات البيئة لوصف المفتاح الجديد

KEY_LOCATION=global
KEYRING=binauthz-keys
KEY_NAME=codelab-key
KEY_VERSION=1

إنشاء سلسلة مفاتيح للاحتفاظ بمجموعة من المفاتيح

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

إنشاء مفتاحَي توقيع غير متماثلين جديد للمصنِّف

gcloud kms keys create "${KEY_NAME}" \
    --keyring="${KEYRING}" --location="${KEY_LOCATION}" \
    --purpose asymmetric-signing   \
    --default-algorithm="ec-sign-p256-sha256"

من المفترض أن يظهر المفتاح على صفحة KMS على Google Cloud Console.

والآن، اربط المفتاح بالمصنِّف من خلال الأمر gcloud binauthz:

gcloud beta container binauthz attestors public-keys add  \
    --attestor="${ATTESTOR_ID}"  \
    --keyversion-project="${PROJECT_ID}"  \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

إذا طبعت قائمة جهات إصدار الاعتماد مرة أخرى، من المفترض أن يظهر لك الآن مفتاح مسجَّل:

gcloud container binauthz attestors list

إنشاء مصادقة موقَّعة

في هذه المرحلة، لديك الميزات المهيأة التي تمكّنك من توقيع الصور. استخدم Attestor الذي قمت بإنشائه مسبقًا لتوقيع صورة الحاوية التي كنت تعمل معها.

يجب أن تتضمّن المصادقة توقيعًا مشفرًا للإشارة إلى أنّ جهة المصادقة قد أثبتت ملكية صورة حاوية معيّنة وأنّها آمنة ليتم تشغيلها في مجموعتك. لتحديد صورة الحاوية التي يجب المصادقة عليها، تحتاج إلى تحديد ملخصها.

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
    --format='get(image_summary.digest)')

الآن، يمكنك استخدام gcloud لإنشاء المصادقة. يأخذ الأمر ببساطة تفاصيل المفتاح الذي تريد استخدامه للتوقيع، وصورة الحاوية المحددة التي تريد الموافقة عليها

gcloud beta container binauthz attestations sign-and-create  \
    --artifact-url="${CONTAINER_PATH}@${DIGEST}" \
    --attestor="${ATTESTOR_ID}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${PROJECT_ID}" \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

في عبارات تحليل الحاوية، سيؤدي ذلك إلى إنشاء موضع ورود جديد، وإرفاقه بملاحظة المُصدِّر. لضمان سير الأمور على النحو المتوقع، يمكنك سرد تصديقاتك.

gcloud container binauthz attestations list \
   --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

4. سياسات مراقبة الدخول

التفويض الثنائي هو ميزة في GKE وCloud Run توفّر إمكانية التحقّق من صحة القواعد قبل السماح بتشغيل صورة الحاوية. يتم تنفيذ عملية التحقّق على أي طلب لتشغيل أي صورة، سواء كانت من مسار CI/CD موثوق به أو من مستخدم يحاول نشر صورة يدويًا. تسمح لك هذه الميزة بتأمين بيئات وقت التشغيل بفعالية أكبر من عمليات فحص مسار التكامل والاستجابة المضمّنة، وذلك بمفردها.

لفهم هذه الإمكانية، يجب تعديل سياسة GKE التلقائية لفرض قاعدة تفويض صارمة.

إنشاء مجموعة GKE

إنشاء مجموعة GKE مع تفعيل المصادقة الثنائية:

gcloud beta container clusters create binauthz \
    --zone us-central1-a  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

السماح بنشر Cloud Build في هذه المجموعة:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/container.developer"

السماح بجميع السياسات

تحقَّق أولاً من حالة السياسة التلقائية ومن قدرتك على نشر أي صورة

1. مراجعة السياسة الحالية

gcloud container binauthz policy export

2. يُرجى العلم أنّه تم ضبط سياسة التنفيذ على ALWAYS_ALLOW.

evaluationMode: ALWAYS_ALLOW

3. انشر النموذج للتأكّد من إمكانية تفعيل أي عنصر.

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

4. التحقّق من نجاح عملية النشر

kubectl get pods

سيظهر لك الناتج التالي

5. حذف النشر

kubectl delete pod hello-server

رفض كل السياسات

يُرجى تعديل السياسة الآن لمنع جميع الصور.

1. تصدير السياسة الحالية إلى ملف قابل للتعديل

gcloud container binauthz policy export  > policy.yaml

2. تغيير السياسة

في محرِّر نصوص، غيِّر evaluationMode من ALWAYS_ALLOW إلى ALWAYS_DENY.

edit policy.yaml

من المفترض أن يظهر ملف YAML للسياسة على النحو التالي:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_DENY
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

هذه السياسة بسيطة نسبيًا. يوضِّح سطر globalPolicyEvaluationMode أنّ هذه السياسة توسِّع نطاق السياسة العامة التي حدَّدتها Google. يسمح هذا الإجراء بتشغيل جميع حاويات GKE الرسمية بشكلٍ تلقائي. بالإضافة إلى ذلك، تنص السياسة على سمة defaultAdmissionRule التي تنصّ على أنّه سيتم رفض جميع المجموعات الأخرى المتسلسلة الأخرى. تتضمن قاعدة الإدخال سطر enforcementMode الذي ينص على أنّه يجب حظر تشغيل جميع مجموعات الإعلانات المتسلسلة غير المتوافقة مع هذه القاعدة في المجموعة.

للحصول على تعليمات حول كيفية إنشاء سياسات أكثر تعقيدًا، يمكنك الاطّلاع على مستندات التفويض الثنائي.

3. افتح Terminal وطبِّق النهج الجديد وانتظر بضع ثوانٍ حتى يتم نشر التغيير.

gcloud container binauthz policy import policy.yaml

4. محاولة نشر نموذج من حجم العمل

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

5. تعذُّر النشر مع ظهور الرسالة التالية

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

عليك إلغاء السياسة للسماح بجميع

قبل الانتقال إلى القسم التالي، تأكَّد من إلغاء التغييرات التي أُجريت على السياسة.

1. تغيير السياسة

في محرِّر نصوص، غيِّر evaluationMode من ALWAYS_DENY إلى ALWAYS_ALLOW.

edit policy.yaml

من المفترض أن يظهر ملف YAML للسياسة على النحو التالي:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

2. تطبيق السياسة التي تم التراجع عنها

gcloud container binauthz policy import policy.yaml

5- توقيع الصور الممسوحة ضوئيًا

لقد فعّلت توقيع الصورة واستخدمت المصدق يدويًا للتوقيع على نموذج الصورة. من الناحية العملية، ستحتاج إلى تطبيق الإقرارات أثناء العمليات الآلية مثل مسارات الإحالات الناجحة خارج إطار الإنترنت (CI/CD).

في هذا القسم، سيتم ضبط Cloud Build على "مصادقة الصور" تلقائيًا.

الأدوار

إضافة دور "مُشاهد التفويض الثنائي" إلى حساب خدمة Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/binaryauthorization.attestorsViewer

إضافة دور الموقِّع أو جهة التحقُّق من Cloud KMS إلى حساب خدمة Cloud Build (التوقيع المستنِد إلى KMS):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/cloudkms.signerVerifier

إضافة دور إرفاق ملاحظات تحليل الحاوية إلى حساب خدمة Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/containeranalysis.notes.attacher

توفير إذن الوصول إلى حساب خدمة Cloud Build

ستحتاج خدمة Cloud Build إلى إذن الوصول إلى واجهة برمجة التطبيقات للفحص عند الطلب. يمكنك منح إذن الوصول إلى الجهاز باستخدام الأوامر التالية.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/iam.serviceAccountUser"
        
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/ondemandscanning.admin"

الاستعداد لخطوة إنشاء السحابة الإلكترونية المخصّصة

ستستخدم خطوة "إنشاء مخصّص" في Cloud Build لتبسيط عملية المصادقة. توفِّر Google خطوة الإنشاء المخصّص هذه التي تحتوي على وظائف مساعدة لتبسيط العملية. قبل الاستخدام، يجب تضمين الرمز لخطوة التصميم المخصّصة في حاوية وإرسال هذا الرمز إلى Cloud Build. للقيام بذلك، شغِّل الأوامر التالية:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml
cd ../..
rm -rf cloud-builders-community

أضِف خطوة توقيع إلى cloudbuild.yaml

في هذه الخطوة، عليك إضافة خطوة المصادقة إلى مسار Cloud Build.

1. راجِع خطوة التوقيع أدناه.

للمراجعة فقط. عدم النسخ

#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

2. اكتب ملف cloudbuild.yaml مع المسار الكامل أدناه.

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'



images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF

إدارة عملية الإنشاء

gcloud builds submit

مراجعة الإصدار في "سجلّ إنشاء السحابة الإلكترونية"

افتح Cloud Console للانتقال إلى صفحة "سجلّ إنشاء Cloud" وراجِع آخر إصدار وعملية التنفيذ الناجحة لخطوات الإصدار.

6- السماح بالصور الموقَّعة

في هذا القسم، سيتم تعديل GKE لاستخدام "التفويض الثنائي" للتحقّق من أنّ الصورة تتضمّن توقيعًا من فحص الثغرات الأمنية قبل السماح بتشغيل الصورة.

تعديل سياسة GKE لطلب المصادقة

اشتراط توقيع الصور من خلال المصادق من خلال إضافة clusterAdmissionRules إلى سياسة GKE BinAuth.

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

استبدِل السياسة بالإعدادات المعدَّلة باستخدام الأمر أدناه.

COMPUTE_ZONE=us-central1-a

cat > binauth_policy.yaml << EOM
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
  ${COMPUTE_ZONE}.binauthz:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor
EOM

يُفترض أن يكون لديك الآن ملف جديد على القرص، اسمه updated_policy.yaml. أمّا الآن، فبدلاً من القاعدة التلقائية التي ترفض جميع الصور، يتم أولاً التحقّق من المُصدِّر بشأن عمليات إثبات الملكية.

حمِّل السياسة الجديدة إلى التفويض الثنائي:

gcloud beta container binauthz policy import binauth_policy.yaml

نشر صورة موقَّعة

الحصول على ملخص الصورة للحصول على صورة جيدة

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \
    --format='get(image_summary.digest)')

استخدام الملخّص في إعدادات Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

نشر التطبيق على GKE

kubectl apply -f deploy.yaml

راجِع عبء العمل في وحدة التحكّم وراجِع عملية النشر الناجحة للصورة.

7. تم حظر الصور غير الموقَّعة.

إنشاء صورة

في هذه الخطوة، ستستخدم Docker على الجهاز لإنشاء الصورة في ذاكرة التخزين المؤقّت على الجهاز.

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

إرسال الصورة غير الموقَّعة إلى المستودع

docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

الحصول على ملخص الصور للصورة السيئة

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \
    --format='get(image_summary.digest)')

استخدام الملخّص في إعدادات Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

محاولة نشر التطبيق على GKE

kubectl apply -f deploy.yaml

راجِع عبء العمل في وحدة التحكّم ولاحظ الخطأ الذي يشير إلى رفض عملية النشر:

No attestations found that were valid and signed by a key trusted by the attestor

8. تهانينا

تهانينا، لقد أنهيت الدرس التطبيقي حول الترميز.

المواضيع التي تناولناها:

• توقيع الصور
• سياسات مراقبة الدخول
• توقيع الصور الممسوحة ضوئيًا
• السماح بالصور الموقَّعة
• تم حظر الصور غير الموقَّعة.

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

• تأمين عمليات نشر الصور في Cloud Run وGoogle Kubernetes Engine | مستندات Cloud Build
• البدء السريع: ضبط سياسة التفويض الثنائي باستخدام GKE | Google Cloud

تَنظيم

لتجنُّب تحمُّل الرسوم المفروضة على حسابك على Google Cloud مقابل الموارد المُستخدَمة في هذا الدليل التوجيهي، يمكنك إما حذف المشروع الذي يحتوي على الموارد أو الاحتفاظ بالمشروع وحذف الموارد الفردية.

حذف المشروع

أسهل طريقة لإزالة الفوترة هي حذف المشروع الذي أنشأته للبرنامج التعليمي.

—

تاريخ التعديل الأخير: 21/3/23