Mga konsiderasyon sa pag-set up ng IBM Quantum Platform para sa isang organisasyon

Ang IBM Quantum® Platform ay ang dashboard para sa mga instance at workload ng IBM Quantum Compute Service ng iyong IBM Cloud® account, at nagbibigay ng pinasimpleng view ng access management. Ang IBM Cloud account ng isang organisasyon ay maaaring magkaroon ng maraming user at maraming Quantum Compute instance, bawat isa ay may sariling allocation. Kinokontrol ng Identity and Access Management (IAM) kung aling mga user ang maaaring mag-access sa aling mga service instance, kaya maaari kang magbigay-daan sa collaboration habang nirerestrict ang visibility kung saan kailangan. Nagiging mas relevant ang access management kung mayroon kang mga service instance sa mga bayad na plano. Tingnan ang IBM Cloud account structure para sa isang overview kung paano magkasama ang mga account, user, instance, at access. Sumangguni sa IBM Cloud IAM documentation para sa buong detalye ng mga konsepto ng IAM na binanggit sa gabay na ito, tulad ng access groups, policies, roles, at resource groups.

Inilalarawan ng gabay na ito ang mga desisyon at tradeoffs na kaugnay sa pag-set up ng access para sa isang organisasyon na may maraming service instance — halimbawa, ang pag-assign ng isang instance kada team o workload.

tala

Kung ang iyong organisasyon ay may maraming IBM Cloud accounts — halimbawa, magkakahiwalay na accounts para sa bawat business unit, na bawat isa ay may sariling Quantum Compute instances — maaari mong i-link ang mga ito sa ilalim ng iisang IBM Cloud Enterprise account, na may isang pangunahing account na responsable para sa billing at isa o higit pang child accounts. Para i-redistribute ang Premium o Flex Plan allocation sa pagitan ng mga child accounts, makipag-ugnayan sa IBM Quantum support sa pamamagitan ng IBM Cloud Support Center. Tingnan ang IBM Cloud Enterprise account documentation para sa buong detalye.

Pangkalahatang-ideya

tala

Ang IBM Cloud® ay nagbibigay ng ilang paraan upang ipatupad ang mga mekanismong inilarawan sa gabay na ito. Karamihan sa mga hakbang ay pangkalahatan sa IBM Cloud at hindi partikular sa Quantum Compute, maliban sa mga detalye ng custom role.

Mga taong kasangkot

Ang mga sumusunod na persona ay binabanggit sa gabay na ito:

• User: Isang taong nakakakuha ng access sa Quantum Compute resources (service instances) at maaaring makipagtulungan sa ibang mga user sa mga resource na ito. Ang access ng mga user ay kontrolado ng isang administrator, at hindi sila maaaring lumikha o magtanggal ng mga service instance.

• Cloud administrator: Isang IBM Cloud account owner na nagmamay-ari ng IBM Quantum Compute resources at namamahala kung sino ang may access sa mga resource na ito. Bilang may-ari ng resource, ang administrator ay sisingilin para sa anumang bayad na paggamit ng resource.

• IDP administrator: Isang administrator na nagtatakda ng mga pagkakakilanlan at ang kanilang mga katangian sa isang identity provider (IDP).

Terminolohiya

Ginagamit ng gabay na ito ang mga sumusunod na termino:

• Resource: Isang pangkaraniwang IBM Cloud term na tumutukoy sa isang object na maaaring pamahalaan sa pamamagitan ng Cloud user interface, CLI, o API. Para sa gabay na ito, ang resource ay isang Quantum Compute Service instance.

• Service instance: Ang isang service instance ay ginagamit para ma-access ang mga Cloud service — partikular, ang mga quantum computer, sa pamamagitan ng IBM Quantum Compute Service. Ito ay tinukoy sa pamamagitan ng catalog. Maaari kang magtukoy ng maraming service instance batay sa parehong o iba't ibang plano, na nag-aalok ng access sa iba't ibang quantum computing backend. Tingnan ang Available IBM Cloud plans para sa mga detalye.

Planuhin ang iyong setup

Bago mo i-set up ang IBM Quantum Platform para sa iyong organisasyon, kailangan mong gawin ang mga desisyong ito:

