Lumaktaw sa pangunahing nilalaman

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

Sa isang organisasyon kung saan ang mga indibidwal ay maaaring magtrabaho sa maraming proyekto, ang pamamahala ng IBM Quantum Platform ay maaaring mukhang kumplikado. Gayunpaman, ang access management ay maaaring gamitin para madaling paganahin ang pakikipagtulungan ng mga gumagamit at upang paghigpitan ang visibility ng mga gumagamit at proyekto kung kinakailangan. Nagiging mas mahalaga ang pamamahala ng access sa mga IBM Quantum Platform resource na hindi libre — iyon ay, ang mga service instance na gumagamit ng mga bayad na plano (na sisingilin sa mga organisasyon).

Pangkalahatang-ideya​

tala

Ang IBM Cloud® ay nagbibigay ng iba't ibang paraan upang ipatupad ang mga mekanismong inilarawan sa gabay na ito. Mayroon ding ilang paraan upang makamit ang mga layuning ito. Bukod dito, karamihan sa mga hakbang sa gabay na ito ay pangkalahatang para sa IBM Cloud at hindi partikular sa IBM Quantum Platform, maliban sa mga detalye ng custom role.

Mga taong kasangkot​

Mayroong ilang pangunahing persona na binabanggit sa gabay na ito:

  • User: Isang taong nakakakuha ng access sa mga IBM Quantum Platform resource (service instances) at maaaring makipagtulungan sa ibang mga gumagamit sa mga resource na ito. Ang access ng mga gumagamit 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 mga IBM Quantum Platform resource 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 IBM Quantum Platform service instance.

  • Service instance: Ang isang service instance ay ginagamit para ma-access ang mga Cloud service — partikular, ang mga quantum computer. 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 plan para sa mga detalye.

  • Project: Isang unit ng pagpapangkat na nagbibigay-daan sa mga gumagamit na magtrabaho sa parehong mga resource. Gumagamit ang gabay na ito ng dalawang proyekto: ml at finance. Tingnan ang Mga hierarchical na istruktura ng proyekto para sa karagdagang impormasyon.

    tala

    Ang proyektong ito ay hindi kaugnay sa konsepto ng "project" sa classic na IBM Quantum® Platform.

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 gumagamit? Maaari kang mag-set up ng mga IBM Cloud user, mga gumagamit mula sa ibang IDP, o pareho.

    • Kung gumagamit ka ng ibang IDP, ang Cloud administrator o ang IDP administrator ba ang nag-aasign ng mga gumagamit sa mga project resource?
    • Kung ang IDP administrator ang nag-aasign ng mga gumagamit sa mga proyekto, kailangan mo ng string na gagamitin bilang key, tulad ng project (na ginagamit ng gabay na ito) para sa mga paghahambing ng proyekto.

  • Ano ang mga proyekto at aling mga service instance ang mabibilang sa bawat isa? Kailangan mong maingat na planuhin ang mga pangalan ng proyekto.

    • Huwag gawing substring ng isa ang mga pangalan ng proyekto. Halimbawa, kung gagamitin mo ang ml at chemlab bilang mga pangalan ng proyekto, at mamaya ay mag-set up ka ng project match para sa ml, ito ay mag-ti-trigger sa parehong halaga, na hindi sinasadyang nagbibigay ng mas maraming access kaysa inaasahan. Sa halip, gumamit ng natatanging mga pangalan tulad ng ml at chem-lab. Bilang kahalili, gumamit ng mga prefix o suffix na halaga upang maiwasan ang mga hindi sinasadyang substring match.
    • Ang paggamit ng mga naming convention kasama ang mga prefix o suffix na halaga ay makakatulong sa iyo na madaling payagan ang access sa maraming proyekto.
    • Ang mga quantum experiment (jobs) ay kabilang sa mga service instance, at ang mga gumagamit na may access sa isang instance ay makakakita ng mga job nito.
    • Ang mga service instance ay maaaring nakabatay sa iba't ibang plano, na nagbibigay ng access sa iba't ibang backend.

  • Aling mga gumagamit ang kailangan ng access sa aling mga proyekto?

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

  • Gagamitin mo ba ang mga access group na direktang tumutukoy sa mga IBM Quantum Platform service instance o mag-oorganisa ng mga serbisyo sa mga resource group?

    • Mga access group ay isang maginhawa at karaniwang paraan ng pagkontrol ng access ng gumagamit para sa mga IBM Cloud resource. Ito ay isang simple ngunit makapangyarihang paraan upang pare-parehong italaga ang access ng gumagamit. Lumilikha tayo ng access group para sa bawat proyekto at nagma-map ng mga gumagamit sa mga access group. Gumagamit ang bawat access group ng custom role na nagpapahintulot sa mga gumagamit na ma-access ang mga partikular na service instance o resource group.
    • Mga resource group ay ginagamit lamang kapag kailangan mong mapanatili ang malinaw na paghihiwalay ng mga service instance. Kung mas maraming service instance ang nilikha sa isang resource group, lahat ng gumagamit 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, lilikha ka ng mga access group at pagkatapos ay i-aasign ang mga ito sa mga resource group.
    tala

    Ang isang service instance ay maaaring kabilang sa isang resource group lamang, at pagkatapos na ma-assign ang mga instance sa mga resource group, hindi na ito maaaring baguhin. Nangangahulugan din ito na ang pag-aasign ng resource group ay maaari lamang mangyari sa paglikha ng service instance. Kaya naman, ang mga resource group ay maaaring hindi magbigay ng sapat na flexibility kung ang mga pag-aasign ng mga service instance sa mga resource group ay maaaring kailangang baguhin.

