0

In Google Cloud, when I create a service account, I give it roles to access certain APIs. Then later, when I load credentials for that service account, I specify scopes for the APIs it will use. Often, the roles given at account creation time are similar to the scopes specified at credential loading time. For example, I might create a service account with permission to access cloud storage and pub/sub, then specify scopes for, again, cloud storage and pub/sub.

Why, conceptually, is it like this? Specifically, what is the design goal for having to update both roles and scopes when I give my service account access to a new API?

(FWIW it's no problem for me to update both roles and scopes in this way, and I'm not really looking for a workaround, I'm just interested in why things are this way.)

I found some previous questions related to this but none really satisfied my curiosity about why things are set up this way

Alex Flint
  • 6,040
  • 8
  • 41
  • 80
  • I am not sure why one needs to work with scopes or keys (for service accounts) for accessing/using APIs within the GCP context. For example, if a service account is created (in GCP), and some IAM roles are granted/bound - i.e. to work with cloud storage buckets or pubsub topics - I've never come across any necessity to mess with scopes or keys. Everything worked smoothly, and IAM roles were enough in my experience. – al-dann Aug 19 '23 at 11:56
  • User and service accounts are virtually the same regarding granting of permissions. Think of an identity (user or service account) as a bucket. You grant Cloud IAM roles to that identity (fill the bucket with permissions). Scopes can not add permissions to that bucket of permissions. Scopes select which permissions you want to use from the bucket with the generated token. If you use scopes that request permissions that are not in the bucket, the generated token will not have those permissions. The final arbiter of permissions is Cloud IAM. Scopes select a subset of those permissions. – John Hanley Aug 19 '23 at 15:03
  • @JohnHanley Thanks, this makes sense, but what actually is the purpose of having two different ways to narrow permissions? Why not just set roles on your service account in one place? Are there really use cases where one would want/need to create a service account with some set of permissions, and then only make use of a subset of those? I'm sure there is a good reason; this is just my personal curiosity! – Alex Flint Aug 20 '23 at 13:29
  • 1
    Using OAuth Scopes for permissions is a legacy mechanism. They existed before Cloud IAM. Google also has many APIs which are not part of Google Cloud that still use scopes to request permissions (they are not managed by Cloud IAM). In Google Cloud, I recommend only using the scope `cloud-platform` and relying on Cloud IAM for access control. – John Hanley Aug 20 '23 at 14:22

0 Answers0