• Paano tinutukoy ang mga pagkakakilanlan ng user? Maaari kang mag-set up ng mga IBM Cloud user, mga user mula sa ibang identity provider (IDP), o pareho.

  • Kung gumagamit ka ng ibang IDP, ang Cloud administrator o ang IDP administrator ba ang nag-aasign ng mga user sa mga access group?

  • Kung ita-assign ng IDP administrator ang mga user sa pamamagitan ng dynamic rules, kakailanganin mo ng custom na IDP user attribute upang gamitin bilang matching key (halimbawa, isang team attribute).

• Ilang service instance ang kailangan mo, at para saan gagamitin ang bawat isa? Planuhin nang mabuti ang mga pangalan ng iyong instance. Tuwing gagawa ka ng service instance sa pamamagitan ng IBM Quantum Platform user interface, ang platform ay gumagawa ng karagdagang tawag sa IAM sa iyong ngalan upang gumawa ng katumbas na access group (na may parehong pangalan ng instance, na may "Collaborators" na idinagdag) na nagbibigay ng write access sa instance na iyon. Kaya, ang mga pangalan ng instance ay nagiging mga pangalan ng access group din. Ang karagdagang hakbang na ito ay nangyayari lamang kapag gumawa ka ng instance sa pamamagitan ng IBM Quantum Platform user interface. Hindi ito nangyayari kung gagawa ka ng instance gamit ang Terraform, ang IBM Cloud CLI, o ang IBM Cloud API.

  • Ang mga workload ay kabilang sa mga service instance, at ang mga user na may access sa isang instance ay makakakita ng mga workload nito.

  • Ang mga service instance ay maaaring nakabatay sa iba't ibang plano, na nagbibigay ng access sa iba't ibang backend at allocations.

• Aling mga user ang kailangan mag-access sa aling mga service instance?

• Dapat bang makapag-delete ng workloads ang mga user? Ang pagpapanatili ng mga workload sa mga service instance ay nagbibigay ng mas maraming traceability para sa mga gastos sa billing.

• Gagamitin mo ba ang access group na awtomatikong nagagawa para sa bawat instance, gagawa ng karagdagang mga access group na sarili mo, direktang mag-a-assign ng access sa indibidwal na mga user, o oorganisahin ang mga instance sa mga resource groups?

  • Ang mga access group ay isang maginhawa at karaniwang paraan ng pagkontrol sa user access sa mga resource ng IBM Cloud. Ang bawat service instance na ginawa mo sa pamamagitan ng IBM Quantum Platform user interface ay mayroon nang sariling "Collaborators" access group. Maaari mong gamitin ang group na iyon as-is, o gumawa ng karagdagang mga access group sa IBM Cloud console upang pangkatin ang mga user ayon sa team o workload (halimbawa, ml at finance) sa isa o higit pang mga instance. Ang bawat access group ay gumagamit ng custom role na nagpapahintulot sa mga user na mag-access ng mga tiyak na service instance o resource groups. Kung hindi mo kailangan ng isang grupo ng mga user na magbahagi ng parehong access, maaari mo ring direktang i-assign ang access sa indibidwal na mga user, nang walang access group.

    • Kung gagamit ka ng dynamic rules batay sa IDP attributes upang i-assign ang mga user sa mga access group, iwasan ang mga attribute value na substring ng isa't isa. Halimbawa, kung gagamitin mo ang ml at chemlab bilang mga attribute value, ang isang rule na tumutugma sa ml ay tutugma rin sa chemlab, na hindi sinasadyang nagbibigay ng mas maraming access kaysa inaasahan. Gumamit ng natatanging mga halaga tulad ng ml at chem-lab, o magdagdag ng mga prefix o suffix upang maiwasan ang hindi sinasadyang substring match.

  • Ang mga resource group ay ginagamit lamang kapag kailangan mong mapanatili ang malinaw na paghihiwalay ng mga service instance. Kapag gumagawa ng service instance mula sa IBM Quantum Platform, maaari mong piliin kung aling resource group ito kabilang (at magdagdag ng tags), ngunit kailangan mong gamitin ang IBM Cloud console upang gumawa o mamahala ng mga resource group. Kung mas maraming service instance ang nilikha sa isang resource group, lahat ng user na may access sa resource group ay awtomatikong makakakita ng mga ito, nang hindi kina-update ang mga access group. Kung pipiliin mong gumamit ng mga resource group, una gumawa ka ng mga access group at pagkatapos ay i-aassign ang mga ito sa mga resource group.

  tala

  Ang isang service instance ay maaaring kabilang sa isang resource group lamang, at hindi na mababago ang assignment na iyon kapag nagawa na ang instance. Kaya naman, ang mga resource group ay maaaring hindi magbigay ng sapat na flexibility kung maaaring kailanganin ng mga service instance na lumipat sa pagitan ng mga resource group sa hinaharap.

