การสร้างที่ปลอดภัย ทำให้ใช้งานได้ด้วย Cloud Build, Artifact Registry และ GKE

1. บทนำ

Container Analysis มีการสแกนช่องโหว่และการจัดเก็บข้อมูลเมตาสำหรับคอนเทนเนอร์ บริการสแกนจะสแกนช่องโหว่ในอิมเมจใน Artifact Registry และ Container Registry จากนั้นจะจัดเก็บข้อมูลเมตาที่ได้และเปิดให้ใช้งานผ่าน API ที่เก็บข้อมูลเมตาช่วยให้คุณจัดเก็บข้อมูลจากแหล่งที่มาต่างๆ ได้ รวมถึงการสแกนช่องโหว่ บริการของ Google Cloud และผู้ให้บริการบุคคลที่สาม

การสแกนช่องโหว่จะเกิดขึ้นโดยอัตโนมัติหรือตามต้องการ

• เมื่อเปิดใช้การสแกนอัตโนมัติ การสแกนจะทริกเกอร์โดยอัตโนมัติทุกครั้งที่คุณพุชอิมเมจใหม่ไปยัง Artifact Registry หรือ Container Registry เราจะอัปเดตข้อมูลช่องโหว่อย่างต่อเนื่องเมื่อพบช่องโหว่ใหม่
• เมื่อเปิดใช้การสแกนตามต้องการ คุณต้องเรียกใช้คำสั่งเพื่อสแกนอิมเมจในเครื่องหรืออิมเมจใน Artifact Registry หรือ Container Registry การสแกนตามคำขอช่วยให้คุณมีความยืดหยุ่นในการเลือกเวลาที่จะสแกนคอนเทนเนอร์ เช่น คุณสามารถสแกนอิมเมจที่สร้างขึ้นในเครื่องและแก้ไขช่องโหว่ก่อนจัดเก็บไว้ในรีจิสทรี ผลการสแกนจะพร้อมใช้งานเป็นเวลาสูงสุด 48 ชั่วโมงหลังจากสแกนเสร็จสมบูรณ์ และระบบจะไม่ปรับปรุงข้อมูลช่องโหว่หลังการสแกน

เมื่อผสานรวม Container Analysis เข้ากับไปป์ไลน์ CI/CD คุณจะตัดสินใจโดยอิงตามข้อมูลเมตาดังกล่าวได้ เช่น คุณสามารถใช้การให้สิทธิ์แบบไบนารีเพื่อสร้างนโยบายการติดตั้งใช้งานที่อนุญาตให้ติดตั้งใช้งานได้เฉพาะอิมเมจที่เป็นไปตามข้อกำหนดจากรีจิสทรีที่เชื่อถือได้

สิ่งที่คุณจะได้เรียนรู้

• วิธีเปิดใช้การสแกนอัตโนมัติ
• วิธีทำการสแกนตามคำขอ
• วิธีผสานรวมการสแกนในไปป์ไลน์บิลด์
• วิธีลงนามในรูปภาพที่อนุมัติ
• วิธีใช้ตัวควบคุมการยอมรับของ GKE เพื่อบล็อกอิมเมจ
• วิธีกำหนดค่า GKE เพื่ออนุญาตเฉพาะอิมเมจที่ลงนามและได้รับอนุมัติ

2. การตั้งค่าและข้อกำหนด

การตั้งค่าสภาพแวดล้อมแบบเรียนรู้ด้วยตนเอง

1. ลงชื่อเข้าใช้ Google Cloud Console แล้วสร้างโปรเจ็กต์ใหม่หรือใช้โปรเจ็กต์ที่มีอยู่ซ้ำ หากยังไม่มีบัญชี Gmail หรือ Google Workspace คุณต้องสร้างบัญชี

• ชื่อโปรเจ็กต์คือชื่อที่แสดงสำหรับผู้เข้าร่วมโปรเจ็กต์นี้ ซึ่งเป็นสตริงอักขระที่ Google APIs ไม่ได้ใช้ โดยคุณจะอัปเดตได้ทุกเมื่อ
• รหัสโปรเจ็กต์จะไม่ซ้ำกันในโปรเจ็กต์ Google Cloud ทั้งหมดและเปลี่ยนแปลงไม่ได้ (เปลี่ยนไม่ได้หลังจากตั้งค่าแล้ว) Cloud Console จะสร้างสตริงที่ไม่ซ้ำกันโดยอัตโนมัติ ซึ่งโดยปกติแล้วคุณไม่จำเป็นต้องสนใจว่าสตริงนั้นคืออะไร ใน Codelab ส่วนใหญ่ คุณจะต้องอ้างอิงรหัสโปรเจ็กต์ (โดยปกติจะระบุเป็น PROJECT_ID) หากไม่ชอบรหัสที่สร้างขึ้น คุณก็สร้างรหัสแบบสุ่มอีกรหัสหนึ่งได้ หรือคุณจะลองใช้ชื่อของคุณเองเพื่อดูว่าพร้อมใช้งานหรือไม่ก็ได้ คุณจะเปลี่ยนแปลงรหัสนี้หลังจากขั้นตอนนี้ไม่ได้ และรหัสจะยังคงอยู่ตลอดระยะเวลาของโปรเจ็กต์
• โปรดทราบว่ายังมีค่าที่ 3 ซึ่งคือหมายเลขโปรเจ็กต์ที่ API บางตัวใช้ ดูข้อมูลเพิ่มเติมเกี่ยวกับค่าทั้ง 3 นี้ได้ในเอกสารประกอบ

