Cloud Authentication and Authorization

In GCP we manage authorization and authentication via the (Identity Access and Management) IAM system. This should work similarly for most cloud providers.

Model

GCP has resources, like buckets, Pubsub subscription topics, BigQuery, etc. You can do various things with these resources, i.e. you can read items off a bucket or put items in a bucket.

Some people, applications, etc. may need to do some things and not others. So we can manage that with IAM.

• Permission. This is a "thing you can do", like read a file on a bucket, etc. You generally don't deal with these directly. Instead, you group these into roles.
• Role. This is a collection of "things you can do" to or with a cloud resource, i.e. permissions. You could have a "Bucket RW" role that lets you read and write items to a bucket, but also an admin role that gives you permission to read/write/delete. A CSP will often have a bunch of canned roles for you to use, but you can generally make your own.
• Principal or Members or Accounts. These are like "people", but they can also be applications or machines. In the past, I used to think of these as "users", but the concept is a bit broader than that and includes things like apps, etc.

What is a Service Account?

A Service account is a special type of principal (in the past we called these "users") that we use to access resources on behalf of a application. In the past, I used to call these "application users", but "service account" appears to be the new way of referring to this concept.

When you want an application to interact with a bucket, for example, you generally have to:

• create a service account for that application.
• add roles to that service account (not permissions). Roles carry the permission with them.