Considerații pentru configurarea IBM Quantum Platform într-o organizație

Într-o organizație în care persoanele pot lucra pe mai multe proiecte, guvernanța IBM Quantum Platform poate părea complexă. Cu toate acestea, gestionarea accesului poate fi utilizată pentru a facilita colaborarea utilizatorilor și pentru a restricționa vizibilitatea utilizatorilor și a proiectelor atunci când este necesar. Gestionarea accesului devine mai relevantă în cazul resurselor IBM Quantum Platform care nu sunt gratuite - adică instanțe de serviciu care utilizează planuri plătite (pentru care organizațiile sunt taxate).

Prezentare generală

notă

IBM Cloud® oferă diverse modalități de implementare a mecanismelor descrise în acest ghid. Există mai multe moduri de a atinge aceste obiective. În plus, majoritatea pașilor din acest ghid sunt generici pentru IBM Cloud și nu sunt specifici IBM Quantum Platform, cu excepția detaliilor privind rolurile personalizate.

Persoane implicate

Există mai multe persoane principale menționate în acest ghid:

• Utilizator: Cineva care obține acces la resursele IBM Quantum Platform (instanțe de serviciu) și poate colabora cu alți utilizatori pe aceste resurse. Accesul utilizatorilor este controlat de un administrator, iar aceștia nu pot crea sau șterge instanțe de serviciu.
• Administrator Cloud: Un proprietar de cont IBM Cloud care deține resurse IBM Quantum Platform și gestionează ce utilizatori pot accesa aceste resurse. Ca proprietar al resurselor, administratorul este taxat pentru orice utilizare a resurselor plătite.
• Administrator IDP: Un administrator care definește identitățile și atributele acestora într-un furnizor de identitate (IDP).

Terminologie

Acest ghid utilizează următorii termeni:

• Resursă: Un termen generic IBM Cloud care se referă la un obiect ce poate fi gestionat prin interfața utilizator Cloud, CLI sau API. În acest ghid, o resursă este o instanță de serviciu IBM Quantum Platform.

• Instanță de serviciu: O instanță de serviciu este utilizată pentru accesarea serviciilor Cloud - mai precis, a calculatoarelor cuantice. Este definită prin catalog. Poți defini mai multe instanțe de serviciu bazate pe planuri identice sau diferite, care oferă acces la Backend-uri diferite de calcul cuantic. Consultă Planul IBM Cloud disponibil pentru detalii.

• Proiect: O unitate de grupare care permite utilizatorilor să lucreze pe aceleași resurse. Acest ghid folosește două proiecte: ml și finance. Consultă Structuri ierarhice de proiecte pentru mai multe informații.

  notă

  Acest proiect nu are legătură cu conceptul de „proiect" din platforma clasică IBM Quantum® Platform.

Planifică-ți configurarea

Înainte de a configura IBM Quantum Platform pentru organizația ta, trebuie să iei aceste decizii:

• Cum sunt definite identitățile utilizatorilor? Poți configura utilizatori IBM Cloud, utilizatori dintr-un alt IDP sau ambele.

  • Dacă folosești un alt IDP, administratorul Cloud sau administratorul IDP atribuie utilizatorii resurselor de proiect?
  • Dacă administratorul IDP atribuie utilizatorii proiectelor, ai nevoie de un șir care să fie folosit ca cheie, cum ar fi project (pe care îl folosește acest ghid) pentru comparații de proiecte.

• Care sunt proiectele și ce instanțe de serviciu vor aparține fiecăruia? Trebuie să planifici cu atenție numele proiectelor.

  • Nu face ca numele proiectelor să fie subșiruri ale altuia. De exemplu, dacă folosești ml și chemlab ca nume de proiecte, iar mai târziu configurezi o potrivire pentru ml, aceasta se va declanșa pentru ambele valori, acordând accidental mai mult acces decât era prevăzut. În schimb, folosește nume unice precum ml și chem-lab. Alternativ, folosește valori de prefix sau sufix pentru a evita astfel de potriviri neintenționate de subșiruri.
  • Utilizarea convențiilor de denumire împreună cu valori de prefix sau sufix te poate ajuta să permiți cu ușurință accesul la mai multe proiecte.
  • Experimentele cuantice (job-urile) aparțin instanțelor de serviciu, iar utilizatorii care au acces la o instanță pot vedea job-urile acesteia.
  • Instanțele de serviciu pot fi bazate pe planuri diferite, permițând accesul la Backend-uri diferite.

• Ce utilizatori trebuie să acceseze ce proiecte?

• Ar trebui utilizatorii să poată șterge job-uri? Păstrarea job-urilor în instanțele de serviciu oferă mai multă trasabilitate pentru costurile de facturare.

