De ce au ales jetoane ID OIDC pentru service-to-service
comunicare? Am folosit OIDC o tonă pe partea utilizatorului, dar niciodată pe partea
server la partea de server. Așadar, obținerea unui ID Token pentru server la server
comunicarea pare foarte ciudată. Mi-ar plăcea un link către puncte către
documente care explică această alegere de arhitectură de la server la server
lateral.. M-aș fi așteptat la un token de acces OAuth2 cu client
Acreditări pentru toate comunicările de la serviciu la serviciu, nu un simbol ID.
În Google Cloud, există două tipuri de autorizare. Bazat pe rol (Token de acces OAuth) și bazat pe identitate (Jeton de identitate OIDC). Autorizarea bazată pe roluri oferă acces la toate resursele bazate pe roluri. De exemplu, accesul spectatorului la toate instanțele Compute Engine. Acest tip de permisiune este gestionat la nivel de proiect/dosar/organizație. Autorizarea bazată pe identitate oferă acces la o resursă individuală. Diferența cheie este locul în care se atribuie permisiunea/rolul: la nivel de proiect sau la nivel de resursă. Deoarece un rol este prea larg de permisiuni la nivel de resursă, aveți nevoie de o altă cale.Așa sunt identitățile. acord Ioan acces la cheia KMS secret2. Identitatea + permisiunile sunt stocate la nivelul de gestionare a accesului la chei KMS.
De ce este arbitrar câmpul Public? În Cloud Scheduler, acesta
se pare că atâta timp cât folosesc un cont de serviciu valid în proiect,
Pot pune vreo valoare în domeniul audienței? Sunt sigur că există un motiv
pentru asta, oamenii Google sunt inteligenți, dar asta se simte ca o gaură de securitate.
Adică, publicul ar putea fi orice adresă URL validă (mai bine pot spune). Pot sa
plasați o audiență a unui punct final Cloud Run într-un proiect diferit și creați
apelul acela?
Dacă codul dvs. creează Jetonul de identitate, public este necesară. Există anumite ID-uri de client OAuth gestionate de Google care permit ignorarea publicului. Deoarece identitatea și permisiunile sunt stocate la resursă, apelarea unui alt punct final Cloud Run nu va trece de verificarea identității. IMHO, câmpul audiență este o metodă rapidă pentru ca un sistem de identitate să verifice mai întâi dacă Identity Token ar trebui să fie aprobat pentru stratul IAM.
Evident, aici există o divizare între AuthN și AuthZ, deci
id_token este mai mult despre authN, dar un câmp de audiență validat pe
cererea jetonului ar indica Authz solid. DAR cu ea fiind
arbitrar, simt că nu se poate avea încredere în validarea audienței
pentru că oricine poate pune orice acolo. Te rog spune-mi ce sunt
dispărut.
Jetoanele de identitate sunt semnate. Numai serviciile și codul autorizat pot crea jetoane de identitate. După cum am menționat în punctul meu anterior, publicul nu oferă permisiunea și nici nu acordă acces. Este un pas într-un strat de pași pentru a autoriza accesul pe baza simbolului de identitate. Validarea finală este identitatea + permisiunea atribuite la resursă. Publicul nu acordă niciunul dintre acestea, dar poate fi folosit ca un filtru pentru a elimina rapid jetoanele.
