Kustomize Overlay Shift Left Security | SiamCafe Blog

Kustomize Overlay กับ Shift Left Security คืออะไร ทำไมทีม DevOps ปี 2026 ต้องรู้จัก

ถ้าให้ผมอ.บอมอธิบายแบบสั้นที่สุด Kustomize Overlay คือเครื่องมือจัดการคอนฟิกูเรชันของ Kubernetes ที่ช่วยให้เราเขียนไฟล์แมนิเฟสต์ชุดหนึ่ง

แล้วนำไปปรับใช้กับหลายสภาพแวดล้อมได้โดยไม่ต้องคัดลอกไฟล์ซ้ำ ส่วน Shift Left Security คือแนวคิดการย้ายงานด้านความปลอดภัยให้เริ่มตั้งแต่ขั้นตอนแรก ๆ ของการพัฒนา ไม่ใช่รอไปตรวจตอนท้ายก่อนส่งมอบเหมือนเมื่อสิบปีก่อน เมื่อเอาสองอย่างนี้มารวมกัน เราจะได้กระบวนการที่ทุกครั้งที่เราสร้างโอเวอร์เลย์สำหรับแต่ละสภาพแวดล้อม มีการตรวจสอบความปลอดภัยฝังอยู่ในไปป์ไลน์อัตโนมัติตั้งแต่ต้น

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

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

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

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

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

โครงสร้างโฟลเดอร์ที่ใช้งานได้จริงและทีมใหม่เข้าใจได้ภายในครึ่งวันเป็นแบบนี้

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

manifests/ ├── base/ │ ├── deployment.yaml │ ├── service.yaml │ ├── hpa.yaml │ └── kustomization.yaml ├── overlays/ │ ├── dev/ │ │ └── kustomization.yaml │ ├── staging/ │ │ └── kustomization.yaml │ └── production/ │ ├── kustomization.yaml │ ├── security-policy.yaml │ └── network-policy.yaml

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

apiVersion: apps/v1 kind: Deployment metadata: name: siamcafe-api spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers:

• name: app

image: registry.internal/siamcafe-api ports:

• containerPort: 8080

resources: requests: cpu: "250m" memory: "256Mi" limits: cpu: "1000m" memory: "1Gi" livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5

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

apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: production patches:

• path: security-policy.yaml
• path: network-policy.yaml

images:

• name: registry.internal/siamcafe-api

newTag: v2026.1.0 replicas:

• name: siamcafe-api

count: 5

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

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

ติดตั้งและตั้งค่าไปป์ไลน์ที่ตรวจความปลอดภัยอัตโนมัติ

มาถึงขั้นตอนลงมือทำจริง ผมจะเดินตามลำดับที่ใช้กับระบบของผมเองเลย เริ่มจากเตรียมเครื่องมือพื้นฐานบนเซิร์ฟเวอร์ลินุกซ์

#!/bin/bash set -euo pipefail

sudo apt-get update && sudo apt-get install -y \ curl wget git jq apt-transport-https \ ca-certificates software-properties-common gnupg

if ! command -v docker &> /dev/null; then curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER fi

curl -LO "https://dl.k8s.io/release/$(curl -sL \ https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

curl -s "https://raw.githubusercontent.com/kubernetes-sigs/\ kustomize/master/hack/install_kustomize.sh" | bash sudo install kustomize /usr/local/bin/kustomize

curl -s https://raw.githubusercontent.com/\ kyverno/kyverno/main/scripts/install.sh | bash

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

mkdir -p ~/projects/siamcafe-app/{manifests,scripts,tests} cd ~/projects/siamcafe-app

cat > Makefile <<'MAKEFILE' .PHONY: build scan diff deploy rollback status

build: kustomize build manifests/overlays/production/ > /tmp/rendered.yaml

scan: build kyverno apply policies/ --resource /tmp/rendered.yaml --detailed-results

diff: kubectl diff -k manifests/overlays/production/

