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 & Access Management.

Cloud Platform 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 Cloud Platform enable you to grant permissions to users, groups, and applications. These permissions allow the granted entity to have clearly defined access to your cloud resources.

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

Concept AWS Cloud Platform
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 the Cloud IAM service. 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 Curated 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.

Organizations and projects in Cloud Platform

Cloud Platform provides container resources, such as organizations and projects, that allow you to group and hierarchically organize other Cloud Platform resources, such as Google Cloud Pub/Sub topics and Google 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 Cloud Platform resources belong to the project resource, and an individual Cloud Platform account can manage multiple projects. The projects can be managed individually, or you can manage all your projects under an organization resource.

The following diagram shows an example of a various resources and their hierarchical organization in Cloud Platform.

Example of a Cloud Platform resource hierarchy.

Cloud Platform assumes that you will work with different projects, so Cloud IAM uses a hierarchical approach to implementing IAM that flows from the organization node downwards. If you want to isolate permissions across multiple teams and projects, you can use Cloud Platform projects to do so. You can then assign permissions at the project level and at the resource level within the project.

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 cloud 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 Cloud Platform

With Cloud Platform, 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 do not 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 does not 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 do not 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 allows you to use you 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 Cloud Platform.

Federation technique Description
Google Cloud Directory Sync (GCDS) Tool provided by Google that works with most commercial and enterprise LDAP directory services. GCDS allows you to add, modify, and delete users, groups, and non-employee contacts to synchronize the data in your Cloud Platform domain with your LDAP directory server by using LDAP queries. The data in your LDAP directory server is never modified or compromised.
3rd party Identity Connectors Native connectors with an identity provider for those who provide it. Directly connects an identity provider to the domain provisioned in Cloud Platform. 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 Cloud Platform 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 to 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 Cloud Platform

With Cloud Platform, 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 Google Cloud Platform projects using the Google Cloud Platform Console, the Cloud IAM API, or the gcloud command- line tool.

If you only ever intend to use the service account with applications running on Cloud Platform computing services, you do not need to download the private keys as you can use Cloud-Platform-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 Cloud Platform 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 Cloud-Platform-managed keys, which are managed by Cloud Platform.

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

Cloud-Platform-managed keys are used by services such as Google App Engine and Compute Engine. You cannot explicitly create or download a Cloud Platform-managed key; Google will manage the keys and will rotate them for you once a day.

Permission attribution

Both Cloud Platform 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 Cloud Platform 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.

Cloud Platform permission example

Cloud Platform has a curated, 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.

Cloud Platform policies

Now look at a Cloud Platform policy declared in 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 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 would look like this:

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

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 Cloud Platform

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, Cloud Platform has only one type of policy, and you have the flexibility to manage your policies using whatever version control system you deem appropriate. Cloud Platform offers Google Cloud Source Repositories, which are fully-featured, private Git repositories hosted on Cloud Platform.

If you already have a repository on GitHub or Bitbucket, you can connect it to your Cloud Source Repository. Connected repositories and the Cloud Source Repository 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 Cloud Platform Console.

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

Testing and checking permissions

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

With Cloud Platform, 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 have been attached to the resource. You can also use the Cloud Platform Console to navigate to a specific resource and check the permissions.

To check the permissions assigned to an identity, you can select the identity in the Cloud Platform 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 been granted the same permissions, to check what the identity can access through the console.

Permission propagation

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.

Cloud Platform supports only resource-based permissions. In Cloud Platform, resources are organized hierarchically, where the organization node is the root node in the hierarchy, the projects are the children of the organization, and the other resources are the children of projects. You can set IAM policies at different levels of the resource hierarchy. Resources inherit the policies of the parent resource.

The following diagram shows how policy inheritance works in a hierarchy of Cloud Platform resources.

Example of a Cloud Platform resource hierarchy illustrating policy inheritance.

With AWS, all policies are evaluated. The order in which the policies are defined has no discernible impact, as the end result will be 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 the AWS documentation.

With Cloud Platform, 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 the Cloud IAM documentation.

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.

Cloud Platform offers Cloud audit logging, which records Admin Activity and Data Access. These two streams are generated by Cloud Platform services to help you answer the question of "who did what, where, and when?" within your Google Cloud Platform 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.

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

For longer retention, you can easily 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 Google Cloud Platform for AWS Professionals articles:

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Google Cloud Platform for AWS Professionals