ข้ามไปยังเนื้อหา
THAI DATA IT BUSINESS
ENTERPRISE
Data & Analytics

ClickHouse Cloud รองรับ JWT ล็อกอินด้วยโทเคนจาก Okta และ Entra แทนรหัสผ่านฐานข้อมูล

ClickHouse Cloud รองรับการยืนยันตัวตนด้วย JWT ตั้งแต่ 8 ต.ค. 2026 ใช้โทเคนอายุสั้นจาก Okta หรือ Microsoft Entra แทนรหัสผ่าน แล้วสร้างผู้ใช้ชั่วคราวตาม role

โดย กองบรรณาธิการ THAI DATA อ่าน 4 นาที

แชร์FacebookXLINELinkedIn
ภาพประกอบของ ClickHouse: Introducing JWT authentication in ClickHouse Cloud แสดงโทเคน JWT กับ claim ISS, AUD, SUB, EXP และ ROLES
ภาพ: ClickHouse

สรุปประเด็นสำคัญ

  • ClickHouse ประกาศเมื่อ 8 ตุลาคม 2026 ให้ ClickHouse Cloud ยืนยันตัวตนด้วย JWT จากผู้ให้บริการ OpenID Connect เดิมขององค์กร เช่น Okta และ Microsoft Entra
  • การใช้ผู้ให้บริการตัวตนขององค์กรเองต้องเป็นแพ็กเกจ Enterprise และเซอร์วิสเวอร์ชัน 26.4 ขึ้นไป ส่วนคีย์แบบ EC รองรับตั้งแต่เวอร์ชัน 26.8
  • เมื่อโทเคนผ่านการตรวจ ClickHouse สร้างผู้ใช้ชั่วคราวในหน่วยความจำตาม role ในโทเคน และลบทิ้งอัตโนมัติเมื่อโทเคนหมดอายุ ไม่ต้องสั่ง CREATE USER หรือ DROP USER อีก
  • โทเคนต้องมี claim บังคับ 5 รายการ คือ iss, aud, sub, iat และ exp ส่วน role และสิทธิ์ส่งผ่าน claim เสริม clickhouse:roles และ clickhouse:grants
  • quota, row policy และ column masking policy ผูกกับ UUID ที่คงที่ของแต่ละคน จึงยังมีผลแม้ผู้ใช้ชั่วคราวถูกลบแล้วสร้างใหม่

ClickHouse ประกาศเมื่อวันที่ 8 ตุลาคม 2026 ให้ ClickHouse Cloud ยืนยันตัวตนด้วยโทเคน JWT อายุสั้นจากผู้ให้บริการตัวตนแบบ OpenID Connect ที่องค์กรใช้อยู่แล้ว เช่น Okta และ Microsoft Entra แทนรหัสผ่านฐานข้อมูล เมื่อโทเคนหมดอายุ สิทธิ์เข้าถึงก็หมดไปพร้อมกัน

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

ClickHouse ตรวจโทเคนอย่างไร

ตามเอกสารของ ClickHouse ไคลเอนต์ส่งโทเคนมาได้สามช่องทาง คือ header Authorization: Bearer ของ HTTP, โปรโตคอล TCP แบบ native และฟิลด์ jwt ของ gRPC จากนั้น ClickHouse ตรวจลายเซ็นของโทเคนและ claim บังคับ 5 รายการ ได้แก่ iss (ผู้ออกโทเคน), aud (เซอร์วิสปลายทาง), sub (ผู้ใช้), iat (เวลาออก) และ exp (เวลาหมดอายุ)

เมื่อผ่าน ClickHouse จะสร้างผู้ใช้ชั่วคราว (ephemeral user) ในหน่วยความจำ ให้สิทธิ์ตาม claim เสริม clickhouse:roles และ clickhouse:grants แต่ไม่เกินเพดานสิทธิ์ที่เซอร์วิสกำหนด ถ้าผู้ให้บริการตัวตนใช้ชื่อ claim อื่น เช่น groups ก็ตั้งให้ ClickHouse อ่านจากชื่อนั้นได้ ชื่อผู้ใช้มีรูปแบบ JWT::::<claims_hash> โทเคนของคนเดียวกันที่มี role ต่างกันจึงกลายเป็นผู้ใช้คนละชื่อ และดูได้ในตาราง system.users ในเซอร์วิสที่มีหลาย replica ทุกโหนดตรวจโทเคนเองแยกกัน

หัวข้อ Overview ในเอกสาร JWT Authentication ของ ClickHouse อธิบาย 5 ขั้นตอน: ส่งโทเคน ตรวจลายเซ็น ตรวจ claim สร้างผู้ใช้ชั่วคราว และลบเมื่อหมดอายุ
ขั้นตอนการยืนยันตัวตนด้วย JWT ในเอกสารของ ClickHouse ตั้งแต่ไคลเอนต์ส่งโทเคน ตรวจลายเซ็นและ claim สร้างผู้ใช้ชั่วคราว จนถึงการลบเมื่อโทเคนหมดอายุ ภาพ: ClickHouse (ภาพหน้าจอเอกสาร)