deploy: scan kubectl apply -k manifests/overlays/production/ kubectl rollout status deployment/siamcafe-api \ -n production --timeout=300s

rollback: kubectl rollout undo deployment/siamcafe-api -n production

status: kubectl get pods -l app=siamcafe-api -n production -o wide MAKEFILE

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

ต่อไปคือผูกเข้ากับระบบรวมอัตโนมัติ ในกิตฮับแอ็กชันเราเพิ่มขั้นตอนง่าย ๆ

name: security-gate on: [pull_request] jobs: scan: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v4
• name: Render overlay

run: kustomize build manifests/overlays/production/ > rendered.yaml

• name: Policy check

run: kubectl kyverno apply policies/ --resource rendered.yaml

• name: Image vulnerability scan

run: trivy image registry.internal/siamcafe-api:${{ github.sha }}

นโยบายชุดแรกที่ผมแนะนำให้ทุกทีมเริ่มใช้มีห้าข้อ ห้ามรันในฐานะรูท ห้ามภาพที่ไม่มีการลงนามดิจิทัล บังคับข้อจำกัดทรัพยากรทุกคอนเทนเนอร์ ห้ามยกเลิกความสามารถป้องกันขั้นต่ำ และบังคับให้ทุกแอปพลิเคชันมีนโยบายเครือข่าย ห้าข้อนี้กันปัญหาได้เกือบแปดสิบเปอร์เซ็นต์ของช่องโหว่ทั่วไป สำหรับรายละเอียดเชิงลึกเพิ่มเติม สามารถศึกษาได้ที่ xmsignal.com/th ซึ่งผมสรุปเนื้อหาด้านระบบอัตโนมัติและการเงินไว้ต่อเนื่อง

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

ชั้นโครงสร้างพื้นฐาน ชั้นแอปพลิเคชัน และชั้นนโยบายความปลอดภัย

การตรวจจับและติดตามที่ทำงานร่วมกับ Overlay

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

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

ระดับ	สิ่งที่ต้องเก็บ	เครื่องมือ	ความถี่
โครงสร้างพื้นฐาน	ซีพียู หน่วยความจำ ดิสก์	โพรมีทีอุส กราฟานา	ทุก 15 วินาที
แอปพลิเคชัน	เวลาตอบสนอง อัตราผิดพลาด	โอเพนเทเลเมทรี	ต่อคำขอ
นโยบาย	จำนวนครั้งที่ถูกปฏิเสธ กฎที่โดนบ่อย	ตัวนับนโยบาย	ทุก 1 นาที
ความปลอดภัย	ลายเซ็นโค้ดร้าย การสแกนภาพ	ทรีวี ฟัลโค	ต่อภาพใหม่

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

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

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

คำถามที่พบบ่อย

Kustomize Overlay คืออะไร และต่างจากการคัดลอกไฟล์แมนิเฟสต์แยกแต่ละสภาพแวดล้อมอย่างไร?

Kustomize Overlay คือเครื่องมือจัดการคอนฟิกูเรชันของ Kubernetes ที่ช่วยให้เราเขียนไฟล์แมนิเฟสต์ชุดหนึ่ง แล้วนำไปปรับใช้กับหลายสภาพแวดล้อมได้โดยไม่ต้องคัดลอกไฟล์ซ้ำ หลักการทำงานเริ่มจากโฟลเดอร์ชื่อเบสที่เก็บไฟล์แมนิเฟสต์มาตรฐาน เช่น การปรับใช้งาน บริการ และการขยายอัตโนมัติ จากนั้นสร้างโฟลเดอร์โอเวอร์เลย์สำหรับแต่ละสภาพแวดล้อม เช่น ทดสอบ พรีโปรดักชัน และโปรดักชัน โดยในโอเวอร์เลย์เราระบุเฉพาะสิ่งที่ต้องแก้ไข เช่น เปลี่ยนชื่อภาพคอนเทนเนอร์ ปรับจำนวนจำลอง เพิ่มป้ายกำกับ หรือแทนที่ค่าคอนฟิกูเรชัน เครื่องมือจะนำผลต่างไปทับเบสแบบประกาศศักดิ์สิทธิ์ ทำให้ไม่ต้องใช้เทมเพลตที่ซับซ้อน และอ่านไฟล์เสร็จก็รู้ทันทีว่าผลลัพธ์สุดท้ายเป็นอย่างไร ซึ่งแตกต่างจากการคัดลอกไฟล์ที่ทำให้เกิดการคลาดเคลื่อนของคอนฟิกูเรชันเมื่อต้องแก้ไขหลายจุดพร้อมกัน

