การลงลายมือชื่ออิมเมจ SBOM และ provenance

เมื่ออิมเมจผ่านเกต Build Security แล้ว Loha จะลงลายมือชื่ออิมเมจนั้นด้วยคีย์ของเวิร์กสเปซคุณเอง และแนบการรับรอง (attestation) สองรายการไว้คู่กับอิมเมจในรีจิสทรีของคุณ:

• SLSA provenance (v1) — บิลด์จากรีโพสิทอรีและคอมมิตใด โดย builder ใดของ Loha และภายใต้การตัดสินของเกตความปลอดภัยครั้งใด Loha ตั้งเป้า SLSA Build Level 2: บิลด์รันบนแพลตฟอร์มที่โฮสต์ และแพลตฟอร์มเป็นผู้ลงลายมือชื่อ provenance
• SBOM (CycloneDX) — รายการแพ็กเกจในอิมเมจ จากการสแกนแบบ managed เดียวกับที่ตรวจช่องโหว่

ลายมือชื่อและการรับรองเก็บเป็นอาร์ติแฟกต์ .sig / .att มาตรฐานของ cosign ในรีจิสทรีของคุณ คุณจึงตรวจสอบได้โดยไม่ต้องพึ่ง Loha

อิมเมจใดบ้างที่ถูกลงลายมือชื่อ

Loha ลงลายมือชื่ออิมเมจเมื่อเงื่อนไขต่อไปนี้เป็นจริงทั้งหมด:

• บิลด์สำเร็จและพุชอิมเมจไปยังรีจิสทรีแล้ว

• นโยบายความปลอดภัยของเวิร์กสเปซอยู่ในโหมด Enforce หรือ Observe และอิมเมจผ่านนโยบาย:

  • Enforce: ผลของเกตสุดท้ายของบิลด์คือ ผ่าน
  • Observe: เกตไม่รอผลการสแกน อิมเมจจึงแสดงเป็น รอผลการสแกน ก่อน เมื่อการสแกนเสร็จ Loha จะตรวจผลการสแกนกับนโยบายที่ใช้อยู่ตอนบิลด์ ด้วยกฎหลักฐานเดียวกับ Enforce (นับเฉพาะการสแกนที่ Loha รันเอง) หากผ่าน อิมเมจจะถูกลงลายมือชื่อและแสดงเป็น ลงลายมือชื่อในโหมด Observe

  อิมเมจที่นโยบายบล็อกจะ ไม่ถูก ลงลายมือชื่อเลยไม่ว่าจะเป็นโหมดใด

• รีจิสทรีของอิมเมจเป็นรีจิสทรีที่ Loha รองรับการสแกนแบบ managed และเวิร์กสเปซมีข้อมูลรับรองของรีจิสทรีนั้น (ตั้งค่า → รีจิสทรี) Loha ใช้สิทธิ์พุชของข้อมูลรับรองนั้นในการลงลายมือชื่อ

ลายมือชื่อในโหมด Observe หมายถึงอะไร

ลายมือชื่อในโหมด Observe ยืนยันสิ่งเดียวกับในโหมด Enforce: อิมเมจผ่านเกณฑ์ของนโยบายจากการสแกนที่ Loha รันเอง ต่างกันที่จังหวะเวลา ในโหมด Observe บิลด์ไม่ได้ถูกรอระหว่างสแกน ปลายทางที่ดึงอิมเมจด้วย tag จึงอาจรันอิมเมจก่อนที่จะถูกลงลายมือชื่อ provenance บันทึกโหมดไว้ที่ internalParameters.securityGate.policyMode

แท็บ Security ของบิลด์จะแสดงแต่ละอิมเมจเป็น ลงลายมือชื่อแล้ว, รอลงลายมือชื่อ, รอผลการสแกน (Observe), ลงลายมือชื่อไม่สำเร็จ หรือ ไม่ได้ลงลายมือชื่อ พร้อมเหตุผล

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

ตรวจสอบอิมเมจ

ดาวน์โหลดพับลิกคีย์ของเวิร์กสเปซจาก ตั้งค่า → Code security → คีย์ลงลายมือชื่อ (หรือจากแถวของอิมเมจในแท็บ Security ของบิลด์) แล้วรัน:

cosign verify --key loha.pub --insecure-ignore-tlog=true registry.example.com/team/app@sha256:<digest>
cosign verify-attestation --key loha.pub --insecure-ignore-tlog=true --type slsaprovenance1 registry.example.com/team/app@sha256:<digest>
cosign verify-attestation --key loha.pub --insecure-ignore-tlog=true --type cyclonedx registry.example.com/team/app@sha256:<digest>

ใช้ cosign v2 ต้องใส่ --insecure-ignore-tlog=true เพราะ Loha ไม่เผยแพร่ digest ของอิมเมจคุณไปยัง transparency log สาธารณะ ลายมือชื่อยังคงถูกตรวจกับคีย์ของเวิร์กสเปซคุณตามปกติ

หากใช้ Loha CLI คำสั่ง loha images verify registry.example.com/team/app@sha256:<digest> จะดึงคีย์และรันสองคำสั่งแรกให้ คือตรวจ ลายมือชื่อ และ SLSA provenance CLI ไม่ได้ตรวจการรับรอง SBOM หากต้องการตรวจ ให้รันคำสั่งที่สามเอง หากอิมเมจถูกลงลายมือชื่อด้วยคีย์ที่ถูกเพิกถอนแล้ว คำสั่งจะล้มเหลว ใส่ --allow-revoked หากต้องการยอมรับ (เช่น เพื่อตรวจอิมเมจเก่า)

