استقرار گیتینگ با احراز هویت باینری

1. مقدمه

مجوز دودویی یک کنترل امنیتی در زمان استقرار است که تضمین می کند فقط تصاویر کانتینر مورد اعتماد در موتور Google Kubernetes (GKE) یا Cloud Run مستقر می شوند. با مجوز دودویی، می‌توانید در طول فرآیند توسعه، تصاویر را ملزم به امضای مقامات مورد اعتماد کنید و سپس اعتبار امضا را هنگام استقرار اعمال کنید. با اعمال اعتبارسنجی، می‌توانید با اطمینان از اینکه فقط تصاویر تأیید شده در فرآیند ساخت و انتشار ادغام می‌شوند، کنترل دقیق‌تری بر محیط کانتینر خود به دست آورید.

نمودار زیر مؤلفه‌های یک مجوز باینری/راه‌اندازی ساخت ابر را نشان می‌دهد:

**شکل 1.**خط لوله ساخت Cloud که یک گواهی مجوز باینری ایجاد می کند.

در این خط لوله:

1. کد برای ساخت تصویر کانتینر به یک مخزن منبع مانند مخازن منبع ابری منتقل می شود.
2. ابزار یکپارچه سازی پیوسته (CI)، Cloud Build ظرف را می سازد و آزمایش می کند.
3. ساخت، تصویر ظرف را به Container Registry یا رجیستری دیگری که تصاویر ساخته شده شما را ذخیره می‌کند، هدایت می‌کند.
4. سرویس مدیریت کلید ابری ، که مدیریت کلید را برای جفت کلید رمزنگاری فراهم می کند، تصویر ظرف را امضا می کند. سپس امضای به دست آمده در یک گواهی جدید ایجاد شده ذخیره می شود.
5. در زمان استقرار، گواهی‌دهنده گواهی را با استفاده از کلید عمومی از جفت کلید تأیید می‌کند. مجوز دودویی این خط‌مشی را با الزام گواهی‌های امضا شده برای استقرار تصویر کانتینر اجرا می‌کند.

در این آزمایشگاه شما بر روی ابزارها و تکنیک های ایمن سازی مصنوعات مستقر شده تمرکز خواهید کرد. این آزمایشگاه بر روی مصنوعات (ظروف) پس از ایجاد آنها اما در محیط خاصی مستقر نشده اند تمرکز می کند.

چیزی که یاد خواهید گرفت

• امضای تصویر
• سیاست های کنترل پذیرش
• امضای تصاویر اسکن شده
• تأیید تصاویر امضا شده
• تصاویر بدون امضا مسدود شد

2. راه اندازی و الزامات

تنظیم محیط خود به خود

1. به Google Cloud Console وارد شوید و یک پروژه جدید ایجاد کنید یا از یک موجود استفاده مجدد کنید. اگر قبلاً یک حساب Gmail یا Google Workspace ندارید، باید یک حساب ایجاد کنید .

• نام پروژه نام نمایشی برای شرکت کنندگان این پروژه است. این یک رشته کاراکتری است که توسط API های Google استفاده نمی شود. شما می توانید آن را در هر زمان به روز کنید.
• شناسه پروژه در تمام پروژه‌های Google Cloud منحصربه‌فرد است و تغییرناپذیر است (پس از تنظیم نمی‌توان آن را تغییر داد). Cloud Console به طور خودکار یک رشته منحصر به فرد تولید می کند. معمولاً برای شما مهم نیست که چیست. در اکثر کدها، باید به شناسه پروژه ارجاع دهید (معمولاً به عنوان PROJECT_ID شناخته می شود). اگر شناسه تولید شده را دوست ندارید، ممکن است یک شناسه تصادفی دیگر ایجاد کنید. از طرف دیگر، می‌توانید خودتان را امتحان کنید و ببینید آیا در دسترس است یا خیر. پس از این مرحله نمی توان آن را تغییر داد و در طول مدت پروژه باقی می ماند.
• برای اطلاع شما، یک مقدار سوم وجود دارد، یک شماره پروژه که برخی از API ها از آن استفاده می کنند. در مورد هر سه این مقادیر در مستندات بیشتر بیاموزید.

احتیاط: شناسه پروژه در سطح جهانی منحصر به فرد است و پس از انتخاب شما توسط هیچ کس دیگری قابل استفاده نیست. شما تنها کاربر آن شناسه هستید. حتی اگر پروژه ای حذف شود، ID هرگز نمی تواند دوباره استفاده شود

