Google Cloud Platform for AWS Professionals: Management

Updated March 17, 2017

Compare the management services that Amazon and Google provide in their respective cloud environments. If you're already familiar with the Amazon Web Services (AWS) implementation of identity and access management (IAM), this article provides you with a comprehensive introduction to Google Cloud Identity and Access Management.

Google Cloud Platform (GCP) and AWS offer similar IAM solutions. You can use these tools to create and manage permissions for cloud resources, including for data and applications.

Both AWS and GCP enable you to grant permissions to users, groups, and applications. These permissions let the granted entity have clearly defined access to your cloud resources.

The following table provides a general mapping of AWS terms and concepts to their GCP equivalents.

Concept AWS GCP
Programmatic identity IAM role and instance profile Cloud IAM service account
User identity Managed in IAM. Identity federated to external identity management system. Managed outside Cloud IAM. Identity federated to external identity management system.
Policy A document that explicitly lists permissions. A list of bindings. A binding binds a list of members to a role.
Policy attachment Policy attached to an IAM user or group or a resource. Policy attached to resource.

Policy evaluation Deny by default. Deny by default.
Permission collection Policy Role
Predefined set of permissions Managed policies Predefined roles
Auditing IAM calls AWS CloudTrail Audit logging
Versioning Yes No

Resource management and encapsulation

This section helps you understand how each cloud provider manages resources.

Multiple accounts in AWS

With AWS, the best practice is to set up multiple accounts for each team. You can then assign permissions and policies under each account. You can reduce the complexity of managing multiple AWS accounts by setting up consolidated billing and implementing AWS Organizations.

Organizing projects and policies in GCP

GCP provides container resources, such as organizations, folders, and projects, that let you group and hierarchically organize other GCP resources, such as Cloud Pub/Sub topics and Compute Engine virtual machine instances (VMs). This hierarchical organization lets you manage common aspects of your resources, such as access control and configuration settings.

All GCP resources belong to a project resource, and an individual Google Account can manage multiple projects. You can manage the projects individually. You can group similar or related projects into folders and manage them from there. Furthermore, you can manage both folders and projects under an organization resource.

The following diagram shows an example of various resources and their hierarchical organization in GCP.

Example of a GCP resource hierarchy.

Policy inheritance

With AWS, you can specify resource-based permissions, which apply directly to resources, or you can specify permissions for specific actions that can be performed against a given resource. Which way the permissions can be specified depends on the service.

GCP's IAM policy inheritance is complemented by its resource organization. In GCP, resources are organized hierarchically, so you can set IAM policies that flow from the organization node downwards. If you want to have organization-wide IAM policies, you can assign those polices on the organization resource. If you want to set policies across multiple teams and projects, you can use GCPfolders to do so. You can then assign permissions at the project level, and finally at the resource level within the project for a more granular level of control.

Identities

Identities used to access cloud resources break down into two groupings:

  • End-user identities, represented by their usual corporate logins. In the case of AWS, end users can also be represented by using IAM accounts.
  • Programmatic identities, which enable application code to access cloud resources.

End-users identities in AWS

AWS manages the root account that is a requirement for every account created. AWS provides a list of best practices to help protect your AWS account's root access keys.

To allow access to your AWS resources, you can set up IAM users, which are identities created within AWS, or you can set up federation from your corporate directory. You can use a third-party identity provider. When configuring a third-party identity provider to use with AWS, you need to create an IAM role and then define permissions for the role. When a federated user signs in to AWS, the user is associated with the role and is granted the permissions that are defined in the role.

End-user access in GCP

With GCP, you have two main options for assigning project ownership:

  • You can create a project with one or more owners who have full access to the project's resources.
  • You can have projects that don't have an explicit owner. This approach can be useful when the project is part of an organization and you want all your projects to be owned by that organization.

Cloud IAM doesn't enable you to manage end-user identities; it enables you to grant access to users who you create and manage by other means. When using Cloud IAM, by default you can grant access to the following types of identities:

  • Google Account
  • Service account
  • Google Group
  • G Suite domain

Google Groups are convenient and the recommended way to apply an access policy to a collection of users. You can grant and change access controls for a whole group at once, instead of granting or changing access controls one at a time for individual users or service accounts. You can also easily add members to and remove members from a Google Group, instead of updating a Cloud IAM policy to add or remove users.

If you don't already use a G Suite domain to manage your users, then you can federate your existing subset of operational users from many popular user directories such as Active Directory. This approach lets you use your existing corporate identities. You must first verify your domain name with Google.