Shift Left Security คืออะไร และทำไมทีม DevOps ในปี 2026 ถึงต้องให้ความสำคัญ?

Shift Left Security คือแนวคิดการย้ายงานด้านความปลอดภัยให้เริ่มตั้งแต่ขั้นตอนแรก ๆ ของการพัฒนา ไม่ใช่รอไปตรวจตอนท้ายก่อนส่งมอบเหมือนเมื่อสิบปีก่อน ความสำคัญในปี 2026 เกิดจากระบบปัจจุบันรันบนคลัสเตอร์ที่มีทรัพยากรหลายร้อยรายการ ถ้ารอให้ทีมความปลอดภัยมาตรวจสอบก่อนขึ้นใช้งานจริงทีละรายการ งานจะติดค้างเป็นคิวยาวมาก แล้วคนในทีมจะเริ่มหาทางลัด เช่น ปิดช่องแก้เลขกำหนดสิทธิ์เพื่อให้ทำงานได้ก่อน ซึ่งนั่นคือจุดเริ่มต้นของเหตุข้อมูลรั่วไหลเกือบทุกกรณี เมื่อผสานกับ Kustomize Overlay ทุกครั้งที่สร้างโอเวอร์เลย์สำหรับแต่ละสภาพแวดล้อมจะมีการตรวจสอบความปลอดภัยฝังอยู่ในไปป์ไลน์อัตโนมัติตั้งแต่ต้น เพราะยิ่งระบบเร็วขึ้น ความผิดพลาดของมนุษย์ยิ่งแพร่กระจายเร็วขึ้นด้วย

จะผสานการตรวจสอบความปลอดภัยเข้าไปใน Kustomize Overlay ได้อย่างไร?

จุดที่ Shift Left Security เข้ามาเสริมคือเราเพิ่มขั้นตอนตรวจสอบเข้าไปในโอเวอร์เลย์โดยตรง เช่น บังคับให้ทุกคอนเทนเนอร์รันโดยไม่ใช้สิทธิ์รูทผ่าน securityContext ที่กำหนด runAsNonRoot เป็น true บังคับให้มีข้อจำกัดการใช้ทรัพยากรทุกคอนเทนเนอร์ ห้ามดึงภาพจากรีจิสทรีภายนอกโดยไม่ผ่านการสแกน และตรวจว่านโยบายเครือข่ายถูกกำหนดครบถ้วน ในทางปฏิบัติเราสร้างไฟล์อย่าง security-policy.yaml และ network-policy.yaml ไว้ในโฟลเดอร์โอเวอร์เลย์ของโปรดักชัน จากนั้นเครื่องมืออย่างโพลิซีเอเจนต์หรือคิวเวอร์เนเตสที่รันในไปป์ไลน์จะประเมินผลลัพธ์ของคำสั่งสร้างโอเวอร์เลย์ก่อนที่มันจะถูกส่งไปคลัสเตอร์จริง ถ้าไม่ผ่านนโยบาย งานจะหยุดตรงนั้นทันที นั่นคือการย้ายความปลอดภัยไปอยู่ซ้ายสุดของไทม์ไลน์อย่างแท้จริง

การใช้ Kustomize Overlay ร่วมกับ Shift Left Security ให้ประโยชน์อะไรกลับมาบ้าง?

ประโยชน์

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6