ข้อควรระวัง: รหัสโปรเจ็กต์จะไม่ซ้ำกันทั่วโลกและบุคคลอื่นจะใช้รหัสโปรเจ็กต์ที่คุณเลือกไม่ได้ คุณเป็นผู้ใช้รหัสดังกล่าวเพียงคนเดียว แม้ว่าจะลบโปรเจ็กต์ไปแล้ว แต่ก็ไม่สามารถใช้รหัสนั้นได้อีก

หมายเหตุ: หากใช้บัญชี Gmail คุณสามารถปล่อยให้ตำแหน่งเริ่มต้นเป็นไม่มีองค์กรได้ หากใช้บัญชี Google Workspace ให้เลือกสถานที่ตั้งที่เหมาะสมกับองค์กร

2. จากนั้นคุณจะต้องเปิดใช้การเรียกเก็บเงินใน Cloud Console เพื่อใช้ทรัพยากร/API ของ Cloud การทำตาม Codelab นี้ไม่ควรมีค่าใช้จ่ายมากนัก หรืออาจไม่มีเลย หากต้องการปิดทรัพยากรเพื่อไม่ให้มีการเรียกเก็บเงินนอกเหนือจากบทแนะนำนี้ คุณสามารถลบทรัพยากรที่สร้างขึ้นหรือลบทั้งโปรเจ็กต์ได้ ผู้ใช้ Google Cloud รายใหม่มีสิทธิ์เข้าร่วมโปรแกรมช่วงทดลองใช้ฟรีมูลค่า$300 USD

เริ่มโปรแกรมแก้ไข Cloud Shell

Lab นี้ออกแบบและทดสอบเพื่อใช้กับ Google Cloud Shell Editor วิธีเข้าถึงเครื่องมือแก้ไข

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 จะทริกเกอร์โดยอัตโนมัติทุกครั้งที่คุณพุชอิมเมจใหม่ไปยัง Artifact Registry หรือ Container Registry เราจะอัปเดตข้อมูลช่องโหว่อย่างต่อเนื่องเมื่อพบช่องโหว่ใหม่ ในส่วนนี้ คุณจะพุชอิมเมจไปยัง Artifact 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

สร้างและพุชอิมเมจไปยัง AR

ใช้ 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. เมื่อสแกนเสร็จแล้ว ให้คลิกแท็บช่องโหว่สำหรับรูปภาพ

จากแท็บช่องโหว่ คุณจะเห็นผลการสแกนอัตโนมัติสำหรับอิมเมจที่คุณเพิ่งสร้าง

ระบบจะเปิดใช้การสแกนอัตโนมัติโดยค่าเริ่มต้น ดูการตั้งค่า Artifact Registry เพื่อดูวิธีเปิด/ปิดการสแกนอัตโนมัติ

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 จะต้องมีสิทธิ์เข้าถึง 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

คำสั่งต่อไปนี้จะสร้างไฟล์ 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

เรียกใช้ไปป์ไลน์ CI

ส่งบิลด์เพื่อประมวลผลเพื่อยืนยันว่าบิลด์จะหยุดทำงานเมื่อพบช่องโหว่ที่มีความรุนแรงระดับวิกฤต

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

เรียกใช้กระบวนการ CI ด้วยอิมเมจที่ดี

ส่งบิลด์เพื่อประมวลผลเพื่อยืนยันว่าบิลด์จะสำเร็จเมื่อไม่พบช่องโหว่ที่มีความรุนแรงระดับวิกฤต

gcloud builds submit

ตรวจสอบความสำเร็จของการสร้าง

บิลด์ที่คุณเพิ่งส่งจะสำเร็จเนื่องจากอิมเมจที่อัปเดตไม่มีช่องโหว่ร้ายแรง

ตรวจสอบว่าบิลด์สำเร็จในหน้าประวัติ Cloud Build

ตรวจสอบผลการสแกน

ตรวจสอบรูปภาพที่ดีใน Artifact Registry

1. เปิด Artifact Registry ใน Cloud Console
2. คลิกที่ artifact-scanning-repo เพื่อดูเนื้อหา
3. คลิกดูรายละเอียดรูปภาพ
4. คลิกสรุปข้อมูลล่าสุดของรูปภาพ
5. คลิกแท็บช่องโหว่สำหรับอิมเมจ

6. การลงนามใน Google รูปภาพ

สร้างหมายเหตุผู้รับรอง

Attestor Note เป็นเพียงข้อมูลเล็กๆ ที่ทำหน้าที่เป็นป้ายกำกับสำหรับประเภทลายเซ็นที่ใช้ เช่น โน้ตหนึ่งอาจระบุการสแกนช่องโหว่ ขณะที่อีกโน้ตหนึ่งอาจใช้สำหรับการลงนาม 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}"