The following table lists and describes the ways you can federate users into GCP.

Federation technique Description
Cloud Directory Sync Tool provided by Google that works with most commercial and enterprise LDAP directory services. Cloud Directory Sync lets you add, modify, and delete users, groups, and non-employee contacts to synchronize the data in your GCP domain with your LDAP directory server by using LDAP queries. The data in your LDAP directory server is never modified or compromised.
Third-party identity connectors Native connectors with an identity provider for those who provide it. Directly connects an identity provider to the domain provisioned in GCP. Examples include:

  • Ping Federate
  • Okta
  • CA Siteminder
  • Azure AD
  • OpenIAM
  • Auth0
  • Oracle IAM
Google Apps API Gives an organization programmatic control of user and group management.

You can then add the identities, in the form of email addresses, to Google Groups to grant them access to GCP resources.

Programmatic identities in AWS

With AWS, if you want to call the AWS APIs from an application that is not running on AWS compute resources, you create an IAM user. Then, you download the appropriate keys and use them with your app to make calls to the AWS APIs.

If you want to use a programmatic identity on an EC2 instance, you must also create an instance profile that is attached to the instance. This profile contains an IAM role, and it can provide the role's credentials to an application that runs on the instance.

An IAM role allows an IAM user, group, or an application that could be running on EC2 or on a mobile device assume the permissions defined by the role. Temporary credentials are created and supplied to the entity that is assuming the role.

The use of IAM roles also allows IAM users to switch to a role to temporarily use the permissions of that role when using the console. When this happens, users give up their original permissions and take on the permissions assigned to the role. When the users exit the role, they surrender those permissions.

Programmatic identities in GCP

With GCP, a service account is a special Google Account that applications can use to programmatically access Google services. This account belongs to your application or a Compute Engine instance rather than to an individual end user.

A service account can contain pairs of service account keys, which are used to authenticate to Google. A service account key is a public-private key pair generated by Google. Google retains the public key, while the user is given the private key.

You can create custom service accounts in GCP projects using the Google Cloud Platform Console, the Cloud Identity and Access Management API, or the gcloud command- line tool.

If you only intend to use the service account with applications running on GCP computing services, you don't need to download the private keys, because you can use GCP-managed keys.

One of the features of Cloud IAM service accounts is that you can treat it as a resource or an identity. The service account has an identity, and you give it permissions by granting it a role to access a resource, such as a project.

When looking at a service account as a resource, you can grant permission to a user to access that service account as you would for other GCP resources. You can grant an owner, editor, viewer, or a serviceAccountActor undefined role to a user to access the service account. A user who is a serviceAccountActor for a service account can access all the resources with the same permissions for which the service account has access. This is similar functionality to the IAM role usage discussed in the previous section.

Service account keys can be either user-managed keys, which are managed by you, or GCP-managed keys, which are managed by GCP.

You can create and manage user-managed keys by using the GCP Console, the Cloud IAM API, or the gcloud command-line tool. You are responsible for keeping the keys safe and rotating them.

GCP-managed keys are used by services such as App Engine and Compute Engine. You cannot explicitly create or download a GCP-managed key; Google manages the keys and rotates them for you once a day.

Permission attribution

Both GCP and AWS use the terms role and policy, but the usages are subtly different. These differences can cause confusion in the mapping from AWS IAM to Cloud IAM. A collection of permissions in GCP is called a role, but with AWS it's called a policy .

AWS permission example

With AWS, you specify the permissions as an action, resource, and effect in the policy definition. For example, an AWS policy that allows (the effect) someone to list all buckets (the action) in an account (the resource) looks like this:

{
  "Version": "2012-10-17",
  "Statement": {
  "Effect": "Allow",
  "Action": "s3:ListAllMyBuckets",
  "Resource": "*"
  }
}

Standalone AWS IAM policies that can be attached to multiple users, groups, and roles are called managed policies. Managed policies can be either AWS managed policies, which are created and managed by AWS, or customer-managed policies, which you create and manage in your AWS account.

GCP permission example

GCP has a predefined, role-first approach, so a common use case such as listing all buckets in a project is simply a matter of using the Viewer role. This role then needs to be assigned to the user or group, and the resulting document that binds users or groups to the role is called a policy. The definition of a policy looks similar to the following example:

{
  "bindings": [
      {
     "role": "roles/viewer",
     "members": ["group:gcs-viewers@example.com"]
   }
  ]
}

