When creating a new service account what does Google Cloud use to create a Google managed key pair?

• Google Cloud Identity and Access Management – IAM lets administrators authorize who can take what action on which resources
• IAM provides a unified view into security policy across the entire organization, with built-in auditing to ease compliance processes.

IAM manages access control by defining who (identity) has what access (role) for which resource

Member

• A member can be a Google Account (for end users), a service account (for apps and virtual machines), a Google group, or a Google Workspace or Cloud Identity domain that can access a resource.
• Identity of a member is an email address associated with a user, service account, or Google group; or a domain name associated with Google Workspace or Cloud Identity domains.

Role

• Permission to access a resource isn’t granted directly to the end user
• A role is a collection of permissions and is granted to authenticated members
• Permissions are represented in the form service.resource.verb for e.g. compute.instances.list
• Permissions determine what operations are allowed on a resource.
• Role granted to a member grants all the permissions that the role contains
• GCP supports different role types
  • Basic or Primitive roles
    • Roles historically available in the Google Cloud Console. Also, referred to as primitive roles
    • Roles are Owner, Editor, and Viewer.
    • Provide board level of permissions and not recommended
  • Predefined roles
    • Roles that give fine-grained granular access control
    • Roles are created and maintained by Google and automatically updated as necessary, such as when Google Cloud adds new features or services.
  • Custom roles
    • Roles created to tailor permissions to the needs of the organization, when predefined roles don’t meet the needs.
    • Custom roles are not maintained by Google; when new permissions, features, or services are added to Google Cloud, the custom roles will not be updated automatically.

IAM Policy

• IAM policy binds one or more members to a role.
• An IAM policy defines and enforces what roles are granted to which members, and this policy is attached to a resource.
• IAM policy attached to the resource defines who (member) has what type of access (role) on the resource
• IAM policy can be set at any level in the resource hierarchy:  organization level,  folder level, project level, or resource level.
• IAM Policy inheritance is transitive and resources inherit the policies of all of their parent resources.
• The effective policy for a resource is the union of the policy set on that resource and the policies inherited from higher up in the hierarchy.
• Basically  Permissions -> Roles -> (IAM Policy) -> Members
• When an authenticated member attempts to access a resource, IAM checks the resource’s policy to determine whether the action is permitted.

Service Accounts

• A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.
• Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as Google Workspace or Cloud Identity users through domain-wide delegation.
• is identified by its email address, which is unique to the account.
• does not have passwords, and cannot log in via browsers or cookies.
• are associated with private/public RSA key-pairs that are used for authentication to Google.
• Other users or service accounts cannot impersonate a service account.
• are not members of the Google Workspace domain, unlike user accounts.
• users need to be granted serviceAccountUser role to be able to use service accounts
• are both a member (who) and a resource (what)
  • Services accounts are granted permissions to a resource (what)
  • Users are granted the serviceAccountUser role (who)
• Service accounts are used in scenarios such as:
  • Running workloads on virtual machines (VMs).
  • Running workloads on on-premises workstations or data centers that call Google APIs.
  • Running workloads which are not tied to the lifecycle of a human user.
• Service Account Keys
  • Each service account is associated with two sets of public/private RSA key pairs that are used to authenticate to Google:
  • Google-managed keys
    • Google-managed key pairs imply that Google stores both the public and private portion of the key, rotates them regularly (each key can be used for signing a maximum of two weeks), and the private key is always held in escrow and is never directly accessible.
    • IAM provides APIs to use these keys to sign on behalf of the service account.
  • User-managed keys.
    • User-managed key pairs imply that you own both the public and private portions of a key pair.
    • User-managed key pairs (also known as “external” keys) can be created and used from outside of Google Cloud.
    • Google only stores the public portion of a user-managed key.
    • The creator is  responsible for the security of the private key and other management operations such as key rotation
• Service Account Types
  • Default service accounts
    • Google Cloud creates user-managed service accounts when you enable or use some Google Cloud services that enable the service to deploy jobs that access other Google Cloud resources.
    • For applications running in a Google Cloud environment that has a default service account, the application can use the credentials for the default service account to call Google Cloud APIs.
  • User-managed service accounts
    • User-managed service accounts are created in the project using the IAM API, the Cloud Console, or the gcloud command-line tool.
    • Creator is responsible for managing and securing these accounts
• Service Account Permissions
  • Service account permissions are controlled by IAM roles and Access Scopes
    • IAM Roles
      • restricts access to APIs based on the IAM roles that are granted to the service account.
      • are account-specific
    • Access scopes
      • potentially further limit access to API methods when authenticating through OAuth
      • apply on a per-instance basis
      • only apply for the default service accounts
      • are the legacy method of specifying permissions for the instance
  • Best practice is to set the full cloud-platform access scope on the instance, then securely limit the service account’s access using IAM roles
• Service Account, if accidentally deleted, can be recovered if the time gap is less than 30 days and a service account by the same name wasn’t created

