ข้อควรพิจารณาสำหรับการตั้งค่า IBM Quantum Platform สำหรับองค์กร

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

ภาพรวม

หมายเหตุ

IBM Cloud® มีวิธีต่าง ๆ ในการนำกลไกที่อธิบายในคู่มือนี้ไปใช้ มีหลายวิธีในการบรรลุวัตถุประสงค์เหล่านี้ นอกจากนี้ ขั้นตอนส่วนใหญ่ในคู่มือนี้เป็นแบบทั่วไปของ IBM Cloud และไม่เฉพาะเจาะจงกับ IBM Quantum Platform ยกเว้นรายละเอียด custom role

บุคคลที่เกี่ยวข้อง

มีบุคคลหลักหลายคนที่กล่าวถึงในคู่มือนี้:

• ผู้ใช้: คนที่ได้รับการเข้าถึงทรัพยากร IBM Quantum Platform (service instances) และอาจร่วมมือกับผู้ใช้คนอื่นบนทรัพยากรเหล่านี้ การเข้าถึงของผู้ใช้ถูกควบคุมโดยผู้ดูแลระบบและไม่สามารถสร้างหรือลบ service instances ได้
• Cloud administrator: เจ้าของบัญชี IBM Cloud ที่เป็นเจ้าของทรัพยากร IBM Quantum Platform และจัดการว่าผู้ใช้คนใดสามารถเข้าถึงทรัพยากรเหล่านี้ได้ ในฐานะเจ้าของทรัพยากร ผู้ดูแลระบบต้องรับผิดชอบค่าใช้จ่ายสำหรับการใช้ทรัพยากรแบบชำระเงิน
• IDP administrator: ผู้ดูแลระบบที่กำหนด identities และคุณลักษณะของพวกเขาใน identity provider (IDP)

คำศัพท์

คู่มือนี้ใช้คำศัพท์ต่อไปนี้:

• Resource: คำทั่วไปของ IBM Cloud ที่หมายถึงออบเจกต์ที่สามารถจัดการผ่าน Cloud user interface, CLI หรือ API สำหรับคู่มือนี้ resource คือ IBM Quantum Platform service instance

• Service instance: Service instance ใช้เพื่อเข้าถึง Cloud services โดยเฉพาะคอมพิวเตอร์ควอนตัม กำหนดผ่าน catalog สามารถกำหนด service instances หลายตัวตามแผนเดียวกันหรือต่างกัน ซึ่งให้การเข้าถึง Backend การคำนวณควอนตัมที่แตกต่างกัน ดูรายละเอียดที่ แผน IBM Cloud ที่ใช้ได้

• Project: หน่วยการจัดกลุ่มที่ช่วยให้ผู้ใช้ทำงานบนทรัพยากรเดียวกัน คู่มือนี้ใช้สองโปรเจกต์: ml และ finance ดูข้อมูลเพิ่มเติมที่ โครงสร้างโปรเจกต์แบบลำดับชั้น

  หมายเหตุ

  โปรเจกต์นี้ไม่เกี่ยวข้องกับแนวคิด "project" ใน IBM Quantum® Platform เวอร์ชันคลาสสิก

วางแผนการตั้งค่า

ก่อนตั้งค่า IBM Quantum Platform สำหรับองค์กร ต้องตัดสินใจสิ่งเหล่านี้:

• จะกำหนด user identities อย่างไร สามารถตั้งค่าผู้ใช้ IBM Cloud, ผู้ใช้จาก IDP อื่น หรือทั้งสองอย่าง

  • ถ้าใช้ IDP อื่น Cloud administrator หรือ IDP administrator เป็นคนกำหนดผู้ใช้ให้กับทรัพยากรโปรเจกต์?
  • ถ้า IDP administrator กำหนดผู้ใช้ให้กับโปรเจกต์ จำเป็นต้องมี string ที่ใช้เป็น key เช่น project (ที่คู่มือนี้ใช้) สำหรับการเปรียบเทียบโปรเจกต์