ไม่ต้องสร้างและลบผู้ใช้ฐานข้อมูลอีก

ระบบเดิมที่ใช้รหัสผ่านต้องมีคนสั่ง CREATE USER และ GRANT ทุกครั้งที่มีพนักงานใหม่ และต้องจำไปสั่ง DROP USER เมื่อคนลาออก ทีมส่วนใหญ่จึงเขียนสคริปต์จัดการ ซึ่ง ClickHouse ยอมรับว่ามักคลาดเคลื่อนจากผู้ให้บริการตัวตนไปเรื่อย ๆ

ผู้ใช้ JWT ไม่ต้องผ่านขั้นตอนนั้น ผู้ใช้เกิดขึ้นเมื่อมีโทเคนที่ถูกต้อง และงานเบื้องหลังลบทิ้งเมื่อเลยเวลา exp โดยไม่เขียนลงดิสก์และไม่อยู่ในข้อมูลสำรอง คำสั่ง CREATE USER ... IDENTIFIED WITH jwt จะเกิด error โดยตั้งใจ สิ่งที่ผู้ดูแลยังต้องจัดการใน ClickHouse คือ role เช่น analyst หรือ pipeline_writer ส่วนการรับพนักงานเข้าหรือออกกลายเป็นการเพิ่มหรือถอดสมาชิกกลุ่มในผู้ให้บริการตัวตน

หัวข้อ ผู้ใช้แบบรหัสผ่าน ผู้ใช้ JWT
การสร้างผู้ใช้ สั่ง CREATE USER และ GRANT เอง เกิดอัตโนมัติเมื่อโทเคนถูกต้อง
การถอดสิทธิ์ ต้องสั่ง DROP USER หมดเมื่อโทเคนหมดอายุ
ที่เก็บตัวตนและ role ในฐานข้อมูล ในผู้ให้บริการตัวตน
อยู่ในข้อมูลสำรอง ใช่ ไม่

นโยบายเดิมยังมีผลกับผู้ใช้ที่มาแล้วไป

คำถามสำคัญคือ quota, settings profile และ row policy ที่ปกติผูกกับชื่อผู้ใช้จะหายไปพร้อมผู้ใช้ชั่วคราวหรือไม่ ClickHouse แก้ด้วยการคำนวณ UUID ของแต่ละคนจาก iss, sub และ aud ซึ่งคงที่ทุกครั้งที่คนเดิมล็อกอินผ่านผู้ให้บริการเดิม settings profile, quota, row policy และ column masking policy ผูกกับ UUID นี้และเก็บในพื้นที่สิทธิ์ที่ทำซ้ำข้ามโหนด จึงยังมีผลหลังผู้ใช้ถูกลบแล้วสร้างใหม่ ClickHouse แนะนำให้ผูกนโยบายกับ role จะครอบคลุมทุกคนที่ได้ role นั้นโดยอัตโนมัติ

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

ใครใช้ได้และตั้งค่าอย่างไร

การใช้ผู้ให้บริการตัวตนขององค์กรเองต้องเป็นแพ็กเกจ Enterprise กับเซอร์วิสเวอร์ชัน 26.4 ขึ้นไป ตั้งค่าที่ Settings > Security > JWT authentication โดยระบุ issuer, audience และ URL ของ JWKS ที่เป็น HTTPS สาธารณะ ระบบรองรับคีย์ RSA แบบ RS256 และตั้งแต่เวอร์ชัน 26.8 รองรับคีย์ EC แบบ ES256, ES384 และ ES512 ไคลเอนต์ทางการ เช่น clickhouse-js, clickhouse-connect, ไคลเอนต์ Go และ Java ส่งโทเคนแทนชื่อผู้ใช้และรหัสผ่านได้ โดยห้ามส่งทั้งสองแบบพร้อมกัน

นอกจากนี้ทุกเซอร์วิสมีตัวยืนยันตัวตนในตัวที่ใช้ได้ทุกแพ็กเกจ SQL Console ใช้อยู่แล้ว และคำสั่ง clickhouse-client --login ใช้ OAuth2 แบบ device code กับบัญชี ClickHouse Cloud

ตาราง Availability ของ ClickHouse: Built-in ClickHouse authenticator ใช้ได้ทุกแพ็กเกจ ส่วน Custom identity provider ต้องเป็น Enterprise เวอร์ชัน 26.4 ขึ้นไป (26.8 สำหรับคีย์ EC)
ตารางความพร้อมใช้งานจากบล็อกของ ClickHouse: ตัวยืนยันตัวตนในตัวใช้ได้ทุกแพ็กเกจ ส่วนผู้ให้บริการตัวตนขององค์กรต้องเป็น Enterprise และเวอร์ชัน 26.4 ขึ้นไป ภาพ: ClickHouse (ภาพหน้าจอบทความ)