AWS policies

With AWS, in addition to being able to attach policies to an identity, you can attach a policy to a resource. For policies that you attach to a resource, you need to embed an identity or role that is able to access the resource within the policy.

In most cases, AWS recommends using managed policies. Recommendations for choosing between managed policies and inline policies are stated in the AWS documentation.

GCP policies

Now look at a GCP policy declared in a JSON file, named iam-gcs-access.json,, which grants the viewer role to a group of users and the objectCreator role to a service account. An application uses the service account to add objects to buckets in a project. The following example illustrates how you can create multiple member-to-role bindings in a single policy.

{
    "bindings": [
    {
        "members": [
            "group:gcs-viewers@example.com"
        ],
        "role": "roles/viewer"
    },
    {
        "members": [
            "serviceAccount:123456789012-compute@developer.gserviceaccount.com"
        ],
        "role": "roles/storage.objectCreator"
    },
    ],
    "etag": "BwUjMhCsNvY=",
    "version": 1
}

This policy can then then be bound to the resource, which in this case is a project, by using the GCP Console, the set-iam-policy command in the gcloud tool, or the API, to assign the policy to the project. For this example, the gcloud command looks like this:

gcloud projects set-iam-policy [PROJECT_ID] iam-gcs-access.json

where [PROJECT_ID] represents your GCP project ID.

This is similar to how you embed an identity or role that is able to access the resource within the policy in AWS.

Managing policies in GCP

You should treat your policies as you do your code: keep them in a version control system with the rest of the assets you use to define your cloud environment. If you update your policies, then create a new version.

While AWS has the two types of policies previously discussed, GCP has only one type of policy, and you have the flexibility to manage your policies using whatever version control system you deem appropriate. GCP offers Cloud Source Repositories, which are fully featured, private Git repositories hosted on GCP.

If you already have a repository on GitHub or Bitbucket, you can connect it to your Cloud Source Repositories. Connected repositories and the Cloud Source Repositories stay automatically synchronized. Cloud Source Repositories also provide a source editor that you can use to browse, view, edit, and commit changes to repository files from the GCP Console.

If you prefer to use your current version control solutions, you can do that on GCP.

Testing and checking permissions

When using AWS, you can use the IAM policy simulator, which lets you test and validate any new and existing policies and see what policies have been set for a user, group, or resource.

With GCP, you can use the get-iam-policy gcloud command to return the policy definition:

gcloud projects get-iam-policy [PROJECT_ID]

You can use the definition returned to help check which policies are attached to the resource. You can also use the GCP Console to go to a specific resource and check the permissions.

To check the permissions assigned to an identity, you can select the identity in the GCP Console and view the roles that identity is bound to. You could also sign in as that identity, or as a test identity that has the same permissions, to check what the identity can access in the GCP Console.

Permission propagation

With AWS, all policies are evaluated. The order in which the policies are defined has no discernible impact, as the end result is either "allowed" or "denied". By using an explicit denial, you can override a broad policy that might allow access to a wide set of resources. This is described in detail in Determining Whether a Request Is Allowed or Denied Within an Account.

With GCP, the effective policy for a resource is the union of the policy set at that resource and the policy inherited from its parent. Because roles are concentric, granting multiple roles to the same user gives the user the permissions of the broadest role granted. You can read some example scenarios in Using resource hierarchy for access control.

IAM auditing

For auditing IAM activity, Amazon offers AWS CloudTrail, which records and logs AWS API calls for your account. CloudTrail sends these logs to an Amazon S3 account you specify.

GCP offers Cloud Audit Logs, which records admin activity and data access. These two streams are generated by GCP services to help you answer the question of "who did what, where, and when?" within your GCP projects.

Individual audit log entries are kept for a specified length of time in Stackdriver, so you can have at-a-glance dashboard views for recent activities. These entries are deleted from Stackdriver after a specified period of time. The Stackdriver Logging quota policy explains the length of time that log entries are retained. You cannot otherwise delete or modify audit logs.

Logging IAM roles let you restrict access to only the logging-related resources in a project or organization.

For longer retention, you can export audit log entries to a Cloud Storage bucket, a BigQuery dataset, a Cloud Pub/Sub topic, or any combination of the three.

What's next

Check out the other GCP for AWS Professionals articles:

Var denne side nyttig? Giv os en anmeldelse af den:

Send feedback om...

Google Cloud Platform for AWS Professionals