بناء آمن النشر باستخدام Cloud Build و Artifact Registry وGKE

1. مقدمة

توفّر ميزة "تحليل الحاويات" فحص الثغرات الأمنية وتخزين البيانات الوصفية للحاويات. تُجري خدمة الفحص عمليات فحص للثغرات الأمنية في الصور في Artifact Registry وContainer Registry، ثم تخزِّن البيانات الوصفية الناتجة وتُتاح للاستخدام من خلال واجهة برمجة تطبيقات. يتيح لك تخزين البيانات الوصفية تخزين معلومات من مصادر مختلفة، بما في ذلك فحص نقاط الضعف وخدمات Google Cloud ومقدّمي الخدمات الخارجيين.

يمكن أن يتم البحث عن الثغرات الأمنية تلقائيًا أو عند الطلب:

• عند تفعيل المسح التلقائي، يتم بدء عملية المسح تلقائيًا في كل مرة تُحمِّل فيها صورة جديدة إلى Artifact Registry أو Container Registry. يتم تعديل معلومات الثغرات باستمرار عند اكتشاف ثغرات جديدة.
• عند تفعيل ميزة المسح الضوئي عند الطلب، يجب تنفيذ أمر لمسح صورة محلية أو صورة في Artifact Registry أو Container Registry ضوئيًا. تمنحك ميزة "المسح الضوئي عند الطلب" المرونة في تحديد وقت مسح الحاويات ضوئيًا. على سبيل المثال، يمكنك فحص صورة تم إنشاؤها محليًا ومعالجة الثغرات الأمنية قبل تخزينها في سجلّ. تتوفّر نتائج الفحص لمدة تصل إلى 48 ساعة بعد اكتمال الفحص، ولا يتم تعديل معلومات الثغرات بعد الفحص.

من خلال دمج ميزة "تحليل الحِزم" في مسار عمل التطوير المتكامل/النشر الدائم، يمكنك اتخاذ قرارات استنادًا إلى هذه البيانات الوصفية. على سبيل المثال، يمكنك استخدام Binary Authorization لإنشاء سياسات نشر لا تسمح إلا بعمليات نشر الصور المتوافقة من السجلات الموثوق بها.

ما ستتعرّف عليه

• كيفية تفعيل ميزة "المسح التلقائي"
• كيفية إجراء "المسح عند الطلب"
• كيفية دمج عملية المسح في مسار إنشاء
• كيفية توقيع الصور الموافَق عليها
• كيفية استخدام أدوات التحكّم في الدخول في GKE لحظر الصور
• كيفية ضبط GKE للسماح بالصور الموافَق عليها والموقَّعة فقط

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

إعداد البيئة حسب وتيرة الطالب واحتياجاته

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

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

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

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

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

ابدأ محرِّر Cloudshell.

تم تصميم هذا البرنامج التدريبي واختباره للاستخدام مع محرِّر Google Cloud Shell. للوصول إلى المحرِّر، اتّبِع الخطوات التالية:

1. يمكنك الوصول إلى مشروعك على Google على الرابط https://console.cloud.google.com.
2. في أعلى يسار الصفحة، انقر على رمز محرِّر Cloud Shell.

3. ستفتح لوحة جديدة في أسفل نافذتك.

إعداد البيئة

في 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

3- البحث الآلي

يتم بدء فحص العناصر تلقائيًا في كل مرة تُحمِّل فيها صورة جديدة إلى Artifact Registry أو Container Registry. يتم تعديل معلومات الثغرات باستمرار عند اكتشاف ثغرات جديدة. في هذا القسم، ستُرسِل صورة إلى "مستودع العناصر" وستستكشف النتائج.

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

mkdir vuln-scan && cd vuln-scan

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

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

cat > ./Dockerfile << EOF
FROM gcr.io/google-appengine/debian9@sha256:ebffcf0df9aa33f342c4e1d4c8428b784fc571cdf6fbab0b31330347ca8af97a

# System
RUN apt update && apt install python3-pip -y

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==1.1.4
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 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. لاحِظ العلامة bad على الصورة. سيساعدك ذلك في التعرّف عليه لتنفيذ الخطوات اللاحقة.

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

مراجعة تفاصيل الصورة

بعد اكتمال عملية الإنشاء، راجِع الصورة ونتائج الثغرات الأمنية في لوحة بيانات Artifact Registry.

1. افتح Artifact Registry في Cloud Console.
2. انقر على مستودع artifact-scanning-repo لعرض المحتوى.
3. انقر على تفاصيل الصورة.
4. انقر على أحدث ملخّص لصورتك.
5. بعد انتهاء عملية الفحص، انقر على علامة التبويب "الثغرات الأمنية" للصورة.

من علامة التبويب "الثغرات الأمنية"، ستظهر لك نتائج عملية الفحص التلقائي للصورة التي أنشأتها للتو.

تكون ميزة المسح التلقائي مفعّلة تلقائيًا. استكشِف إعدادات "مستودع العناصر" لمعرفة كيفية إيقاف/تفعيل المسح التلقائي.

4. البحث عند الطلب

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

إنشاء صورة

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

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

مسح الصورة ضوئيًا

بعد إنشاء الصورة، اطلب مسحها ضوئيًا. يتم تخزين نتائج الفحص في خادم بيانات وصفية. تكتمل المهمة مع تحديد موقع النتائج في خادم البيانات الوصفية.

gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --format="value(response.scan)" > scan_id.txt