Mga konsiderasyon​

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

Tukuyin ang mas detalyadong mga role​

Ang mga aksyon sa mga custom role ay maaaring gamitin para sa mas detalyadong access control. Halimbawa, ang ilang mga gumagamit 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 job.

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

tala

Kapag gumagamit ng mga dynamic rule, iyon ay, kapag ang identity provider (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 ng pag-set up ng mga custom role, tingnan ang Lumikha ng mga access group para sa mga proyekto.

Access sa shared workload​

Mahalagang tandaan na ang access ay nalalapat sa mga service instance. Kaya naman, ang mga gumagamit na may 'write' access sa isang instance ay maaaring kanselahin ang kanilang sariling mga workload, ngunit maaari rin nilang tingnan at kanselahin ang mga workload ng ibang gumagamit. Ito ay isang function ng kung paano gumagana ang IAM at hindi maaaring baguhin.

Iba pang Cloud resource​

Ang mga hakbang sa gabay na ito ay maaari ding gamitin upang pamahalaan ang access sa iba pang mga Cloud resource. Isama ang naaangkop na mga pahintulot sa mga access group ng mga kaugnay na proyekto.

Mga hierarchical na istruktura ng proyekto​

Sa gabay na ito, ang pag-map ng mga gumagamit sa mga proyekto at service instance ay pinananatiling simple. Gayunpaman, sa pamamagitan ng pag-uugnay ng maraming gumagamit sa mga access group at pagtukoy sa mga service instance mula sa maraming access group, maaaring maipatupad ang mas kumplikadong mga pag-map.

Ang pamamaraang ito ay maaaring mag-accommodate ng isang hierarchical na istruktura. Iyon ay, maaari itong iayon sa kung paano maaaring italaga ang mga gumagamit sa Hub/Group/Project access structure sa classic na bersyon ng IBM Quantum® Platform. Halimbawa, ang isang group ay maaaring maging isang access group na itinalaga sa lahat ng service instance ng mga proyekto ng grupo. Ang mga gumagamit na dapat makakuha ng access sa lahat ng proyekto ng grupo ay kailangan lamang na idagdag sa access group ng grupo.

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

Ang mga hakbang ng gabay na ito ay maaaring i-automate para sa pare-pareho at paulit-ulit na pamamahala ng mga gumagamit, proyekto, at ang pag-map sa pagitan ng mga ito. Sumangguni sa Terraform IBM Cloud® Provider documentation para sa mga template.

Mga susunod na hakbang​

Mga rekomendasyon