Using IAM Securely

Introduction

This page recommends security best practices that you should keep in mind when using Cloud IAM.

This page is designed for users who are proficient with Cloud IAM. If you are just starting out with IAM, these instructions will not teach you how to use it; instead, new users should start with the Cloud IAM Quickstart.

Least privilege

❑  
Predefined roles provide more granular access than the primitive roles. Grant predefined roles to identities when possible, so you only give the least amount of access necessary to access your resources.
❑  
Grant primitive roles in the following cases:
  • when the Cloud Platform service does not provide a predefined role. See the predefined roles table for a list of all available predefined roles.
  • when you want to grant broader permissions for a project. This often happens when you’re granting permissions in development or test environments.
  • when you need to allow a member to modify permissions for a project, you’ll want to grant them the owner role because only owners have the permission to grant access to other users for for projects.
  • when you work in a small team where the team members don’t need granular permissions.
❑  
Treat each component of your application as a separate trust boundary. If you have multiple services that requires different permissions, create a separate service account for each of the services so that they can be permissioned differently.
❑  
Remember that a policy set on a child resource cannot restrict access granted on its parent. Check the policy granted on every resource and make sure you understand the hierarchical inheritance.
❑  
Grant roles at the smallest scope needed. For example, if a user only needs access to publish Pub/Sub topic, grant the Publisher role to the user for that topic.
❑  
Restrict who can act as service accounts. Users who are granted the Service Account Actor role for a service account can access all the resources for which the service account has access. Therefore be cautious when granting the Service Account Actor role to a user.
❑  
Restrict who has access to create and manage service accounts in your project.
❑  
Granting owner role to a member will allow them to modify the IAM policy. Therefore grant the owner role only if the member has a legitimate purpose to manage the IAM policy. This is because as your policy contains sensitive access control data and having a minimal set of users manage it will simplify any auditing that you may have to do.

Service accounts and service account keys

❑  
Rotate your service account keys using the IAM service account API. You can rotate a key by creating a new key, switching applications to use the new key and then deleting old key. Use the serviceAccount.keys.create() method and serviceAccount.keys.delete() method together to automate the rotation.
❑  
Implement processes to manage user-managed service account keys.
❑  
Be careful not to confuse encryption keys with service account keys. Encyption keys are typically used to encrypt data and service account keys are used for secure access to Google Cloud Platform APIs.
❑  
Do not delete service accounts that are in use by running instances. This could result in all or parts of your application to fail if you have not transitioned to using an alternative service account first.
❑  
Use the display name of a service account to keep track of what they are used for and what permissions they should have.
❑  
Don’t check in the service account keys into the source code or leave them in the Downloads directory.

Auditing

❑  
Use Cloud audit logs to regularly audit changes to your IAM policy.
❑  
Exporting audit logs to Google Cloud Storage to store your logs for long periods of time.
❑  
Audit who has the ability to change your IAM policies on your projects.
❑  
Restrict access to logs using Cloud logging roles.
❑  
Apply the same access policies to the Cloud Platform resource that you use to export logs as applied to the logs viewer.
❑  
Use Cloud audit logs to regularly audit access to service account keys.

Policy management

❑  
Set organization-level IAM policies to grant access to all projects in your organization.
❑  
Grant roles to a Google group instead of to individual users when possible. It is easier to add members to and remove members from a Google group instead of updating a Cloud IAM policy to add or remove users.
❑  
If you need to grant multiple roles to allow a particular task, create a Google group, grant the roles to that group, and then add users to that group.

Send feedback about...

Cloud Identity and Access Management Documentation