توجه: اگر از یک حساب Gmail استفاده می‌کنید، می‌توانید مکان پیش‌فرض را روی «بدون سازمان» بگذارید. اگر از حساب Google Workspace استفاده می‌کنید، مکانی را انتخاب کنید که برای سازمان شما منطقی باشد.

2. در مرحله بعد، برای استفاده از منابع Cloud/APIها باید صورتحساب را در کنسول 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 برای ذخیره و اسکن تصاویر خود استفاده خواهید کرد. با دستور زیر مخزن را ایجاد کنید.

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

داکر را برای استفاده از اعتبار gcloud خود هنگام دسترسی به رجیستری مصنوع پیکربندی کنید.

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

تصویر را بسازید و به AR فشار دهید

از Cloud Build برای ساختن و به طور خودکار کانتینر خود را به Artifact Registry فشار دهید.

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

3. امضای تصویر

گواهی دهنده چیست

گواهی دهنده

• این شخص/فرایند مسئول یک حلقه در زنجیره اعتماد سیستم است.
• آنها یک کلید رمزنگاری را در دست دارند و در صورت گذراندن مراحل تأیید، تصویری را امضا می کنند.
• در حالی که ایجاد کننده خط مشی، خط مشی را به روشی سطح بالا و انتزاعی تعیین می کند، تأیید کننده مسئول اجرای دقیق برخی از جنبه های خط مشی است.
• ممکن است یک شخص واقعی باشد، مانند یک آزمایشگر QA یا یک مدیر، یا ممکن است یک ربات در یک سیستم CI باشد.
• امنیت سیستم به قابل اعتماد بودن آنها بستگی دارد، بنابراین مهم است که کلیدهای خصوصی آنها ایمن نگه داشته شوند.

هر یک از این نقش ها می تواند نماینده یک فرد یا تیمی از افراد در سازمان شما باشد. در یک محیط تولید، این نقش‌ها احتمالاً توسط پروژه‌های Google Cloud Platform (GCP) جداگانه مدیریت می‌شوند و دسترسی به منابع با استفاده از Cloud IAM به شکل محدودی بین آنها به اشتراک گذاشته می‌شود.

گواهی‌دهنده‌ها در مجوز باینری در بالای Cloud Container Analysis API پیاده‌سازی می‌شوند، بنابراین مهم است که قبل از ادامه کار توضیح دهید که چگونه کار می‌کند. Container Analysis API طوری طراحی شده است که به شما امکان می دهد ابرداده را با تصاویر کانتینر خاص مرتبط کنید.

به عنوان مثال، ممکن است یک یادداشت برای ردیابی آسیب پذیری Heartbleed ایجاد شود. سپس فروشندگان امنیتی اسکنرهایی را برای آزمایش تصاویر کانتینر برای آسیب‌پذیری ایجاد می‌کنند و یک رخداد مرتبط با هر کانتینر در معرض خطر ایجاد می‌کنند.

همراه با ردیابی آسیب‌پذیری‌ها، Container Analysis به عنوان یک API فراداده عمومی طراحی شده است. مجوز دودویی از تجزیه و تحلیل کانتینر برای مرتبط کردن امضاها با تصاویر کانتینری که آنها در حال تأیید هستند استفاده می کند**.** یادداشت تجزیه و تحلیل کانتینر برای نشان دادن یک گواهی کننده واحد استفاده می شود و رویدادها ایجاد می شوند و با هر ظرفی که تأیید کننده تأیید کرده است مرتبط می شود.

Binary Authorization API از مفاهیم "تأیید کننده ها" و "تأیید کننده ها" استفاده می کند، اما این ها با استفاده از یادداشت ها و رخدادهای مربوطه در API تجزیه و تحلیل کانتینر پیاده سازی می شوند.

یک یادداشت تأیید کننده ایجاد کنید

یادداشت تأیید کننده به سادگی یک بیت کوچک از داده است که به عنوان یک برچسب برای نوع امضای اعمال شده عمل می کند. به عنوان مثال، یک یادداشت ممکن است نشان دهنده اسکن آسیب پذیری باشد، در حالی که یکی دیگر ممکن است برای علامت QA استفاده شود. در حین امضاء به یادداشت ارجاع داده خواهد شد.

یک یادداشت ایجاد کنید

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 به طور خودکار امضا می کند و برای آنها گواهی ایجاد می کند.

اضافه کردن نقش IAM

