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
If you need to replace a basic role, you can use role recommendations to determine which roles to grant instead. You can also use the Policy Simulator to ensure that changing the role won't affect the principal's access.
It might be appropriate to grant basic roles in the following cases:
- When the Google Cloud 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 work in a small team where the team members don't need granular permissions.
Granting the Owner (
roles/owner
) role to a principal will allow them to access and
modify almost all resources, including modifying allow policies. This amount
of privilege is potentially risky. Grant the Owner role only when (nearly)
universal access is required.Service accounts
❑
Adopt best practices for
working with service accounts
. Ensure that service accounts have limited
privileges, and protect against potential security threats.
|
---|
❑
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 the service
account is used for and what permissions it needs.
|
Service account keys
❑
Avoid using service account keys if another option is
available.Service account keys are a security risk if not managed correctly. You should choose a more secure alternative to service account keys
whenever possible. If you must authenticate with a service account key, you are responsible for the
security of the private key and for other operations described by Best practices for managing service account keys
.
If you are prevented from creating a service account key, service account key creation might
be disabled for your organization. For more information, see Managing secure-by-default organization resources
.
|
---|
❑
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, disabling the old key, and then deleting the
old key when you are sure that it is no longer needed.
|
❑
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.
|
❑
Don't check in the service account keys into the source code or leave them in
the Downloads directory.
|
Auditing
❑
|
---|
❑
Export audit logs
to Cloud Storage
to store your logs for long periods of time.
|
❑
Audit who has the ability to change your allow policies on your projects.
|
❑
|
❑
Apply the same access policies to the Google Cloud resource that you use
to route logs as applied to the Logs Explorer.
|
❑
Use logs from Cloud Audit Logs to regularly audit access to service
account keys.
|
Policy management
❑
If a principal needs access to all projects in your organization, grant roles to
the principal at the organization level
.
|
---|
❑
Grant roles to a Google group instead of individual users when possible. It
is easier to update the members of a Google group than to update the principals
in your allow policies.
|