การสร้างผู้รับรอง

ระบบจะใช้ผู้รับรองเพื่อดำเนินการลงนามในรูปภาพจริง และจะแนบอินสแตนซ์ของโน้ตกับรูปภาพเพื่อการยืนยันในภายหลัง สร้าง Attestor เพื่อใช้ในภายหลัง

สร้างผู้รับรอง

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ผู้รับรองในโปรเจ็กต์โดยอัตโนมัติเมื่อคุณเรียกใช้บิลด์ที่สร้างอิมเมจ ดังนั้นคำสั่งด้านบนจะแสดง Attestor 2 ราย ได้แก่ 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 เพื่อให้ 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

ตอนนี้เชื่อมโยงคีย์กับผู้รับรองผ่านคำสั่ง 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}"

ในแง่ของ Container Analysis การดำเนินการนี้จะสร้างรายการใหม่และแนบไปกับโน้ตของผู้รับรอง คุณสามารถแสดงรายการการรับรองเพื่อให้มั่นใจว่าทุกอย่างทำงานตามที่คาดไว้

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

7. การลงนามด้วย Cloud Build

คุณได้เปิดใช้การลงนามรูปภาพและใช้ Attestor ด้วยตนเองเพื่อลงนามในรูปภาพตัวอย่าง ในทางปฏิบัติ คุณจะต้องใช้การรับรองในระหว่างกระบวนการอัตโนมัติ เช่น ไปป์ไลน์ 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 CryptoKey ให้บัญชีบริการ Cloud Build (การลงนามที่อิงตาม KMS)

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

เพิ่มบทบาทผู้แนบบันทึก Container Analysis ไปยังบัญชีบริการ 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 Build แล้วตรวจสอบบิลด์ล่าสุดและการดำเนินการตามขั้นตอนการสร้างที่สำเร็จ

8. นโยบายการควบคุมการรับส่ง

การให้สิทธิ์แบบไบนารีเป็นฟีเจอร์ใน 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"

นโยบายอนุญาตทั้งหมด

ก่อนอื่น ให้ยืนยันสถานะนโยบายเริ่มต้นและความสามารถในการติดตั้งใช้งานรูปภาพ

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. เปิดเทอร์มินัล ใช้กับนโยบายใหม่ และรอสักครู่เพื่อให้การเปลี่ยนแปลงมีผล

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 เพื่อกำหนดให้มีการรับรอง

กำหนดให้รูปภาพต้องลงนามโดย Attestor โดยการเพิ่ม 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

พยายามติดตั้งใช้งานรูปภาพที่ไม่ได้ลงนาม

สร้าง Deployment Descriptor สำหรับแอปพลิเคชันที่คุณสร้างไว้ก่อนหน้านี้โดยใช้คำสั่งต่อไปนี้ รูปภาพที่ใช้ที่นี่คือรูปภาพที่คุณสร้างไว้ก่อนหน้านี้ซึ่งมีช่องโหว่ร้ายแรงและไม่มีการรับรองที่ลงนาม

Admission Controller ของ 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

พยายามทำให้แอปใช้งานได้ใน GKE

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

ทำให้แอปใช้งานได้ใน GKE

kubectl apply -f deploy.yaml

ตรวจสอบภาระงานในคอนโซลและสังเกตการติดตั้งใช้งานอิมเมจที่สำเร็จ

10. ยินดีด้วย

ยินดีด้วย คุณทำ Codelab เสร็จแล้ว

สิ่งที่เราได้พูดถึงไปแล้ว

• วิธีเปิดใช้การสแกนอัตโนมัติ
• วิธีทำการสแกนตามคำขอ
• วิธีผสานรวมการสแกนในไปป์ไลน์บิลด์
• วิธีลงนามในรูปภาพที่อนุมัติ
• วิธีใช้ตัวควบคุมการยอมรับของ GKE เพื่อบล็อกอิมเมจ
• วิธีกำหนดค่า GKE เพื่ออนุญาตเฉพาะอิมเมจที่ลงนามและได้รับอนุมัติ

ขั้นตอนต่อไปที่ทำได้

• การรักษาความปลอดภัยในการทําให้อิมเมจใช้งานได้ใน Cloud Run และ Google Kubernetes Engine | เอกสารประกอบของ Cloud Build
• คู่มือเริ่มใช้งานฉบับย่อ: กำหนดค่านโยบายการให้สิทธิ์แบบไบนารีด้วย GKE | Google Cloud

ล้างข้อมูล

โปรดลบโปรเจ็กต์ที่มีทรัพยากรหรือเก็บโปรเจ็กต์ไว้และลบทรัพยากรแต่ละรายการเพื่อหลีกเลี่ยงการเรียกเก็บเงินจากบัญชี Google Cloud สำหรับทรัพยากรที่ใช้ในบทแนะนำนี้

การลบโปรเจ็กต์

วิธีที่ง่ายที่สุดในการยกเลิกการเรียกเก็บเงินคือการลบโปรเจ็กต์ที่คุณสร้างขึ้นสำหรับบทแนะนำ