حساب سرویس مجوز باینری برای مشاهده یادداشت‌های گواهی نیاز به حقوق دارد. دسترسی را با فراخوانی API زیر فراهم کنید

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

از فایل برای ایجاد سیاست IAM استفاده کنید

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

قبل از اینکه بتوانید از این گواهی‌دهنده استفاده کنید، مرجع شما باید یک جفت کلید رمزنگاری ایجاد کند که بتوان از آن برای امضای تصاویر ظرف استفاده کرد. این را می توان از طریق سرویس مدیریت کلید ابری گوگل (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 ظاهر می شود.

اکنون، کلید را از طریق دستور 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}"

به عبارت Container Analysis، این یک اتفاق جدید ایجاد می‌کند و آن را به یادداشت گواهی‌دهنده شما متصل می‌کند. برای اطمینان از اینکه همه چیز طبق انتظار انجام شده است، می توانید گواهینامه های خود را فهرست کنید

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

4. سیاست های کنترل پذیرش

Binary Authorization یک ویژگی در GKE و Cloud Run است که توانایی اعتبارسنجی قوانین را قبل از اجازه اجرا شدن تصویر کانتینر فراهم می‌کند. اعتبار سنجی در هر درخواستی برای اجرای یک تصویر اجرا می شود، خواه از یک خط لوله قابل اعتماد CI/CD باشد یا کاربری که به صورت دستی سعی در استقرار یک تصویر دارد. این قابلیت به شما این امکان را می دهد که محیط های زمان اجرا خود را به طور موثرتری نسبت به بررسی های خط لوله 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"

Allow All Policy

ابتدا وضعیت خط مشی پیش فرض و توانایی خود را برای استقرار هر تصویر بررسی کنید

1. سیاست موجود را مرور کنید

gcloud container binauthz policy export

2. توجه داشته باشید که خط مشی اجرایی روی ALWAYS_ALLOW تنظیم شده است

evaluationMode: ALWAYS_ALLOW

3. برای تأیید اینکه می‌توانید هر چیزی را مستقر کنید، Sample را مستقر کنید

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. سیاست را تغییر دهید

در یک ویرایشگر متن، ارزیابی حالت را از 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. ترمینال را باز کنید و سیاست جدید را اعمال کنید و چند ثانیه صبر کنید تا تغییر منتشر شود

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. سیاست را تغییر دهید

در یک ویرایشگر متن، ارزیابی حالت را از 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. امضای تصاویر اسکن شده

شما امضای تصویر را فعال کرده اید و به صورت دستی از Attestor برای امضای تصویر نمونه خود استفاده کرده اید. در عمل شما می خواهید گواهینامه ها را در طی فرآیندهای خودکار مانند خطوط لوله CI/CD اعمال کنید.

در این بخش ، Cloud Build را برای تأیید تصاویر به صورت خودکار پیکربندی خواهید کرد

نقش ها

نقش نمایشگر تأیید کننده مجوز باینری را به حساب سرویس ساخت ابری اضافه کنید:

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

نقش امضاکننده/تأییدکننده Cloud KMS CryptoKey را به حساب سرویس ساخت ابری (امضا مبتنی بر KMS) اضافه کنید:

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

نقش Attacher Notes Analysis Container را به حساب سرویس Cloud Build اضافه کنید:

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

دسترسی برای حساب خدمات ساخت ابری فراهم کنید

Cloud Build برای دسترسی به api اسکن درخواستی به حقوق نیاز دارد. با دستورات زیر دسترسی را فراهم کنید.

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 خود اضافه می کنید.

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

Build را اجرا کنید

gcloud builds submit

ساخت را در Cloud Build History مرور کنید

Cloud Console را به صفحه Cloud Build History باز کنید و آخرین ساخت و اجرای موفقیت آمیز مراحل ساخت را مرور کنید.

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 | مستندات ساخت ابر
• شروع سریع: یک خط مشی مجوز باینری را با GKE | پیکربندی کنید Google Cloud

پاک کن

برای جلوگیری از تحمیل هزینه به حساب Google Cloud خود برای منابع استفاده شده در این آموزش، یا پروژه حاوی منابع را حذف کنید یا پروژه را نگه دارید و منابع فردی را حذف کنید.

حذف پروژه

ساده ترین راه برای حذف صورتحساب، حذف پروژه ای است که برای آموزش ایجاد کرده اید.

-

آخرین به روز رسانی: 3/21/23