ทำไม kubectl ใช้งานได้ผ่าน VPN แต่ AKS หยุดสเกล

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

รายการที่อนุญาตจับคู่กับที่อยู่ ไม่ใช่บุคคล

--api-server-authorized-ip-ranges รับบล็อก CIDR ไม่ใช่ผู้ใช้หรือกลุ่ม เมื่อคำขอของนักพัฒนาออกจากเซิร์ฟเวอร์ VPN ไปยัง Azure ที่อยู่ต้นทางที่เซิร์ฟเวอร์ API คือทางออกสาธารณะของเซิร์ฟเวอร์ VPN ดังนั้นทุกคนบน VPN นั้นจึงใช้รายการเดียวร่วมกัน และใครก็ตามที่อยู่นอก VPN จะถูกปฏิเสธก่อนที่การรับรองความถูกต้องจะเกิดขึ้นเสียอีก

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

สิ่งที่พังก่อนมักไม่ใช่ kubectl

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

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

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

สร้างรายการทั้งหมดด้วยคำสั่งเดียว

พารามิเตอร์อัปเดตแทนที่รายการทั้งหมดแทนการเพิ่มรายการ ดังนั้นคำสั่งที่พกเฉพาะที่อยู่ VPN จะทิ้งทุกอย่างที่มีอยู่ก่อนหน้าอย่างเงียบ ๆ อ่านค่าปัจจุบันก่อน เก็บไว้ แล้วส่งยูเนียน:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

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

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

สิ่งที่รายการที่อนุญาตไม่เคยครอบคลุม

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

มันไม่เกี่ยวกับเวิร์กโหลดเลย Pods และ Services ยังทำงานต่อไปเมื่อเปิดรายการ และ การเข้าถึงแอปพลิเคชันผ่าน VPN เป็นปัญหาอีกเรื่องหนึ่ง: Service ที่มีเพียง IP ของคลัสเตอร์ยังต้องมีตัวกระจายโหลดภายใน, ingress หรือ port-forward ก่อนที่แล็ปท็อปจะเปิดได้ การผสมสองดีไซน์นี้ทำให้เกิดตั๋วเปลี่ยนแปลงที่อ้างว่าจำกัดนักพัฒนาและจริง ๆ แล้วไม่ได้จำกัดอะไรเกี่ยวกับแอปพลิเคชัน

ตรวจสอบทั้งสองด้าน แล้วรันการดำเนินการจริงหนึ่งครั้ง

ทดสอบด้วยไคลเอนต์ใหม่บน VPN และไคลเอนต์นอกรายการ ความพยายามจากภายนอกควรถูกปฏิเสธที่เซิร์ฟเวอร์ API ไม่ใช่ที่การแปลงชื่อ; หากชื่อไม่ถูกแปลง คุณกำลังทดสอบ DNS และไม่ได้เรียนรู้อะไรเกี่ยวกับตัวกรอง จากนั้นรันการดำเนินการที่ไม่ใช่การเรียก kubectl แบบโต้ตอบ เช่น การสเกล node pool หรือการตรวจสอบการอัปเกรด และยืนยันว่ามันเสร็จสิ้นแทนที่จะสันนิษฐานว่าจะเสร็จ

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