จัดการตัวตนผู้ใช้ข้ามแพลตฟอร์ม Kubernetes และ AI แบบรวมศูนย์

จัดการตัวตนผู้ใช้ข้ามแพลตฟอร์ม Kubernetes และ AI แบบรวมศูนย์ในยุคที่แพลตฟอร์ม AI ไม่ได้จำกัดอยู่แค่แอปพลิเคชันเดียวที่มีหน้าจอเข้าสู่ระบบเพียงหน้าจอเดียว ผู้ใช้อาจเริ่มต้นจากพอร์ทัลกลาง เข้าถึงชุดข้อมูลที่ควบคุม หรือเปิดใช้งาน Notebook เพื่อทำงานกับข้อมูลเหล่านั้น ซึ่งทั้งหมดนี้ควรให้ประสบการณ์ที่ราบรื่นและเป็นหนึ่งเดียว แต่เมื่อตัวตนของผู้ใช้ต้องข้ามขอบเขตของ Control Plane และ Data Plane ในทุกขั้นตอน การจัดการ Single Sign-On (SSO) แบบเดิมๆ ก็อาจไม่เพียงพออีกต่อไปสำหรับทีมที่ดูแลแพลตฟอร์มข้อมูลหรือ AI แบบกระจายศูนย์ที่ครอบคลุมหลายคลัสเตอร์ การส่งต่อบริบทของผู้ใช้ไปยังสภาพแวดล้อมการประมวลผลแบบกระจายทำได้ยาก โดยไม่จำเป็นต้องส่ง Token ดิบให้กับทุกแอปพลิเคชัน ทำให้การเพิกถอนสิทธิ์ทำได้ยากขึ้น หรือบังคับให้แต่ละคลัสเตอร์ต้องสร้าง Logic การจัดการ Identity Provider ขึ้นมาใหม่เองความท้าทายนี้ยิ่งทวีความสำคัญสำหรับแพลตฟอร์ม AI และข้อมูล ที่ซึ่งข้อมูลและการประมวลผลมักจะอยู่ใกล้กับแหล่งผลิต จัดเก็บ หรือควบคุม เวิร์กโหลดอาจทำงานในคลัสเตอร์ระดับภูมิภาค บัญชีคลาวด์แยกต่างหาก สภาพแวดล้อม On-premises หรือระนาบการประมวลผลเฉพาะทาง แต่ผู้ใช้ยังคงคาดหวังประสบการณ์แพลตฟอร์มที่เป็นหนึ่งเดียว ครอบคลุมทั้ง Notebook, Catalog, เครื่องมือ Query และผู้ช่วย AIบทความนี้จะนำเสนอรูปแบบ "Central Identity Gateway Pattern" หรือ "รูปแบบเกตเวย์ตัวตนแบบรวมศูนย์" สำหรับการส่งต่อตัวตนผู้ใช้ข้าม Data Planes ที่กระจายศูนย์ โดยเกตเวย์ส่วนกลางจะเป็นเจ้าของ Session ของแพลตฟอร์ม ในขณะที่เกตเวย์ระดับภูมิภาคจะตรวจสอบ Session ดังกล่าวผ่าน API ที่ใช้ร่วมกัน และแปลงเป็นบริบทตัวตนท้องถิ่นที่เชื่อถือได้สำหรับแอปพลิเคชันปลายทาง รูปแบบนี้ใช้มาตรฐาน OpenID Connect (OIDC), ที่เก็บ Session ที่ใช้ร่วมกัน, เกตเวย์ระดับภูมิภาคแบบ Stateless และ API ตรวจสอบตัวตนขนาดเล็กที่บริการต่างๆ สามารถเชื่อถือได้ที่ NVIDIA การนำรูปแบบนี้มาใช้ช่วยลดเหตุการณ์การเข้าสู่ระบบซ้ำๆ ลงได้ถึง 55% บนแพลตฟอร์มสำหรับนักพัฒนาภายใน ที่ครอบคลุมคลัสเตอร์ Kubernetes ใน AWS และ OCI ที่สำคัญกว่านั้นคือ การสร้างรากฐานที่นำกลับมาใช้ใหม่ได้สำหรับ Unified Platform Shells, การออกจากระบบที่สอดคล้องกัน, การลดภาระของ Identity Provider ต้นทาง และการทำให้ AI Assistants สามารถทำงานโดยมีตัวตนของผู้ใช้ที่ได้รับมอบหมายข้าม Data Planes ได้เมื่อ SSO สิ้นสุดลง และตัวตน Data Plane เริ่มต้นขึ้นรายละเอียดการนำไปใช้งานอาจแตกต่างกันไปในแต่ละองค์กร แต่การออกแบบหลักสามารถนำไปปรับใช้ได้อย่างกว้างขวางสำหรับทีมแพลตฟอร์มที่ใช้งานสภาพแวดล้อม Kubernetes แบบ Federated, แพลตฟอร์มข้อมูล Multi-cloud, Machine Learning Workbench, พอร์ทัลสำหรับนักพัฒนาภายใน หรือสแต็กแอปพลิเคชัน AI ที่มีเครื่องมือที่ผ่านการรับรองความถูกต้องหลายอย่างSSO ช่วยให้ผู้ใช้มีจุดเข้าใช้งานเพียงจุดเดียว แต่แพลตฟอร์มข้อมูลแบบ Federated ยังคงต้องการวิธีการส่งต่อตัวตนเข้าไปยังระนาบที่การทำงานเกิดขึ้นจริง ไม่ว่าจะเป็น Notebook ในคลัสเตอร์หนึ่ง, API Catalog ในอีกคลัสเตอร์หนึ่ง, หรือผู้ช่วยที่เรียกใช้ Query Engine ในคลัสเตอร์ที่สาม ทั้งหมดนี้ต้องการคำตอบเดียวกัน: "ใครคือผู้ใช้ และพวกเขาได้รับอนุญาตให้ทำอะไรที่นี่?"หากไม่มีโมเดลการส่งต่อตัวตนที่ใช้ร่วมกัน ปัญหาหลายอย่างจะปรากฏขึ้น:การยืนยันตัวตนที่ Control Plane ไม่ได้กลายเป็นตัวตน Data Plane ที่เชื่อถือได้โดยอัตโนมัติ: การยืนยันตัวตนที่จุดเข้าใช้งานเพียงอย่างเดียว ไม่ได้รับประกันว่าผู้ใช้คนเดียวกันนี้จะถูกจดจำและได้รับสิทธิ์ที่ถูกต้องในทุกส่วนของระบบที่กระจายออกไปการส่งต่อ Token ดิบเพิ่มความเสี่ยงด้านข้อมูลประจำตัว: การส่ง Token ที่มีสิทธิ์ของผู้ใช้โดยตรงไปยังทุกบริการ ทำให้ยากต่อการตรวจสอบว่าใครสามารถใช้ Token ใดได้บ้าง และเพิ่มโอกาสในการรั่วไหลเกตเวย์ Data Plane แต่ละแห่งอาจผสานรวมกับ Identity Provider แตกต่างกัน: นำไปสู่ความไม่สอดคล้องกันของ Claims, พฤติกรรมการ Refresh Token และบันทึกการตรวจสอบ (Audit Records)การออกจากระบบและการเพิกถอนสิทธิ์อาจไม่แพร่กระจายอย่างรวดเร็ว: การออกจากระบบในคลัสเตอร์หนึ่ง อาจยังคงมี Session ที่ทำงานอยู่ในคลัสเตอร์อื่น ทำให้เกิดความสับสนและความเสี่ยงด้านความปลอดภัยแอปพลิเคชันใหม่ได้รับสิทธิ์การจัดการตัวตนที่ซ้ำซ้อน: การเพิ่มเครื่องมือใหม่ๆ มักจะหมายถึงการสร้างการรวมระบบการยืนยันตัวตนแบบเดิมๆ ซ้ำอีกครั้งสำหรับผู้ใช้ อาการที่สังเกตได้อาจเป็น "การแจ้งให้เข้าสู่ระบบซ้ำๆ" สำหรับวิศวกรแพลตฟอร์ม ปัญหาที่ซ่อนอยู่คือ "การส่งต่อ Token แบบกระจาย" ซึ่งตัวตนที่สร้างขึ้นที่ Control Plane จะต้องถูกแปลงเป็นบริบทที่เชื่อถือได้ มีขอบเขตที่ชัดเจน และตรวจสอบได้ในทุก Data Planeโมเดลนี้ใช้ได้ดีกับแอปพลิเคชันจำนวนน้อย แต่จะสร้างปัญหาเชิงโครงสร้างเมื่อแพลตฟอร์มขยายตัว:Session ถูกจำกัดขอบเขตตามที่สร้างขึ้น: Token ที่ออกโดยเกตเวย์หนึ่ง จะไม่เป็นที่รู้จักของเกตเวย์อื่น ทำให้ผู้ใช้ต้องยืนยันตัวตนสำหรับแต่ละบริการ แทนที่จะเป็นทั้งแพลตฟอร์มการออกจากระบบเป็นแบบ Local: การออกจากระบบเครื่องมือหนึ่ง อาจยังคงมี Session ที่ทำงานอยู่กับเครื่องมืออื่น ทำให้เกิดทั้งความสับสนของผู้ใช้และความเสี่ยงด้านความปลอดภัยการ Refresh Token ไม่ได้รับการประสานงาน: แต่ละเกตเวย์จะเจรจาวงจรการ Refresh กับ Identity Provider ต้นทางอย่างอิสระ เพิ่มภาระและสร้างสถานะ Session ที่แตกต่างกันบริบทตัวตนไม่สอดคล้องกัน: บริการปลายทางมักจะแยกวิเคราะห์ Token แตกต่างกัน หรือมีการทำซ้ำ Logic การยืนยันตัวตนบริการใหม่ๆ ต้องเผชิญกับความซับซ้อนเดิมๆ: การเพิ่มเครื่องมืออีกชิ้น มักจะหมายถึงการสร้างการรวมระบบการยืนยันตัวตนแบบเดิมๆ ซ้ำอีกครั้งสำหรับผู้ใช้แพลตฟอร์ม อาการที่พบคือการแจ้งให้เข้าสู่ระบบซ้ำๆ และพฤติกรรมที่ไม่สอดคล้องกัน สำหรับวิศวกรแพลตฟอร์ม ปัญหาที่ลึกกว่านั้นคือ "การเป็นเจ้าของ Session" ที่กระจายอยู่ในส่วนประกอบต่างๆ ซึ่งควรมีหน้าที่เพียงการบังคับใช้นโยบาย (Access Enforcement) เท่านั้น ไม่ใช่การเป็นเจ้าของสถานะตัวตนเปรียบเทียบรูปแบบการจัดการตัวตน 2 แบบมีสองวิธีทั่วไปในการจัดโครงสร้างการจัดการตัวตนในแพลตฟอร์มแบบ Federated:รูปแบบการเป็นเจ้าของ Session แบบกระจาย (Distributed Session Ownership): เกตเวย์ของแต่ละบริการจะเป็นเจ้าของ Flow การเข้าสู่ระบบ, ที่เก็บ Session, Logic การ Refresh Token และพฤติกรรมการออกจากระบบของตนเอง วิธีนี้ช่วยให้แต่ละคลัสเตอร์เป็นอิสระ แต่ก็หมายความว่าสถานะตัวตนจะไม่สามารถเคลื่อนย้ายข้ามแพลตฟอร์มได้อย่างราบรื่นรูปแบบการเป็นเจ้าของ Session แบบรวมศูนย์ (Centralized Session Ownership): เกตเวย์ตัวตนเฉพาะจะรับผิดชอบการเข้าสู่ระบบ, สถานะ Session, การ Refresh และการออกจากระบบ เกตเวย์ระดับภูมิภาคยังคงมีอยู่ แต่จะมอบหมายการตรวจสอบ Session ให้กับเกตเวย์ส่วนกลาง และเน้นการบังคับใช้นโยบายการเข้าถึง (Request Enforcement)| คุณสมบัติ | รูปแบบกระจาย (Distributed) | รูปแบบรวมศูนย์ (Centralized) || :----------------------- | :--------------------------------------------------------- | :------------------------------------------------------------ || การเข้าสู่ระบบ | แต่ละเกตเวย์จัดการ OIDC Flow และ Session ของตนเอง | เกตเวย์ส่วนกลางจัดการ OIDC Flow และสร้าง Session แพลตฟอร์ม || การออกจากระบบ | การออกจากระบบเป็นแบบ Local, ไม่ส่งผลต่อบริการอื่น | การออกจากระบบที่เกตเวย์ส่วนกลาง จะส่งผลทันทีทั่วทั้งแพลตฟอร์ม || การ Refresh Token | แต่ละเกตเวย์จัดการ Refresh Token ของตนเอง | เกตเวย์ส่วนกลางจัดการ Refresh Token และอัปเดต Session ที่ใช้ร่วมกัน || การส่งต่อตัวตน | ต้องส่ง Token ดิบ หรือ Claims จาก Token | เกตเวย์ระดับภูมิภาคสร้าง Header ตัวตนที่เชื่อถือได้จาก Session || การปรับขนาดการดำเนินงาน | ภาระ Identity Provider เพิ่มตามจำนวน User-Tool Combinations | ภาระ Identity Provider ปรับตามจำนวน User ที่ใช้งานอยู่ |การเป็นเจ้าของ Session แบบรวมศูนย์ไม่จำเป็นสำหรับทุกแอปพลิเคชัน แต่จะกลายเป็นสิ่งที่มีคุณค่าเมื่อผู้ใช้ต้องทำงานข้ามเครื่องมือ, คลัสเตอร์, หรือภูมิภาคต่างๆ ใน Workflow เดียวกัน และคาดหวังว่าเครื่องมือเหล่านั้นจะทำงานเสมือนเป็นแพลตฟอร์มเดียวรูปแบบ Central Identity Gatewayเกตเวย์ตัวตนส่วนกลางรับผิดชอบ 3 ส่วนหลัก:การสร้าง Session: จัดการ OIDC Authorization Code Flow และสร้าง Session ที่ครอบคลุมทั้งแพลตฟอร์มการตรวจสอบตัวตนต่อคำขอ (Per-request Identity Validation): ตอบคำถาม "ใครคือผู้ใช้นี้?" สำหรับเกตเวย์หรือบริการที่เชื่อถือได้การจัดการวงจรชีวิต Session: ประสานงานการ Refresh Token และการออกจากระบบทั่วทั้งแพลตฟอร์มเกตเวย์การยืนยันตัวตนระดับภูมิภาคยังคงมีอยู่ โดยยังคงทำหน้าที่บังคับใช้นโยบายต่อคลัสเตอร์, ปกป้องบริการในพื้นที่, และแทรกตัวตนเข้าไปในคำขอ สิ่งที่เปลี่ยนแปลงคือ "ที่อยู่" ของ Session แทนที่จะเก็บ Session ไว้ในเกตเวย์ระดับภูมิภาคแต่ละแห่ง เกตเวย์ส่วนกลางจะเขียน Session ที่ผ่านการยืนยันตัวตนทั้งหมดไปยังที่เก็บที่ใช้ร่วมกัน เช่น RedisSession จะถูกคีย์ด้วย Session ID ที่ไม่เปิดเผย และเชื่อมโยงกับ Cookie ของเบราว์เซอร์ที่ปลอดภัยแบบ HTTP-only ซึ่งถูกกำหนดขอบเขต (scoped) ให้กับโดเมนของแพลตฟอร์มในแต่ละคำขอ เกตเวย์ระดับภูมิภาคจะเรียก Endpoint การตรวจสอบตัวตน เช่น /gateway/userinfo เกตเวย์ส่วนกลางจะตรวจสอบที่เก็บ Session และส่งคืน Identity Claims ที่เชื่อถือได้ เกตเวย์ระดับภูมิภาคจะแทรกชุด Header ตัวตนที่เป็นมาตรฐานก่อนส่งต่อคำขอไปยังแอปพลิเคชันแอปพลิเคชันไม่จำเป็นต้องแยกวิเคราะห์ Token, Refresh ข้อมูลประจำตัว, หรือผสานรวมโดยตรงกับ Identity Provider อีกต่อไป พวกเขาจะได้รับตัวตนจาก Interface ที่สอดคล้องกันรูปแบบนี้มี 3 Flow หลัก: การเข้าสู่ระบบ, การตรวจสอบ, และการออกจากระบบFlow การเข้าสู่ระบบ (Login Flow)เมื่อผู้ใช้เข้ามาโดยไม่มี Session แพลตฟอร์มที่ถูกต้อง เกตเวย์ระดับภูมิภาคจะเปลี่ยนเส้นทางเบราว์เซอร์ไปยังเกตเวย์ส่วนกลาง เกตเวย์ส่วนกลางจะดำเนินการ OIDC Authorization Code Flow กับ Identity Provider ขององค์กร, แลกเปลี่ยน Authorization Code แบบ Server-side, จัดเก็บ Session ที่ได้ใน Redis พร้อมกำหนด Time-to-live (TTL) และตั้งค่า Session Cookie แบบ HTTP-onlySession Cookie นี้จะกลายเป็นข้อมูลประจำตัวแพลตฟอร์มของผู้ใช้สำหรับ Session ที่เหลือการตรวจสอบต่อคำขอ (Per-request Validation)ในการร้องขอครั้งต่อๆ ไป เกตเวย์ระดับภูมิภาคจะส่ง Session Cookie ไปยัง /gateway/userinfo เกตเวย์ส่วนกลางจะทำการค้นหา Session และส่งคืน Identity Claims เช่น User ID, อีเมล, กลุ่ม, บทบาท และ Metadata ของ Sessionเกตเวย์ระดับภูมิภาคจะใช้ Claims เหล่านี้เพื่อแทรก Header ตัวตนที่เชื่อถือได้ บริการปลายทางจะอ่าน Header และใช้ Logic การอนุญาต (Authorization Logic) ในระดับท้องถิ่นตามความจำเป็นสิ่งนี้ทำให้เส้นทางการร้องขอ (Request Path) มีน้ำหนักเบา การร้องขอปกติไม่จำเป็นต้องมีการแลกเปลี่ยน OIDC หรือการเรียก Identity Provider โดยตรง เพียงแค่การค้นหา Session และการเรียกตรวจสอบความถูกต้องระหว่างเกตเวย์ที่เชื่อถือได้การ Refresh Token และการออกจากระบบ (Token Refresh and Logout)เมื่อ Access Token ใกล้หมดอายุ เกตเวย์ส่วนกลางจะ Refresh Token โดยใช้ Refresh Token ที่จัดเก็บไว้ และอัปเดตบันทึก Session เนื่องจากสถานะที่ Refresh แล้วถูกเขียนไปยังที่เก็บที่ใช้ร่วมกัน เกตเวย์ระดับภูมิภาคทุกแห่งจึงจะเห็นสถานะ Session เดียวกันสำหรับการออกจากระบบ เกตเวย์ส่วนกลางจะลhttps://developer.nvidia.com/blog/how-to-carry-user-identity-across-federated-kubernetes-and-ai-platforms/