The following best practices can help you get started with role recommendations.
Begin with an initial cleanup of over-granted permissions. Initially, you
might see a very large number of recommendations, especially if many
principals have highly permissive roles like Editor. Take the time to address
all recommendations in your project or organization to ensure that all of your
principals have the appropriate roles.
When doing this initial cleanup, prioritize the following types of
recommendations:
Recommendations that reduce permissions for service accounts.
By default, all default service accounts are
granted the highly permissive Editor role on projects. Other
service accounts that you manage might also have been granted highly
permissive roles. All over-granted permissions increase your security
risk, including overly privileged service accounts, so we recommend
prioritizing overly privileged service accounts during your
initial cleanup.
Recommendations that help prevent privilege escalation. Roles that
let principals act as a service account (iam.serviceAccounts.actAs)
or get or set the allow policy for a resource can potentially let a
principal escalate their own privilege. Prioritize recommendations
relating to these roles.
Recommendations that reduce lateral movement. Lateral movement is when
a service account in one project has permission to impersonate a service
account in another project. This permission can result in a chain of
impersonations across projects that gives principals unintended access to
resources. To mitigate this unintended access, prioritize recommendations
that are associated with lateral movement
insights.
Recommendations with a high priority level. IAM
recommendations are automatically assigned priority levels based on the
role bindings they're associated with. Prioritize recommendations with
a high priority level to quickly reduce over-granted permissions.
When you find an over-privileged principal in one project, check other
projects for recommendations involving that principal. If a principal
has been granted an overly permissive role in one project, it is possible
that they have been granted overly permissive roles in other projects as
well. Review recommendations for the principal across multiple projects to
globally reduce the principal's access to the appropriate level.
After the initial cleanup, check your recommendations regularly. We
recommend that you check your recommendations at least once a week. This check
will usually take much less time than the initial cleanup, because you will
only need to address recommendations for changes that have occurred since the
last cleanup or check.
Regularly checking permissions reduces the work required for each check, and
can help you proactively identify and remove inactive users, as well as
continue to downscope permissions for active users.
Best practices for working with recommendations
If you use the Recommender API or the
recommender commands for the gcloud CLI to
manage recommendations, make sure to update the state of recommendations that
you apply. This allows you to keep track of your recommendations and ensures
that the changes you make appear in your recommendations logs.
Best practices for applying recommendations automatically
To manage your recommendations more efficiently, you might want to automate the
process of applying recommendations. If you decide to use automation, keep the
following points in mind.
Recommender tries to provide recommendations that will not
cause breaking changes in access. For example, we will never recommend a role
that excludes permissions that a principal has used,
passively or actively, in the last
90 days. We also use machine learning to
identify other permissions that the user is likely to need.
However, we cannot guarantee that our recommendations will never cause breaking
changes in access—it is possible that applying a recommendation will
result in a principal being unable to access a resource that they need. We
recommend reviewing
How the IAM recommender works and
deciding how much automation you are comfortable with. For example, you might
decide to apply most recommendations automatically, but require a manual review
for recommendations that add or remove a certain number of permissions, or that
involve granting or revoking a specific role.
When automating recommendations, you might want to identify which resource a
recommendation is for. To identify the resource, use the operation.resource
field. Other fields, such as the name field, will not always represent the
resource that the recommendation is for.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[],[],null,["# Role recommendations best practices\n\nWe recommend the following best practices for managing role recommendations.\n\nFor more information about role recommendations, see the\n[role recommendation overview](/policy-intelligence/docs/role-recommendations-overview).\n\nGetting started with recommendations\n------------------------------------\n\nThe following best practices can help you get started with role recommendations.\n\n- **Begin with an initial cleanup of over-granted permissions.** Initially, you\n might see a very large number of recommendations, especially if many\n principals have highly permissive roles like Editor. Take the time to address\n all recommendations in your project or organization to ensure that all of your\n principals have the appropriate roles.\n\n When doing this initial cleanup, prioritize the following types of\n recommendations:\n - **Recommendations that reduce permissions for service accounts.**\n By default, all [default service accounts](/iam/docs/service-account-types#default) are\n granted the highly permissive Editor role on projects. Other\n service accounts that you manage might also have been granted highly\n permissive roles. All over-granted permissions increase your security\n risk, including overly privileged service accounts, so we recommend\n prioritizing overly privileged service accounts during your\n initial cleanup.\n\n - **Recommendations that help prevent privilege escalation.** Roles that\n let principals act as a service account (`iam.serviceAccounts.actAs`)\n or get or set the allow policy for a resource can potentially let a\n principal escalate their own privilege. Prioritize recommendations\n relating to these roles.\n\n - **Recommendations that reduce lateral movement.** Lateral movement is when\n a service account in one project has permission to impersonate a service\n account in another project. This permission can result in a chain of\n impersonations across projects that gives principals unintended access to\n resources. To mitigate this unintended access, prioritize recommendations\n that are associated with [lateral movement\n insights](/policy-intelligence/docs/role-recommendations-overview#lateral-movement-insights).\n\n - **Recommendations with a high priority level.** IAM\n recommendations are automatically assigned priority levels based on the\n role bindings they're associated with. Prioritize recommendations with\n a high priority level to quickly reduce over-granted permissions.\n\n To learn how a recommendation's priority is determined, see\n [Recommendation priority](/policy-intelligence/docs/role-recommendations-overview#priority).\n - **When you find an over-privileged principal in one project, check other\n projects for recommendations involving that principal.** If a principal\n has been granted an overly permissive role in one project, it is possible\n that they have been granted overly permissive roles in other projects as\n well. Review recommendations for the principal across multiple projects to\n globally reduce the principal's access to the appropriate level.\n\n- After the initial cleanup, **check your recommendations regularly.** We\n recommend that you check your recommendations at least once a week. This check\n will usually take much less time than the initial cleanup, because you will\n only need to address recommendations for changes that have occurred since the\n last cleanup or check.\n\n Regularly checking permissions reduces the work required for each check, and\n can help you proactively identify and remove inactive users, as well as\n continue to downscope permissions for active users.\n\nBest practices for working with recommendations\n-----------------------------------------------\n\nIf you use the [Recommender API](/recommender/docs/reference/rest) or the\n[`recommender` commands for the gcloud CLI](/sdk/gcloud/reference/recommender) to\nmanage recommendations, make sure to update the state of recommendations that\nyou apply. This allows you to keep track of your recommendations and ensures\nthat the changes you make appear in your [recommendations logs](/policy-intelligence/docs/review-apply-role-recommendations#logs).\n\nBest practices for applying recommendations automatically\n---------------------------------------------------------\n\nTo manage your recommendations more efficiently, you might want to automate the\nprocess of applying recommendations. If you decide to use automation, keep the\nfollowing points in mind.\n\nRecommender tries to provide recommendations that will not\ncause breaking changes in access. For example, we will never recommend a role\nthat excludes permissions that a principal has used,\n[passively or actively](/policy-intelligence/docs/role-recommendations-overview#permissions-used), in the last\n90 days. We also use [machine learning](/policy-intelligence/docs/role-recommendations-overview#ml) to\nidentify other permissions that the user is likely to need.\n\nHowever, we cannot guarantee that our recommendations will never cause breaking\nchanges in access---it is possible that applying a recommendation will\nresult in a principal being unable to access a resource that they need. We\nrecommend reviewing\n[How the IAM recommender works](/policy-intelligence/docs/role-recommendations-overview#how-recommender-works) and\ndeciding how much automation you are comfortable with. For example, you might\ndecide to apply most recommendations automatically, but require a manual review\nfor recommendations that add or remove a certain number of permissions, or that\ninvolve granting or revoking a specific role.\n\nWhen automating recommendations, you might want to identify which resource a\nrecommendation is for. To identify the resource, use the `operation.resource`\nfield. Other fields, such as the `name` field, will not always represent the\nresource that the recommendation is for.\n\nWhat's next\n-----------\n\n- Understand [role recommendations](/policy-intelligence/docs/role-recommendations-overview).\n- Learn the steps for [reviewing and applying recommendations](/policy-intelligence/docs/review-apply-role-recommendations).\n- Find out how to [export data for IAM recommendations](/policy-intelligence/docs/export-role-recommendations-data)."]]