• โปรเจกต์คืออะไรและ service instances ใดจะอยู่ในแต่ละโปรเจกต์? ต้องวางแผนชื่อโปรเจกต์อย่างรอบคอบ

  • อย่าทำชื่อโปรเจกต์เป็น substring ของอีกชื่อหนึ่ง เช่น ถ้าใช้ ml และ chemlab เป็นชื่อโปรเจกต์ แล้วตั้งค่า project match สำหรับ ml ในภายหลัง จะ trigger ทั้งสองค่า ทำให้เกิดการให้สิทธิ์การเข้าถึงมากกว่าที่คาดไว้โดยไม่ตั้งใจ แทนที่นั้น ให้ใช้ชื่อที่ไม่ซ้ำกัน เช่น ml และ chem-lab หรือใช้ค่า prefix หรือ suffix เพื่อหลีกเลี่ยง substring matches ที่ไม่ตั้งใจดังกล่าว
  • การใช้ naming conventions ร่วมกับค่า prefix หรือ suffix สามารถช่วยให้อนุญาตการเข้าถึงหลายโปรเจกต์ได้ง่าย
  • การทดลองควอนตัม (jobs) อยู่ใน service instances และผู้ใช้ที่มีการเข้าถึง instance สามารถดู jobs ของ instance นั้นได้
  • Service instances สามารถใช้แผนต่างกันได้ โดยอนุญาตให้เข้าถึง Backend ต่างกัน

• ผู้ใช้คนใดต้องเข้าถึงโปรเจกต์ใด?

• ผู้ใช้ควรสามารถลบ jobs ได้หรือไม่? การเก็บ jobs ใน service instances ทำให้ติดตามค่าใช้จ่ายในการเรียกเก็บเงินได้ดีขึ้น

• จะใช้ access groups ที่อ้างอิง IBM Quantum Platform service instances โดยตรง หรือจัดระเบียบ services เป็น resource groups?

  • Access groups เป็นวิธีที่สะดวกและพบได้บ่อยในการควบคุมการเข้าถึงของผู้ใช้สำหรับทรัพยากร IBM Cloud เป็นวิธีที่เรียบง่ายแต่ทรงพลังในการกำหนดการเข้าถึงของผู้ใช้อย่างสม่ำเสมอ สร้าง access group สำหรับแต่ละโปรเจกต์และ map ผู้ใช้ไปยัง access groups แต่ละ access group ใช้ custom role ที่อนุญาตให้ผู้ใช้เข้าถึง service instances หรือ resource groups ที่เฉพาะเจาะจง
  • Resource groups ใช้เฉพาะเมื่อต้องการรักษาการแยก service instances อย่างชัดเจน ถ้าสร้าง service instances เพิ่มเติมใน resource group ผู้ใช้ทั้งหมดที่มีการเข้าถึง resource group จะเห็นพวกเขาโดยอัตโนมัติโดยไม่ต้องอัปเดต access groups ถ้าเลือกใช้ resource groups จะต้องสร้าง access groups ก่อนแล้วกำหนดให้กับ resource groups
  หมายเหตุ

  Service instance สามารถอยู่ใน resource group ได้เพียงหนึ่งเดียว และหลังจาก instances ถูกกำหนดเข้า resource groups แล้ว ไม่สามารถเปลี่ยนได้ ซึ่งหมายความว่าการกำหนด resource group สามารถเกิดขึ้นได้เฉพาะตอนสร้าง service instance เท่านั้น ดังนั้น resource groups อาจไม่ยืดหยุ่นเพียงพอถ้าการกำหนด service instances ให้กับ resource groups อาจต้องเปลี่ยนแปลง

ข้อควรพิจารณา

ควรทำความเข้าใจข้อควรพิจารณาต่อไปนี้เมื่อตั้งค่าสภาพแวดล้อม

กำหนด roles ที่ละเอียดกว่า

actions ใน custom roles สามารถใช้เพื่อการควบคุมการเข้าถึงที่ละเอียดกว่าได้ เช่น ผู้ใช้บางคนอาจต้องการการเข้าถึงแบบเต็มรูปแบบเพื่อทำงานบน service instances ในขณะที่คนอื่นอาจต้องการเพียงการเข้าถึงแบบอ่านอย่างเดียวสำหรับ service instances, programs และ jobs