คีย์ลงลายมือชื่อ

แต่ละเวิร์กสเปซมีคีย์ ECDSA P-256 ที่ใช้งานอยู่หนึ่งคีย์ Loha เก็บไพรเวตคีย์แบบเข้ารหัสและใช้เฉพาะภายในงานลงลายมือชื่อ ไม่มีการแสดงหรือให้ดาวน์โหลด ผู้ดูแลสามารถ หมุนคีย์ ได้ (ต้องยืนยันตัวตนเพิ่ม): อิมเมจใหม่ใช้คีย์ใหม่ และอิมเมจที่ลงลายมือชื่อด้วยคีย์เดิมยังตรวจสอบได้ด้วยพับลิกคีย์เดิมซึ่งยังแสดงอยู่ในรายการ

เมื่อเปิดใช้นโยบาย admission ในเวิร์กสเปซ การหมุนคีย์จะเตรียมคีย์ใหม่ไว้ก่อน คีย์ใหม่เข้าสู่นโยบาย admission ทันทีและเริ่มลงลายมือชื่อหลัง 7 วัน หรือเมื่อแอดมินเปิดใช้ ดูการหมุนคีย์

หากสงสัยว่าคีย์รั่วไหล ให้หมุนคีย์และเลือก เพิกถอน อิมเมจที่ลงลายมือชื่อด้วยคีย์ที่ถูกเพิกถอนจะถูกทำเครื่องหมายในแท็บ Security Loha เก็บลายมือชื่อหนึ่งชุดต่อหนึ่ง digest ของอิมเมจ อิมเมจที่ลงลายมือชื่อด้วยคีย์ที่ถูกเพิกถอนจึงยังคงมีลายมือชื่อจากคีย์นั้นอยู่ หากต้องการลายมือชื่อจากคีย์ใหม่ ต้องมี บิลด์ใหม่ที่ได้ digest ของอิมเมจใหม่ Loha ไม่ลงลายมือชื่อซ้ำให้กับ digest เดิม

กำหนดให้ต้องมีลายมือชื่อก่อน deploy

เปิด ต้องมีลายมือชื่อของ Loha ก่อน Delivery ในนโยบายความปลอดภัย (imageAttestations.required) ตัวเลือกนี้จะถูกปฏิเสธหากนโยบายเป็น Off

ในโหมด Observe หาก dispatch ถึงอิมเมจที่ยัง รอผลการสแกน การ dispatch จะ รอ จนกว่าอิมเมจจะถูกลงลายมือชื่อ หรือจนกว่า Loha จะตัดสินใจไม่ลงลายมือชื่อ (นโยบายบล็อกอิมเมจ หรือไม่สามารถเชื่อถือผลสแกนได้)

Delivery จะปฏิเสธการ dispatch release ที่อิมเมจยังไม่ได้ลงลายมือชื่อ ลงลายมือชื่อไม่สำเร็จหรือถูกข้าม หรือลงลายมือชื่อด้วยคีย์ที่ถูกเพิกถอน ข้อนี้ใช้กับการ dispatch ทุกครั้ง รวมถึงการ rollback ไปยัง release ก่อนหน้า: rollback ไปยัง release ที่อิมเมจไม่มีลายมือชื่อจะถูกปฏิเสธเช่นกัน

คุณยังเตรียมและอนุมัติแผน (plan) ได้ระหว่างที่อิมเมจกำลังถูกลงลายมือชื่อ หาก rollout ถึงขั้น dispatch ก่อนที่การลงลายมือชื่อจะเสร็จ การ dispatch จะ รอ: rollout จะถูกเลื่อนและลองใหม่จนกว่าอิมเมจจะถูกลงลายมือชื่อ (หรือการลงลายมือชื่อล้มเหลว) การรอจะสิ้นสุดเมื่อแผนหมดอายุ (หรือประมาณสองชั่วโมงสำหรับแผนที่ไม่มีวันหมดอายุ) หลังจากนั้น rollout จะล้มเหลวและต้องเตรียมแผนใหม่ rollout ที่กำลังดำเนินอยู่แล้วจะไม่ได้รับผลกระทบ การปิดตัวเลือกนี้ภายหลังถือเป็นการผ่อนคลายนโยบาย และต้องมีผู้ดูแลคนที่สองเช่นเดียวกับการผ่อนคลายนโยบายอื่น

สิ่งที่ฟีเจอร์นี้ไม่ได้ทำ

• Loha ไม่ได้ห้ามคลัสเตอร์รันอิมเมจที่ไม่มีลายมือชื่อด้วยตัวเอง เมื่อใช้นโยบาย admission ที่ Loha สร้างให้ admission controller ของคุณจะปฏิเสธอิมเมจจากรีโพสิทอรีที่ Loha บิลด์ซึ่ง Loha ไม่ได้ลงลายมือชื่อ
• อิมเมจที่ไปป์ไลน์พุชไปยังรีจิสทรีที่ Loha ไม่ได้สแกนแบบ managed หรือไม่มีข้อมูลรับรองใน Loha จะไม่ถูกลงลายมือชื่อ
• SBOM ที่ใหญ่กว่า 20 MiB จะไม่ถูกเก็บหรือแนบ แต่ยังคงลงลายมือชื่ออิมเมจพร้อม provenance
• การดาวน์โหลด SBOM เป็นไปตามระยะเก็บรายงานความปลอดภัย (30 วัน) ส่วนการรับรองในรีจิสทรีของคุณไม่หมดอายุ