Mga konsiderasyon

Dapat mong maunawaan ang mga sumusunod na konsiderasyon kapag nag-set up ng iyong kapaligiran.

Tukuyin ang mas detalyadong mga role

Maaaring gamitin ang mga custom role para sa mas detalyadong access control. Halimbawa, ang ilang user ay maaaring kailangan ng buong access para magtrabaho sa mga service instance, habang ang iba ay maaaring kailangan lamang ng read access sa mga service instance, program, at workload.

Upang makamit iyon, tukuyin ang dalawang iba't ibang custom role, tulad ng MLreader at MLwriter. Alisin ang lahat ng cancel, delete, at update actions mula sa MLreader custom role, at isama ang lahat ng aksyon sa MLwriter custom role. Pagkatapos, idagdag ang mga role sa dalawang iba't ibang access group nang naaayon.

tala

Kapag gumagamit ng mga dynamic rule, iyon ay, kapag ang IDP administrator ay namamahala ng access sa pamamagitan ng mga custom IDP user attribute, huwag gumamit ng mga IDP custom user attribute na mga substring ng isa't isa. Halimbawa, huwag gumamit ng ml at mlReader, dahil ang string comparison ng ml ay tatanggap din ng mlReader. Maaari kang gumamit ng MLreader at MLwriter upang maiwasan ang salungatan na ito.

Para sa isang halimbawa, tingnan ang Set up custom roles.

Access sa shared workload

Ang access ay nalalapat sa mga service instance. Kaya naman, ang mga user na may write access sa isang instance (kabilang ang sa pamamagitan ng "Collaborators" access group na awtomatikong ginagawa para sa mga instance na nilikha ng IBM Quantum Platform user interface) ay maaaring kanselahin ang kanilang sariling mga workload, ngunit maaari rin nilang tingnan at kanselahin ang mga workload ng ibang user sa instance na iyon. Ganito talaga gumagana ang IAM at hindi ito mababago.

Gayahin ang mga hierarchical na istruktura

Bilang default, ang access ng bawat service instance ay pinamamahalaan nang hiwalay, halimbawa, sa pamamagitan ng "Collaborators" access group na awtomatikong ginagawa para sa mga instance na nilikha sa pamamagitan ng IBM Quantum Platform user interface. Walang built-in na hierarchy ng mga grupo ang IAM, ngunit maaari kang gumawa ng katulad nito sa pamamagitan ng paglikha ng mga access group na tumutukoy sa mga service instance ng maraming team. Ang mga user na nangangailangan ng malawak na access ay kailangan lamang idagdag sa isang "top level" na grupo, sa halip na sa bawat indibidwal na access group ng bawat team.

Pare-pareho at paulit-ulit na pag-deploy ng configuration

Ang mga hakbang sa gabay na ito ay maaaring i-automate para sa pare-pareho at paulit-ulit na pamamahala ng mga user, mga service instance, at ang access mappings sa pagitan ng mga ito. Sumangguni sa Terraform IBM Cloud® Provider documentation para sa mga template.

Maaari mong gamitin ang Terraform para itakda ang allocation at mga limitasyon, pati na rin ang paghigpit sa backend access, para sa mga quantum-computing service instance. Tingnan ang Getting started with Terraform on IBM Cloud para sa karagdagang impormasyon.

Halimbawa:

resource "ibm_resource_instance" "instance1" {
  name       = "name"
  service    = "quantum-computing"
  plan       = "premium"
  location   = "us-east"
  parameters = {
    usage_allocation_seconds = "10" # Mandatory
    usage_limit_seconds      = "20" # Optional. If omitted, it can
            # continue using time after reaching the allocation
    backends                 = ["ibm_boston"] # Optional
  }
}

Mga susunod na hakbang

Mga rekomendasyon

• Tingnan ang I-configure ang IBM Quantum Platform para sa isang organisasyon para sa mga hakbang sa pag-set up ng IBM Quantum Platform.
• Unawain ang mga available na plano.
• Lumikha ng mga instance.
• Unawain ang istruktura ng account ng IBM Cloud.
• Lumikha ng mga patakaran at access group.
• Pamahalaan ang mga user.
• Dokumentasyon ng IBM Cloud IAM para sa kumpletong detalye ng IAM.
• Dokumentasyon ng IBM Cloud Enterprise para sa pamamahala ng maraming naka-link na account.