Cloud IAM

Identity Access Management

• It is a way of identifying who can do what on each resource
• Example: read only access to get and read read-only resources

IAM Resource Hierarchy

• Organization: represents our company
  • Folder: could represent a department, permissions assigned to folders are inherited by all resources the folder contains
    • Projects: represent trust boundary in the company
      • Resources

Organization Node

• Root node of the IAM hierarchy
• Organization roles:
  • Organization Admin: control over all cloud resources, useful for auditing
  • Project creator: controls project creation, control over who can create projects
• Organization resource is closely associated with G Suite or Cloud Identity account
• When an user with a G Suite or Cloud Identity account creates GCP project an organization resource is automatically provisioned to them
• Workspace or Cloud Identity super administrator responsibilities are:
  • Assign the Organization admin role to some users
  • Point of contact in case of recovery issues
  • Control the lifecycle of the Workspace or Cloud Identity account and Organization resource
• Organization admin responsibilities:
  • Define IAM roles
  • Determine the structure of the resource hierarchy
  • Delegate responsibilities over critical components such as Networking, Billing and Resource Hierarchy through IAM roles
• Folders:
  • Provide additional grouping mechanism and isolation boundaries between projects (example: departments)
  • Folders allow delegation of administration rights
  • Folders can contain projects and other projects

Resource Manager Roles

• Organization:
  • Admin
  • Viewer
• Folder:
  • Admin
  • Creator: browser hierarchy and create folders
  • Viewer: view folders and projects bellow a resource
• Project:
  • Creator: create new projects (automatic owner) and migrate new projects into the organization
  • Deleter: delete projects

Roles

• There are 3 types of roles:
  • Basic roles: fixed, coarse grained level of access
    • Example of basic roles:
      • Owner:
        • Invite members
        • Remove members
        • Delete projects
        • All Editor and Viewer permissions
      • Editor:
        • Deploy applications
        • Modify code
        • Configure services
        • All Viewer permissions
      • Viewer:
        • Read-only access
      • Billing Administrator:
        • Manage billing
        • Add/remove administrators
  • IAM predefined roles:
    • Roles that apply to a predefined GCP service in a project
    • Collection of permissions, example InstanceAdmin role providing all the compute permissions
    • Examples of predefined roles:
      • Compute Admin: full control of compute engine resource
      • Network Admin: permissions to create, modify and delete networking resources, except for firewall rules and SSL certificates
      • Storage Admin: permissions to create, modify and delete disks, images and snapshots
  • Custom roles:
    • Let us define a precise set of permissions

Members

• There are 5 different types of members:
  • Google Accounts: human users
  • Service Accounts: accounts for services
  • Google Groups: named collection of google accounts and service accounts
  • Google Workspace domain: virtual group of all the Google accounts created in an organization’s workspace accounts
  • Cloud Identity: customers who are not workspace customers

IAM policies

• A policy consists of a list of bindings
• A binding binds a lost of members to a role
• A role is a named of list o permissions defined by IAM
• Child policies can not restrict access granted at the parent level

IAM Conditions

• Allows us to enforce conditional, attribute based control for Google Cloud resources
• We can grant resources access to identities (members) only if configured conditions are met
• IAM conditions are specified in the role bindings of a resource’s IAM policy

Organization Policies

• It is a configuration of restrictions
• It is defined by configuring a constraint with desired restrictions for the organization
• It is applied to the organization node, folders or projects

Google Cloud Single Sign-On (SSO)

• We can use Cloud Identity to configure SAML and SSO
• If SAML2 isn’t supported, we can use a third-party solution such as ADFS, Ping or Okta

Service Accounts

• Service Accounts provide an identity for carrying out server-to-server interactions
• Programs running within Compute Engine instances can automatically acquire access tokens with credentials
• Tokens are used to access any service API in our project and any other services that grant access to the service account
• Service accounts are convenient when we are not accessing user data
• Service accounts are identified by an email address
• There are 3 types of service accounts:
  • User created (custom)
  • Built-in:
    • Compute Engine and App Engine default service accounts
  • Google APIs service accounts:
    • Runs internal Google processes on our behalf
• Default Compute Engine service account:
  • It is automatically created per project with auto-generated name and email address
  • It is automatically added as a project Editor
  • By default, it is enabled on all instances created using gcloud Cloud Console
• There are 2 types of Google Service accounts:
  • Google-managed service accounts:
    • All service accounts have Google-managed keys
    • Google stores both the public and private portion of the key
    • Each public key can be used for signing for a maximum of 2 weeks
    • Private keys are never directly accessible
  • User-managed service accounts:
    • Google only stores the public portion of a user-managed key
    • Users are responsible for private key security
    • We can create up to 10 user-managed service account keys per service
    • Can be administered via the IAM API, gcloud or the Console

IAM Best Practices

• Leverage and understand the resource hierarchy
• Use projects to group resources that share the same trust boundary
• Check the policy granted on each resource and make sure we understand hierarchy
• Use the principle of least privilege when granting roles
• Audit policies in Cloud Audit Logs
• Audit membership of groups used in policies
• Grant roles to Google groups instead of individuals
• Service accounts best practices:
  • We need to be careful when granting serviceAccountUser role
  • When we create a service account, we should give it a display name that clearly identifies its purpose
  • We should establish key rotation policies and methods
  • We can audit service accounts with serviceAccount.key.lists() method
• Use Identity-Aware Proxy (IAP)