IAM User vs Service Account Decision Tree

Workload Identity Federation

• Using identity federation, on-premises or multi-cloud workloads can be granted access to GCP resources, without using a service account key.
• Identity federation can be used with AWS, or with any identity provider that supports OpenID Connect (OIDC), such as Microsoft Azure
• With identity federation, IAM can be used to grant external identities IAM roles, including the ability to impersonate service accounts using short-lived access tokens, and eliminates the maintenance and security burden associated with service account keys.

IAM Best Practices

• IAM focuses on who, providing the ability to authorize users and groups to take action on specific resources based on permissions.
• Use Predefined over primitive roles
  • provide granular access and roles at the smallest scope to users to control what they can access
• Control access to resources
  • enforce the principle of least privilege by ensuring that members have only the permissions that they actually need.
• Delegate responsibility with groups and service accounts
  • use groups for users requiring the same responsibilities and assigning IAM roles to the groups rather than to individual users
  • use service accounts for server-to-server interactions.
  • rotate service account keys for user-managed service accounts
• Understand IAM Policy Inheritance
  • a child resource cannot restrict access granted on its parent
• Define an Organization Policy
  • Use Organization Policy Service to get centralized and programmatic control over the organization’s cloud resources.
  • An organization policy focuses on what, providing the ability to set restrictions on specific resources to determine how they can be configured and used
  • All descendants of a resource inherit its policies by default.
  • A base set of constraints can be defined that apply to all elements in the hierarchy by attaching a policy to the top-level Organization node.
  • Custom organization policies can be set on child nodes, which overwrite or merge with the inherited policy.
• Federate identity provider with Google Cloud
  • for an organization using an on-premises or third-party identity provider, synchronize the user directory with Cloud Identity to let users access Google Cloud with their corporate credentials.
  • identity platform remains the source of truth while Cloud Identity controls how the employees access Google services.

IAM Recommender

• IAM recommender helps enforce the principle of least privilege by ensuring that members have only the permissions that they actually need.
• IAM uses Recommender to compare project-level role grants with the permissions that each member used during the past 90 days.
• Depending on the usage of the member and permissions provided, IAM recommender recommends a less permissive role or to revoke the role.
• IAM recommender never suggests a change that increases a member’s level of access.
• IAM recommender also uses machine learning to identify permissions in a member’s current role that the member is likely to need in the future, even if the member did not use those permissions in the past 90 days.
• IAM recommender does not apply recommendations automatically, but the recommendations should be reviewed and then applied or dismissed.
• IAM recommender does not evaluate
  • Role grants made at the folder or organization level
  • Role grants made below the project level; that is, role grants on service-specific resources within a project
  • Conditional role grants
  • Role grants for Google-managed service accounts
  • Access controls that are separate from IAM

IAM Audit Logging

• Google Cloud services write audit logs to help answer the questions, “Who did what, where, and when?”
• Cloud projects contain only the audit logs for resources that are directly within the project. Other entities, such as folders, organizations, and Cloud Billing accounts, contain the audit logs for the entity itself.
• IAM writes Admin Activity audit logs, which record operations that modify the configuration or metadata of a resource. Admin Activity audit logs cannot be disabled
• IAM writes Data Access audit logs if explicitly enabled. Data Access audit logs contain API calls that read the configuration or metadata of resources, as well as user-driven API calls that create, modify, or read user-provided resource data.
• IAM doesn’t write System Event audit logs.
• IAM doesn’t write Policy Denied audit logs.
• Cloud Audit Logs provides the following audit logs for each Cloud project, folder, and organization:
  • Admin Activity audit logs
  • Data Access audit logs
  • System Event audit logs
  • Policy Denied audit logs
• IAM Audit Logs can be exported to Cloud Storage for long term retention

GCP Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. You built an application on your development laptop that uses Google Cloud services. Your application uses Application Default Credentials for authentication and works fine on your development laptop. You want to migrate this application to a Compute Engine virtual machine (VM) and set up authentication using Google-recommended practices and minimal changes. What should you do?
   1. Assign appropriate access for Google services to the service account used by the Compute Engine VM.
   2. Create a service account with appropriate access for Google services, and configure the application to use this account.
   3. Store credentials for service accounts with appropriate access for Google services in a config file, and deploy this config file with your application.
   4. Store credentials for your user account with appropriate access for Google services in a config file, and deploy this config file with your application.
2. You need to set up permissions for a set of Compute Engine instances to enable them to write data into a particular Cloud Storage bucket. What should you do following Google-recommended practices?
   1. Create a service account with an access scope. Use the access scope //www.googleapis.com/auth/devstorage.write_o….
   2. Create a service account with an access scope. Use the access scope //www.googleapis.com/auth/cloud-platform.
   3. Create a service account and add it to the IAM role storage.objectCreator for that bucket.
   4. Create a service account and add it to the IAM role storage.objectAdmin for that bucket.

References

Google_Cloud_IAM