Introduction
This page recommends security best practices that you should keep in mind when using IAM.
This page is designed for users who are proficient with 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 IAM Quickstart.
Least privilege
❑
Basic roles include thousands of permissions across all Google Cloud services. In production
environments, do not grant basic roles unless there is no alternative. Instead, grant the most
limited predefined roles or
custom roles that meet your needs.
If you need to replace a basic role, you can use the IAM recommender to determine which roles to grant instead. You can also use the Policy Simulator to ensure that changing the role won't affect the member's access. It might be appropriate to grant basic roles in the following cases:
|
❑
Treat each component of your application as a separate trust boundary. If you
have multiple services that require different permissions, create a separate service account
for each of the services, then grant only the required permissions to each
service account.
|
❑
Remember that the policies for child resources inherit from the policies for
their parent resources. For example, if the policy for a project grants a user
the ability to administer Compute Engine virtual machine (VM) instances, then
the user can administer any Compute Engine VM in that project,
regardless of the policy you set on each VM.
|
❑
Grant roles at the smallest scope needed. For example, if a user only needs
access to publish Pub/Sub topics, grant the Publisher role to the user for that
topic.
|
❑
Specify which members can
act as service accounts.
Users who are granted the Service Account User role for a service account can
access all the resources to which the service account has access. Therefore, be
cautious when granting the Service Account User role to a user.
|
❑
Specify who has access to create and manage service accounts in your project.
|
❑
Granting the
Project IAM
Admin and Folder IAM Admin predefined roles will allow access to modify
IAM policies without also allowing direct read, write, and
administrative access to all resources.
Granting the Owner ( roles/owner ) role to a member will allow them to access and
modify almost all resources, including modifying IAM policies.
This amount of privilege is potentially risky. Grant the Owner
(roles/owner ) role only when (nearly) universal access is
required.
|
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. Encryption
keys are typically used to encrypt data and service account keys are used for
secure access to Google Cloud 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 logs from Cloud Audit Logs to
regularly audit changes to your IAM policy.
|
❑
Export audit logs to Cloud Storage
to store your logs for long periods of time.
|
❑
Audit who has the ability to change your IAM policies on your
projects.
|
❑
Manage access to logs using
Logging roles.
|
❑
Apply the same access policies to the Google Cloud resource that you use
to export logs as applied to the logs viewer.
|
❑
Use logs from 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 individual users when possible. It
is easier to add members to and remove members from a Google group instead of
updating an 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.
|