ทำไมเรื่องนี้สำคัญ

แพลตฟอร์มข้อมูลหลายรายกำลังย้ายการตัดสินสิทธิ์ไปไว้ที่ศูนย์กลาง เช่น Databricks ที่ให้นโยบายใน Unity Catalog มีผลข้ามเอนจินผ่าน Cross-engine ABAC ฝั่ง ClickHouse ซึ่งนิยมใช้กับงานวิเคราะห์แบบเรียลไทม์และ observability ใช้แนวทางผูกตัวตนกับผู้ให้บริการตัวตน ClickHouse ระบุว่าโทเคนกำหนดให้แคบเพียง role เดียวและสั้นเพียงงานเดียวได้ ทั้งสำหรับคน pipeline และเอเจนต์ AI ที่ทำงานเพียงไม่กี่นาที

ผลต่อองค์กรไทย

  • ลดรหัสผ่านที่ใช้ร่วมกัน องค์กรที่ใช้ ClickHouse Cloud แพ็กเกจ Enterprise ควรสำรวจรหัสผ่านที่ BI, pipeline และแอปใช้อยู่ แล้วทยอยย้ายไปใช้โทเคนจาก Okta หรือ Microsoft Entra ที่มีอยู่แล้ว
  • ออกแบบ role ก่อนเปิดใช้ สร้าง role ตามหน้าที่ใน ClickHouse แล้วผูก row policy และ quota กับ role แทนผูกรายคน
  • ผูกการถอดสิทธิ์กับระบบ HR เมื่อสิทธิ์ขึ้นกับกลุ่มในผู้ให้บริการตัวตน การถอดสมาชิกกลุ่มคือการปิดสิทธิ์ฐานข้อมูล ช่วยลดบัญชีค้างของคนที่พ้นหน้าที่ และทำให้การควบคุมการเข้าถึงข้อมูลส่วนบุคคลตามหลัก PDPA เป็นระบบมากขึ้น
  • อัปเกรดเวอร์ชันและทดสอบไคลเอนต์ ตรวจว่าเซอร์วิสเป็น 26.4 ขึ้นไป และไคลเอนต์ที่ใช้รองรับการต่ออายุโทเคน เช่น token_provider ของ clickhouse-connect

อ่านข่าวฐานข้อมูลและ Data Governance อื่นได้ที่หมวดข้อมูล

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

JWT authentication ใน ClickHouse Cloud คืออะไร?

เป็นการยืนยันตัวตนที่ ClickHouse Cloud รับโทเคน JWT อายุสั้นจากผู้ให้บริการตัวตนแบบ OpenID Connect เช่น Okta หรือ Microsoft Entra แทนรหัสผ่านฐานข้อมูล ClickHouse ตรวจลายเซ็นและ claim ของโทเคน แล้วสร้างผู้ใช้ชั่วคราวที่มีสิทธิ์ตาม role ในโทเคน ประกาศเมื่อ 8 ตุลาคม 2026

ใช้ JWT กับ ClickHouse Cloud ต้องมีเงื่อนไขอะไร?

ถ้าใช้ผู้ให้บริการตัวตนขององค์กรเอง ต้องเป็นแพ็กเกจ Enterprise และเซอร์วิสเวอร์ชัน 26.4 ขึ้นไป ตั้งค่าที่ Settings > Security > JWT authentication โดยระบุ issuer, audience และ URL ของ JWKS ที่เป็น HTTPS สาธารณะ ส่วนตัวยืนยันตัวตนในตัวที่ใช้กับ SQL Console มีให้ทุกแพ็กเกจ

ผู้ใช้ชั่วคราว (ephemeral user) ใน ClickHouse ต่างจากผู้ใช้ทั่วไปอย่างไร?

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

row policy และ quota ยังใช้ได้ไหมเมื่อผู้ใช้ JWT หมดอายุแล้ว?

ใช้ได้ ClickHouse คำนวณ UUID ของแต่ละคนจาก claim iss, sub และ aud ซึ่งคงที่ทุกครั้งที่ล็อกอิน settings profile, quota, row policy และ column masking policy ผูกกับ UUID นี้ จึงไม่หายตามผู้ใช้ชั่วคราว และ ClickHouse แนะนำให้ผูกกับ role จะง่ายกว่า

แหล่งอ้างอิง

  1. Introducing JWT authentication in ClickHouse Cloud — ClickHouse
  2. JWT Authentication — ClickHouse Documentation
แท็กClickHouseClickHouse CloudJWTIdentityData Governance
แชร์FacebookXLINELinkedIn

พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