1. Overview
   1. Manages access control by defining WHO can do WHAT on WHICH RESOURCE
   2. WHO = member, Can do what = ROLE, On which resource = RESOURCE
   3. Grants granular access to specific resources
   4. Prevents unwanted access to other resources
   5. Assign only the priviledges essential for performing intended action
   6. Enables the implementation of principle of least priviledge
2. Members
   1. Accounts
      1. Google Account or Cloud Identity user is email address associated with a Google account
      2. Service Account is an account belonging to an application
   2. Cloud Identity Domain
      1. Similar to Google Workplace domain
      2. Represents all Google accounts in an organization
      3. No access to Google Workplace applications
      4. Existing LDAP directory services can sync with Cloud Identity
   3. Google Group
      1. Collection of Google accounts
      2. Represented by email address (googlegroups@company.com)
      3. Enables a single policy to be applied to a group of users
      4. Not used to establish individual identity. Has no credentials
      5. Can include Service Accounts
   4. allAuthenticatedUsers
      1. Special identifier for any GCP account
      2. Not available with every service
      3. Anonymous users are not included
   5. allUsers
      1. A special identifier for all users
      2. Includes anonymous users
      3. Not available with every service
3. Roles
   1. Overview
      1. Represents the WHAT in IAM
      2. Collection of permissions
      3. Roles are assigned to users, which bundles one or more permissions
      4. Permissions not granted directly to users
   2. Primitive
      1. Broad, original Google Cloud role
      2. Applies across entire project
      3. Owner, Editor and Viewer
      4. Owner role includes permissions in Editor role
      5. Editor role includes permissions in Viewer role
      6. Owner can modify all resources, and manage IAM and billing
      7. Editor can modify all resources, no access to IAM and billing
      8. Viewer can view resources, but cannot make changes
   3. Predefined
      1. More granular/specific access, not across entire project
      2. Created and maintained by Google
      3. Automatically updated when features and services are added
      4. Applies to a single service
      5. Aligned to job functions
   4. Custom
      1. More granular than Predefined Roles
      2. Not maintained by Google or updated automatically
      3. Used when predefined roles are not specific enough
   5. Least Priviledge
      1. Apply the minimal access level required
      2. Use predefined roles over primitive roles
      3. Be cautious with Owner roles
4. Resource
   1. Represents the WHICH RESOURCE component
   2. Compute Engine instance, Cloud Storage Bucket etc
   3. Resource includes Organization, Folders, Projects, Services
5. Service Accounts
   1. Overview
      1. Special Google account belonging to an application
      2. Application has no need for user authentication
      3. Authentication is between application and services
      4. Application identified by service account email address
      5. Service accounts are granted permissions to a resource
      6. Users are granted the serviceAccountUser role
      7. Service accounts are both a member, WHO, and a resource, WHAT
   2. Google Managed
      1. Represents different Google services
      2. Automatically granted IAM roles
      3. e.g. PROJECT_NUMBER-compute@cloudservices.gserviceaccount.com
   3. User Managed
      1. Created for/by the user
      2. Based on enabled APIs in project
      3. e.g. PROJECT_NUMBER-compute@developer.gserviceaccount.com
   4. Scopes
      1. Legacy method of granting permissions
      2. Used by instances using default service accounts
      3. Grants per instance permissions to other GCP resources
      4. IAM roles or scopes determines instance permissions
   5. Key
      1. Service account access is governed by keys
      2. Default service account keys are managed by Google
      3. Custom service accounts can use user managed keys
      4. User is responsible for managing key pair
      5. Google maintains a public copy for verification
      6. Private key cannot be retrieved by Google
   6. Recommendations
      1. Rotate user-managed service account keys
      2. Do not delete service accounts in use
      3. Name service accounts to reflect use and permissions
      4. Do not check-in service account keys into source code or leave in download directory
   7. Least Priviledge
      1. When using ServiceAccounts treat each app component as a separate trust boundary
      2. Create a separate service account for each service
      3. Restrict service account access
      4. Restrict who can create and manage service accounts
6. Policies
   1. Policies are needed to grant roles
   2. Collection of statements that defines who has what type of access
   3. Attached to a resource to define access control rules
   4. Expressed by an IAM policy object
   5. IAM policy object consists of a list of bindings
   6. A binding binds a list of members to a role