เพื่อบรรลุเป้าหมายนั้น ให้กำหนด custom roles สองตัวที่แตกต่างกัน เช่น MLreader และ MLwriter ลบ roles cancel, delete และ update ทั้งหมดออกจาก MLreader custom role และรวม actions ทั้งหมดใน MLwriter custom role จากนั้นเพิ่ม roles ให้กับ access groups สองตัวที่แตกต่างกันตามลำดับ

หมายเหตุ

เมื่อใช้ dynamic rules นั่นคือเมื่อ identity provider (IDP) administrator จัดการการเข้าถึงผ่าน custom IDP user attributes อย่าใช้ IDP custom user attributes ที่เป็น substring ของกัน ตัวอย่างเช่น อย่าใช้ ml และ mlReader เนื่องจากการเปรียบเทียบ string ของ ml จะยอมรับ mlReader ด้วย สามารถใช้ MLreader และ MLwriter เพื่อหลีกเลี่ยงความขัดแย้งนี้

สำหรับตัวอย่างการตั้งค่า custom roles ดูที่ สร้าง access groups สำหรับโปรเจกต์

การเข้าถึง workload ร่วมกัน

สิ่งสำคัญที่ต้องสังเกตคือการเข้าถึงใช้กับ service instances ดังนั้นผู้ใช้ที่มีสิทธิ์ 'write' ใน instance สามารถยกเลิก workloads ของตนเองได้ แต่ยังสามารถดูและยกเลิก workloads ของผู้ใช้คนอื่นได้ด้วย นี่คือฟังก์ชันของวิธีที่ IAM ทำงานและไม่สามารถเปลี่ยนแปลงได้

ทรัพยากร Cloud อื่น ๆ

ขั้นตอนในคู่มือนี้สามารถใช้เพื่อจัดการการเข้าถึงทรัพยากร Cloud อื่น ๆ ได้เช่นกัน ให้รวม permissions ที่เหมาะสมไว้ใน access groups ของโปรเจกต์ที่เกี่ยวข้อง

โครงสร้างโปรเจกต์แบบลำดับชั้น

ในคู่มือนี้ การ mapping ผู้ใช้ไปยังโปรเจกต์และ service instances ถูกทำให้เรียบง่าย อย่างไรก็ตาม โดยการเชื่อมโยงผู้ใช้หลายคนกับ access groups และอ้างอิง service instances จาก access groups หลายตัว สามารถนำ mappings ที่ซับซ้อนกว่ามาใช้ได้

วิธีนี้สามารถรองรับโครงสร้างลำดับชั้นได้ นั่นคือสามารถสอดคล้องกับวิธีที่ผู้ใช้อาจถูกกำหนดให้กับโครงสร้างการเข้าถึง Hub/Group/Project ในเวอร์ชันคลาสสิกของ IBM Quantum® Platform ตัวอย่างเช่น group อาจเป็น access group ที่ถูกกำหนดให้กับ service instances ทั้งหมดของโปรเจกต์ของ group ผู้ใช้ที่ควรได้รับการเข้าถึงโปรเจกต์ทั้งหมดของ group นั้นจะต้องเพิ่มเข้าไปใน access group ของ group นั้นเท่านั้น

การ deploy configuration อย่างสม่ำเสมอและทำซ้ำได้

ขั้นตอนของคู่มือนี้สามารถทำให้เป็นอัตโนมัติสำหรับการจัดการผู้ใช้ โปรเจกต์ และการ mapping ระหว่างสิ่งเหล่านั้นอย่างสม่ำเสมอและทำซ้ำได้ ดูเอกสาร Terraform IBM Cloud® Provider สำหรับ templates

ขั้นตอนถัดไป

คำแนะนำ

• ดู กำหนดค่า IBM Quantum Platform สำหรับองค์กร สำหรับขั้นตอนการตั้งค่า IBM Quantum Platform
• ทำความเข้าใจแผนที่ใช้ได้
• สร้าง instances
• ทำความเข้าใจโครงสร้าง IBM Cloud
• สร้าง policies และ access groups
• จัดการผู้ใช้