ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด
กำหนดค่าบทบาท RBAC ของ Kubernetes บังคับใช้นโยบายเครือข่ายที่จำกัดทราฟฟิกระหว่างพ็อด และใช้มาตรฐานความปลอดภัยของพ็อดเพื่อจำกัดการยกระดับสิทธิ์
ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
ภาพรวมพื้นผิวการโจมตีของ Kubernetes
Kubernetesจัดการภาระงานที่ทำงานใน Container ได้ในระดับขนาดใหญ่ แต่ความซับซ้อนของระบบก็สร้างพื้นผิวการโจมตีที่กว้าง องค์ประกอบสำคัญที่ต้องรักษาความปลอดภัย ได้แก่ API Server (ระนาบควบคุมส่วนกลาง — หากถูกยึดครองจะสามารถควบคุมคลัสเตอร์ทั้งหมดได้), etcd (ฐานข้อมูลสถานะของคลัสเตอร์ — จัดเก็บความลับในรูปแบบ base64 จึงต้องเข้ารหัสขณะจัดเก็บ), kubelet (เอเจนต์ของโหนด — API ของ kubelet ที่ไม่ผ่านการยืนยันตัวตนเปิดให้เรียกใช้ Pod ใด ๆ ได้), รันไทม์ของ Container (Docker/containerd) และโครงข่ายที่เชื่อมต่อ Pod ทั้งหมดเข้าด้วยกัน ผู้เข้าสอบ Security+ ควรเข้าใจว่าการกำหนดค่า Kubernetes ที่ไม่ปลอดภัยเป็นหนึ่งในประเด็นที่พบได้บ่อยที่สุดจากการตรวจสอบความปลอดภัยบนคลาวด์
RBAC: การควบคุมการเข้าถึงตามบทบาทใน Kubernetes
Kubernetes RBAC (Role-Based Access Control)ควบคุมว่าผู้ใช้ บัญชีบริการ และกระบวนการใดสามารถดำเนินการใดกับทรัพยากร API ใดได้บ้าง โมเดลนี้มีออบเจ็กต์สี่ชนิด ได้แก่ Role (สิทธิ์ภายในเนมสเปซ), ClusterRole (สิทธิ์ทั่วทั้งคลัสเตอร์), RoleBinding (มอบ Role ให้หัวข้อใดหัวข้อหนึ่งภายในเนมสเปซ) และ ClusterRoleBinding (มอบ ClusterRole ให้หัวข้อใดหัวข้อหนึ่งทั่วทั้งคลัสเตอร์) ทุกคำสั่ง kubectl จะแปลงเป็นการเรียก API ซึ่งตรวจสอบกับกฎ RBAC หากไม่ได้กำหนดค่า RBAC ผู้ใช้ที่ผ่านการยืนยันตัวตนแล้ว (หรือบัญชีบริการ) อาจมีสิทธิ์ระดับผู้ดูแลระบบ
# Create a role allowing only pod reads in 'default' namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: ['']
resources: ['pods']
verbs: ['get', 'list', 'watch']บัญชีบริการและสิทธิ์เท่าที่จำเป็น
ทุก Pod ใน Kubernetes ทำงานภายใต้บัญชีบริการ ซึ่งเป็นข้อมูลระบุตัวตนที่ใช้สำหรับการยืนยันตัวตนกับ API โดยค่าเริ่มต้น Pod จะใช้บัญชีบริการ default ในเนมสเปซของตน ซึ่งอาจมีสิทธิ์กว้างเกินไป หลักการให้สิทธิ์เท่าที่จำเป็นกำหนดให้สร้างบัญชีบริการเฉพาะสำหรับแต่ละแอปพลิเคชัน โดยให้มีเพียงสิทธิ์ที่แอปพลิเคชันนั้นต้องใช้ นอกจากนี้ การตั้งค่า automountServiceAccountToken: false บน Pod ที่ไม่ต้องเข้าถึง API จะป้องกันไม่ให้โทเค็นบัญชีบริการถูกเมานต์เข้าไปในระบบไฟล์ของ Pod ซึ่งแอปพลิเคชันที่ถูกยึดครองอาจนำไปใช้เรียก API ได้
# Pod spec: disable service account token auto-mount
apiVersion: v1
kind: Pod
metadata:
name: myapp
spec:
serviceAccountName: myapp-sa
automountServiceAccountToken: false
containers:
- name: myapp
image: myapp:v1.0นโยบายเครือข่าย: ปฏิเสธทั้งหมดเป็นค่าเริ่มต้น
โดยค่าเริ่มต้นใน Kubernetes Pod ทั้งหมดสามารถสื่อสารกับ Pod อื่นทั้งหมดได้ในทุกเนมสเปซ Pod ที่ถูกยึดครองจึงอาจพยายามเข้าถึงฐานข้อมูล API ภายใน และไมโครเซอร์วิสอื่นได้ทันที ทรัพยากร Kubernetes NetworkPolicyใช้กำหนดกฎเพื่อจำกัดการรับส่งข้อมูลระหว่าง Pod โดยอ้างอิงจากป้ายกำกับ เนมสเปซ และพอร์ต แนวทางที่แนะนำคือใช้นโยบายเครือข่ายแบบปฏิเสธทั้งหมดเป็นค่าเริ่มต้นในแต่ละเนมสเปซ แล้วจึงเพิ่มกฎอนุญาตอย่างชัดเจนสำหรับเส้นทางการสื่อสารที่จำเป็น โปรดทราบว่า NetworkPolicy ต้องใช้ปลั๊กอิน CNIที่รองรับ (Calico, Cilium, Weave) — Kubernetes แบบพื้นฐานจะไม่ดำเนินการใด ๆ กับ NetworkPolicy หากไม่มี CNI ที่เข้ากันได้
# Default deny all ingress and egress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egressมาตรฐานความปลอดภัยของ Pod: มาแทนที่ PSP
Pod Security Standards (PSS) ซึ่งเปิดตัวใน Kubernetes 1.23 และมีเสถียรภาพใน 1.25 มาแทนที่ Pod Security Policy (PSP) ที่เลิกใช้งานแล้ว ด้วยโพรไฟล์ในตัวสามระดับที่บังคับใช้ในระดับเนมสเปซ ได้แก่ Privileged (ไม่จำกัด สำหรับองค์ประกอบระบบ), Baseline (ป้องกันการยกระดับสิทธิ์ที่ทราบกันดี เช่น Container ที่มีสิทธิ์สูงและการเข้าถึงเครือข่ายของโฮสต์) และ Restricted (เสริมความแข็งแกร่ง ต้องใช้ผู้ใช้ที่ไม่ใช่ root ตัดความสามารถทั้งหมดออก และบังคับให้ระบบไฟล์ root เป็นแบบอ่านอย่างเดียว) เนมสเปซจะติดป้ายกำกับเพื่อบังคับใช้ระดับนโยบาย และ Pod ที่ฝ่าฝืนนโยบายจะถูกปฏิเสธในขั้นตอนการรับเข้า
# Label namespace to enforce 'restricted' pod security
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restrictedการจัดการความลับใน Kubernetes
ความลับของ Kubernetesใช้จัดเก็บข้อมูลสำคัญ เช่น รหัสผ่าน โทเค็น และใบรับรอง TLS โดยค่าเริ่มต้น ความลับจะถูกจัดเก็บในetcd เป็นค่าแบบเข้ารหัสด้วย base64 — ไม่ใช่การเข้ารหัสเพื่อความปลอดภัย ผู้ที่อ่าน etcd ได้หรือมีสิทธิ์ RBAC เพียงพอสามารถถอดรหัสได้โดยง่าย แนวทางปฏิบัติที่ดี ได้แก่ การเปิดใช้การเข้ารหัสขณะจัดเก็บสำหรับ etcdโดยใช้ AES-GCM พร้อมคีย์ที่จัดเก็บใน KMS (AWS KMS, GCP KMS) การผสานกับตัวจัดการความลับภายนอก เช่น HashiCorp Vault หรือ AWS Secrets Manager ผ่าน Secrets Store CSI Driver และการจำกัดการเข้าถึงความลับผ่าน RBAC เพื่อให้เฉพาะบัญชีบริการที่จำเป็นต้องใช้เท่านั้นที่อ่านได้
# Enable etcd encryption at rest (encryption configuration)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: <base64-encoded-32-byte-key>ตัวควบคุมการรับเข้า: ด่านตรวจสอบความปลอดภัย
ตัวควบคุมการรับเข้าคือปลั๊กอินใน API server ของ Kubernetes ที่ดักคำขอ API หลังการยืนยันตัวตนและการอนุญาต แต่ก่อนบันทึกออบเจ็กต์ ทำให้สามารถตรวจสอบ เปลี่ยนแปลง หรือปฏิเสธคำขอได้ ตัวควบคุมการรับเข้าที่เกี่ยวข้องกับความปลอดภัย ได้แก่ PodSecurity (บังคับใช้มาตรฐานความปลอดภัยของ Pod), ImagePolicyWebhook (อนุญาตให้ตรวจสอบการลงลายเซ็นอิมเมจจากภายนอก), AlwaysPullImages (บังคับดึงอิมเมจใหม่เพื่อป้องกันการใช้อิมเมจอันตรายที่แคชไว้ในเครื่อง) และ OPA/Gatekeeper (Open Policy Agent — มีความยืดหยุ่นสูงสุด และอนุญาตให้กำหนดนโยบายแบบกำหนดเองด้วยภาษา Rego เพื่อบังคับใช้กฎความปลอดภัยขององค์กรได้ทุกประเภท)
การเสริมความแข็งแกร่งขององค์ประกอบคลัสเตอร์
การเสริมความแข็งแกร่งให้กับองค์ประกอบระนาบควบคุมของ Kubernetes มีความสำคัญอย่างยิ่ง: เซิร์ฟเวอร์ APIควรตั้งค่า --anonymous-auth=false เพื่อปิดการเข้าถึงที่ไม่ผ่านการยืนยันตัวตน ตั้งค่า --audit-log-path เพื่อบันทึกกิจกรรม API ทั้งหมด และใช้ TLS กับการเชื่อมต่อทุกประเภท kubeletควรตั้งค่า --authorization-mode=Webhook (ไม่ใช่ AlwaysAllow) และปิดการยืนยันตัวตนแบบไม่ระบุชื่อ ส่วนetcdควรใช้การเข้ารหัส TLS สำหรับการเชื่อมต่อระหว่างเพียร์และไคลเอ็นต์ จำกัดการเข้าถึงเครือข่าย (ให้เข้าถึงได้เฉพาะโดยเซิร์ฟเวอร์ API) และเข้ารหัสข้อมูลขณะจัดเก็บ CIS Kubernetes Benchmark มีรายการตรวจสอบที่ครอบคลุมการตั้งค่าขององค์ประกอบทั้งหมด
# Check kubelet configuration for security issues
kubectl get --raw /api/v1/nodes/nodename/proxy/configz | jq '.kubeletconfig | {anonymousAuth: .authentication.anonymous.enabled, authorization: .authorization.mode}'การแยกเนมสเปซและการใช้งานหลายผู้เช่า
เนมสเปซของ Kubernetes ช่วยแยกทรัพยากรออกจากกันในเชิงตรรกะ แต่ไม่ใช่ขอบเขตความปลอดภัยที่แข็งแกร่งด้วยตัวมันเอง — โดยหลักแล้วให้เพียงการแยกเพื่อการจัดระเบียบ สำหรับการแยกผู้เช่าหลายรายอย่างแท้จริง (เช่น ภาระงานของลูกค้าต่างรายกัน) จำเป็นต้องมีการควบคุมเพิ่มเติม ได้แก่ นโยบายเครือข่ายเพื่อบล็อกการรับส่งข้อมูลข้ามเนมสเปซ โควตาทรัพยากรเพื่อป้องกัน DoS จากผู้เช่ารายใดรายหนึ่งที่ใช้ทรัพยากรมากเกินไป กลุ่มโหนดแยกต่างหากสำหรับผู้เช่าที่ต้องการการแยกอย่างเข้มงวด หรือคลัสเตอร์เฉพาะสำหรับผู้เช่าแต่ละราย หลายองค์กรใช้ Hierarchical Namespaces หรือโซลูชันเชิงพาณิชย์อย่าง vCluster เพื่อเพิ่มความแข็งแกร่งของการใช้งานหลายผู้เช่าภายในคลัสเตอร์เดียว
การบันทึกการตรวจสอบและการเฝ้าติดตามขณะทำงาน
Kubernetes การบันทึกการตรวจสอบ จะบันทึกคำขอ API ทุกคำขอ ได้แก่ ใครเป็นผู้ส่งคำขอ ส่งจากที่ใด ขอให้ดำเนินการอะไร และมุ่งเป้าไปที่ Resource ใด บันทึกการตรวจสอบมีความสำคัญอย่างยิ่งต่อการสืบสวนทางนิติวิทยาศาสตร์หลังเกิดเหตุการณ์ด้านความปลอดภัย และช่วยตรวจจับพฤติกรรมผิดปกติ เช่น การผูกบทบาทที่ไม่ปกติ การเข้าถึงข้อมูลลับ หรือคำสั่ง exec เข้าไปยังพ็อดในสภาพแวดล้อมจริง ควรสตรีมบันทึกการตรวจสอบไปยัง SIEM แบบรวมศูนย์ Falco ให้การเฝ้าติดตามพฤติกรรมของคอนเทนเนอร์ขณะทำงาน ขณะที่บริการ Kubernetes ที่ผู้ให้บริการคลาวด์จัดการ (EKS, GKE, AKS) มีการผสานรวมบันทึกการตรวจสอบแบบเนทีฟเข้ากับแพลตฟอร์มการบันทึกที่เกี่ยวข้อง
# Check recent kubectl exec events in audit log
grep '"verb":"create".*"resource":"pods".*"subresource":"exec"' /var/log/kubernetes/audit.log | tail -20ความปลอดภัยของห่วงโซ่อุปทาน: แหล่งที่มาของอิมเมจ
ความปลอดภัยของห่วงโซ่อุปทาน สำหรับ Kubernetes ช่วยให้มั่นใจได้ว่าจะมีเพียงอิมเมจที่เชื่อถือได้และผ่านการตรวจสอบแล้วเท่านั้นที่ไปถึงสภาพแวดล้อมจริง คำแนะนำด้าน ความปลอดภัยของห่วงโซ่อุปทาน ของ CNCF ประกอบด้วย การตรวจสอบลายเซ็นอิมเมจด้วย Cosign ก่อนการนำไปใช้งาน (บังคับใช้ผ่านตัวควบคุมการอนุญาตให้ใช้งาน) การสร้างและตรวจสอบ รายการส่วนประกอบซอฟต์แวร์ (SBOM) สำหรับอิมเมจคอนเทนเนอร์ทั้งหมดเพื่อใช้ติดตามแหล่งที่มาของส่วนประกอบ การตรึงอิมเมจไว้กับ ไดเจสต์ (myimage@sha256:abc123) แทนแท็กที่เปลี่ยนแปลงได้ และการสแกนแผนภูมิ Helm จากบุคคลที่สามทั้งหมดเพื่อหาการกำหนดค่าผิดพลาดและช่องโหว่ก่อนนำไปใช้งาน
# Pin image to digest for immutability
# Instead of:
image: nginx:latest
# Use:
image: nginx@sha256:a3e2a7a3d7f94e... # immutable digestตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า Kubernetes RBAC ควบคุมการเข้าถึง API ผ่าน Roles, ClusterRoles และ Bindings — ควรใช้สิทธิ์เท่าที่จำเป็นน้อยที่สุดกับบัญชีบริการเสมอ การกำหนดค่า NetworkPolicy แบบปฏิเสธเป็นค่าเริ่มต้นจะป้องกันการเคลื่อนที่ด้านข้างระหว่างพ็อดและเนมสเปซ และ มาตรฐานความปลอดภัยของพ็อดจะบังคับใช้การทำให้คอนเทนเนอร์แข็งแกร่งขึ้น ในระดับเนมสเปซ โดยบล็อกคอนเทนเนอร์ที่มีสิทธิ์สูง การเข้าถึงเครือข่ายของโฮสต์ และการทำงานด้วยสิทธิ์ผู้ใช้ราก บทถัดไปเราจะสำรวจความปลอดภัยแบบไร้เซิร์ฟเวอร์และพื้นผิวการโจมตีระดับฟังก์ชัน
เรียนรู้ Cloud & IT Cert Prep ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 150
- บทเรียน
- 600
คำถามที่พบบ่อย
บทเรียน “ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด”
กำหนดค่าบทบาท RBAC ของ Kubernetes บังคับใช้นโยบายเครือข่ายที่จำกัดทราฟฟิกระหว่างพ็อด และใช้มาตรฐานความปลอดภัยของพ็อดเพื่อจำกัดการยกระดับสิทธิ์ คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน
- ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด
- ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน
- การสแกนความปลอดภัยโครงสร้างพื้นฐานในรูปโค้ด