• Vei folosi grupuri de acces care referențiază direct instanțele de serviciu IBM Quantum Platform sau vei organiza serviciile în grupuri de resurse?

  • Grupurile de acces sunt o modalitate convenabilă și comună de a controla accesul utilizatorilor la resursele IBM Cloud. Ele reprezintă un mijloc simplu, dar puternic de a atribui în mod consecvent accesul utilizatorilor. Creăm un grup de acces pentru fiecare proiect și mapăm utilizatorii la grupurile de acces. Fiecare grup de acces folosește un rol personalizat care permite utilizatorilor să acceseze instanțe de serviciu sau grupuri de resurse specifice.
  • Grupurile de resurse sunt utilizate doar atunci când trebuie să menții o separare clară a instanțelor de serviciu. Dacă se creează mai multe instanțe de serviciu într-un grup de resurse, toți utilizatorii care au acces la grupul de resurse le văd automat fără a actualiza grupurile de acces. Dacă alegi să folosești grupuri de resurse, vei crea grupuri de acces și le vei atribui ulterior grupurilor de resurse.
  notă

  O instanță de serviciu poate aparține unui singur grup de resurse, iar după ce instanțele sunt atribuite grupurilor de resurse, acestea nu pot fi modificate. Asta înseamnă, de asemenea, că atribuirea grupului de resurse poate avea loc doar la crearea instanței de serviciu. Prin urmare, grupurile de resurse ar putea să nu ofere suficientă flexibilitate dacă atribuirile instanțelor de serviciu la grupurile de resurse ar putea necesita modificări.

Considerații

Ar trebui să înțelegi următoarele considerații atunci când îți configurezi mediul.

Definește roluri mai granulare

Acțiunile din rolurile personalizate pot fi utilizate pentru un control de acces mai granular. De exemplu, unii utilizatori ar putea necesita acces complet pentru a lucra pe instanțele de serviciu, în timp ce alții ar putea necesita doar acces de Citire la instanțele de serviciu, programe și job-uri.

Pentru a realiza acest lucru, definește două roluri personalizate diferite, cum ar fi MLreader și MLwriter. Elimină toate rolurile de anulare, ștergere și actualizare din rolul personalizat MLreader și include toate acțiunile în rolul personalizat MLwriter. Apoi, adaugă rolurile la două grupuri de acces diferite în mod corespunzător.

notă

Când folosești reguli dinamice, adică atunci când administratorul furnizorului de identitate (IDP) gestionează accesul prin atribute personalizate ale utilizatorului IDP, nu folosi atribute personalizate ale utilizatorului IDP care sunt subșiruri unele ale altora. De exemplu, nu folosi ml și mlReader, deoarece comparația de șiruri pentru ml ar accepta și mlReader. Ai putea folosi MLreader și MLwriter pentru a evita acest conflict.

Pentru un exemplu de configurare a rolurilor personalizate, consultă Crearea grupurilor de acces pentru proiecte.

Acces partajat la sarcini de lucru

Este important de reținut că accesul se aplică instanțelor de serviciu. Astfel, utilizatorii cu acces de „scriere" la o instanță pot anula propriile sarcini de lucru, dar pot, de asemenea, vizualiza și anula sarcinile de lucru ale altor utilizatori. Aceasta este o funcție a modului în care funcționează IAM și nu poate fi modificată.

Alte resurse Cloud

Pașii din acest ghid pot fi utilizați și pentru a gestiona accesul la alte resurse Cloud. Include permisiunile corespunzătoare în grupurile de acces ale proiectelor relevante.

Structuri ierarhice de proiecte

În acest ghid, maparea utilizatorilor la proiecte și instanțe de serviciu a fost menținută simplă. Cu toate acestea, prin asocierea mai multor utilizatori cu grupuri de acces și referențierea instanțelor de serviciu din mai multe grupuri de acces, pot fi implementate mapări mai complexe.

Această metodă poate acomoda o structură ierarhică. Adică, se poate alinia la modul în care utilizatorii ar putea fi atribuiți structurii de acces Hub/Group/Project în versiunea clasică a IBM Quantum® Platform. De exemplu, un grup ar putea fi un grup de acces atribuit tuturor instanțelor de serviciu ale proiectelor grupului. Utilizatorii care ar trebui să aibă acces la toate proiectele grupului ar trebui doar să fie adăugați la grupul de acces al grupului.

Implementare consecventă și repetabilă a configurației

Pașii din acest ghid pot fi automatizați pentru o gestionare consecventă și repetabilă a utilizatorilor, proiectelor și a mapării dintre acestea. Consultă documentația Terraform IBM Cloud® Provider pentru șabloane.

Pași următori

Recomandări

• Consultă Configurarea IBM Quantum Platform pentru o organizație pentru pașii de configurare a IBM Quantum Platform.
• Înțelege planurile disponibile.
• Creează instanțe.
• Înțelege structura IBM Cloud.
• Creează politici și grupuri de acces.
• Gestionează utilizatorii.