ตัวตรวจสอบ Kubernetes Manifest

โดยปกติ Kubernetes manifest จะถูกตรวจสอบด้วยสายตาใน pull request ซึ่งหมายความว่าข้อผิดพลาดด้านความปลอดภัยเดิมๆ มักจะหลุดไปถึง production: Deployment ที่ไม่มีการจำกัดหน่วยความจำ สุดท้ายถูก OOM-kill และดึงโหนดลงไปด้วย, คอนเทนเนอร์ที่รันอย่างสบายใจในฐานะ root เพราะไม่มีใครตั้งค่า runAsNonRoot, หรือ Pod ที่ผูกกับ image tag อย่าง `:latest` ซึ่งเปลี่ยนแปลงเงียบๆ ภายใต้การ rollout เครื่องมือ linter นี้จะตรวจจับปัญหาประเภทนั้นทันทีที่คุณวาง manifest ลงไป โดยไม่ต้องมีคลัสเตอร์ที่รันอยู่, บริบท kubectl หรือ credential ใดๆ ทั้งสิ้น

ภายใต้ฮู้ดมีตัวแยกวิเคราะห์ YAML ขนาดเล็กที่เขียนขึ้นเอง โดยเขียนมาเฉพาะสำหรับเซตย่อยของ YAML ที่สมจริงซึ่ง Kubernetes manifest ใช้งานจริง: เอกสารที่คั่นด้วย `---`, การซ้อนตามการเยื้อง, `key: value` และ nested block mappings, รายการแบบ `- ` รวมถึงลิสต์ของ map, สเกลาร์แบบมีและไม่มีเครื่องหมายคำพูด, ความคิดเห็น, และ block scalars แบบ `|`/`>` สำหรับสิ่งต่างๆ เช่นค่า ConfigMap แบบหลายบรรทัดหรือ annotation ไม่มีไลบรารี YAML ภายนอกมาเกี่ยวข้อง — ทั้งตัวแยกวิเคราะห์และเอนจินกฎรวมอยู่กับเครื่องมือและทำงานทั้งหมดภายในเบราว์เซอร์ของคุณ

ตารางกฎอิงตามคำแนะนำด้านความมั่นคงปลอดภัยของคลัสเตอร์ที่เป็นที่รู้จัก — CIS Kubernetes Benchmark, kube-score, และโปรไฟล์ "Restricted" ของ Pod Security Standards — และตรวจสอบแต่ละคอนเทนเนอร์ว่ามี resource requests/limits ที่หายไป, คอนเทนเนอร์ที่สามารถรันในฐานะ root หรือในโหมด privileged, liveness และ readiness probes ที่หายไปใน workload แบบ long-running (Deployment, StatefulSet, DaemonSet), hostPath volume mounts ที่เปิดเผยระบบไฟล์ของโฮสต์, การใช้งาน hostNetwork, และคอนเทนเนอร์อิมเมจที่ไม่สามารถทำซ้ำได้อย่าง `:latest` หรือไม่มีแท็ก ผลลัพธ์ที่พบจะถูกจัดกลุ่มตามเอกสารและคอนเทนเนอร์ โดยระบุระดับความรุนแรง error/warning ในแต่ละรายการ เพื่อให้คุณแยกแยะได้ว่าอะไรที่เสี่ยงจริง กับอะไรที่เป็นเพียงคำแนะนำแนวปฏิบัติที่ดี

ทำงานได้กับ manifest เดี่ยวหรือไฟล์เอกสารหลายชุดที่วางมาจากผลลัพธ์ Helm template render หรือ `kustomize build` โดยเข้าใจทรัพยากร Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet และ CronJob เนื่องจากทุกอย่างรันแบบโลคอล จึงปลอดภัยที่จะวาง manifest ที่มีชื่อเซอร์วิสภายใน, การกำหนดขนาดทรัพยากรจริง หรืออะไรก็ตามที่คุณไม่ต้องการส่งไปยัง API ของบุคคลที่สาม — มีประโยชน์สำหรับการตรวจสอบความถูกต้องอย่างรวดเร็วก่อน commit, เป็นตัวช่วยในการตรวจสอบโค้ด, หรือเรียนรู้ว่า "hardened" จริงๆ แล้วหน้าตาเป็นอย่างไรในทางปฏิบัติ