مراجعة ملف الإخراج

يُرجى تخصيص بعض الوقت لمراجعة نتيجة الخطوة السابقة التي تم تخزينها في ملف scan_id.txt. لاحِظ موقع تقرير نتائج الفحص في خادم البيانات الوصفية.

cat scan_id.txt

مراجعة نتائج الفحص التفصيلية

للاطّلاع على النتائج الفعلية للفحص، استخدِم الأمر list-vulnerabilities في موقع التقرير المُشار إليه في ملف الإخراج.

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) 

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

الإبلاغ عن المشاكل الحرجة

نادرًا ما يستخدم الأشخاص البيانات المخزّنة في التقرير مباشرةً. وعادةً ما يتم استخدام النتائج من خلال عملية مبرمَجة. استخدِم الأوامر أدناه لقراءة تفاصيل التقرير وتسجيل أي ثغرات أمنية خطيرة يتم رصدها.

export SEVERITY=CRITICAL

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq ${SEVERITY}; then echo "Failed vulnerability check for ${SEVERITY} level"; else echo "No ${SEVERITY} Vulnerabilities found"; fi

ستكون نتيجة هذا الأمر كما يلي:

Failed vulnerability check for CRITICAL level

5- إنشاء ميزة "فحص مسار الإحالة الناجحة"

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

منح إذن الوصول لحساب خدمة 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

سيؤدي الأمر التالي إلى إنشاء ملف 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']

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

تشغيل مسار عملية الدمج المستمر

أرسِل الإصدار للمعالجة للتأكّد من حدوث أعطال في الإصدار عند العثور على ثغرة أمنية ذات خطورة CRITICAL.

gcloud builds submit

تعذُّر إنشاء المراجعة

لن يتم إكمال عملية الإنشاء التي أرسلتها للتو لأنّ الصورة تحتوي على ثغرات أمنية خطيرة.

راجِع سبب تعذُّر الإنشاء في صفحة سجلّ Cloud Build.

إصلاح الثغرة الأمنية

عدِّل ملف Dockerfile لاستخدام صورة أساسية لا تحتوي على ثغرات أمنية خطيرة.

استبدِل ملف Dockerfile لاستخدام صورة Debian 10 باستخدام الأمر التالي:

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

تشغيل عملية التكامل المستمر باستخدام الصورة الصالحة

أرسِل الإصدار للمعالجة للتأكّد من نجاحه في حال عدم العثور على أي ثغرات أمنية ذات خطورة CRITICAL.

gcloud builds submit

اكتمال عملية مراجعة الإصدار

سيتم إكمال عملية إرسال الإصدار الذي أرسلته للتو لأنّ الصورة المعدَّلة لا تحتوي على أي ثغرات أمنية خطيرة.

راجِع نجاح عملية الإنشاء في صفحة سجلّ عمليات الإنشاء في Cloud.

مراجعة نتائج الفحص

مراجعة الصورة الصالحة في سجلّ العناصر

1. افتح Artifact Registry في Cloud Console.
2. انقر على مستودع artifact-scanning-repo لعرض المحتوى.
3. انقر على تفاصيل الصورة.
4. انقر على أحدث ملخّص لصورتك.
5. انقر على علامة التبويب "الثغرات الأمنية" للصورة.

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

إنشاء ملاحظة مُثبِّت

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

إنشاء ملاحظة

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}"

إنشاء جهة إثبات الهوية

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

إنشاء جهة إثبات الهوية

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 تلقائيًا شهادات اعتماد لها وينشئها.

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

سيحتاج حساب الخدمة Binary Authorization إلى أذونات لعرض ملاحظات الإقرار. يمكنك منح الإذن بالوصول باستخدام طلب البيانات من واجهة برمجة التطبيقات التالي:

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) لخدمة Cloud Build للوصول إليها لاحقًا.

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

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

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

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

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}

7- التوقيع باستخدام Cloud Build

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

في هذا القسم، ستضبط 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 لتبسيط عملية الإقرار. تقدّم 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 Build

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

8. سياسات التحكّم في الدخول

الإذن الثنائي هو ميزة في 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

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

9. حظر الثغرات الأمنية في GKE

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

تعديل سياسة GKE لطلب شهادة الاعتماد

اشترِط أن يوقّع مُثبِّت الهوية على الصور من خلال إضافة clusterAdmissionRules إلى سياسة BinAuth في GKE.

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

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

تطبيق السياسة

gcloud beta container binauthz policy import binauth_policy.yaml

محاولة نشر الصورة غير الموقَّعة

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

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

الحصول على ملخّص الصورة للصورة غير الصالحة

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

محاولة نشر التطبيق على "خدمات Google لتنسيق Kubernetes"

kubectl apply -f deploy.yaml

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

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

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

الحصول على ملخّص الصورة للصورة غير الصالحة

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

نشر التطبيق على Google Kubernetes Engine

kubectl apply -f deploy.yaml

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

10. تهانينا!

تهانينا، لقد أكملت دورة codelab.

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

• كيفية تفعيل ميزة "المسح التلقائي"
• كيفية إجراء "المسح عند الطلب"
• كيفية دمج عملية المسح في مسار إنشاء
• كيفية توقيع الصور الموافَق عليها
• كيفية استخدام أدوات التحكّم في الدخول في GKE لحظر الصور
• كيفية ضبط GKE للسماح بالصور الموافَق عليها والموقَّعة فقط

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

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

تَنظيم

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

حذف المشروع

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