Do your cloud environments end up cluttered with excess permissions that are no longer being used?
Engineers will often need access to a production cloud environment for brief periods: maybe an hour to debug a production incident or access for a week related to a feature they’re working on. Suppose this is addressed by granting them the required access normally. In that case, they’ll likely end up with this access for much longer than needed: manually revoking the access once they’re done using it is easy to forget and can quickly become a lot of effort as the number of engineers requesting access increases.
Google Cloud natively supports a solution to this problem by allowing you to attach an IAM condition containing an expiration time to a role binding. In this blog post, I’ll walk you through this process.
Why use temporary access?
Improve your security posture by removing permanent grants to sensitive resources and granting temporary access when needed.
Prevent engineers from unintentionally impacting production environments by ensuring they only have production access when needed.
Simplify access reviews by reducing the number of permanent grants in the system.
Permanent grants to overly privileged roles may violate compliance requirements, while temporary grants are generally fine.
Implementation via conditional IAM
You’ll add an IAM condition to the role binding that specifies the expiration. After the expiration, the role binding will still exist, but it will no longer grant access because the condition will be evaluated as false.
To start, you’ll need the appropriate permissions to manage IAM policies on whatever resource you want to add the temporary binding on. For example, if you want to grant temporary access to a project, you’ll need resourcemanager.projectIamAdmin
Using the Google Cloud Console
Begin by visiting the “Grant access” page for your desired resource.
Specify the role and principal, then click “Add IAM Condition.”
Next, specify the condition type: click “time” and then “expiring access.”
Finally, you can specify your expiration by entering an expiry timestamp or a duration.
Add a descriptive condition title and name, click save, and you’re all set.
Directly set policy (CLI or API)
To update an IAM policy via the gcloud CLI or REST API, first get the current IAM policy.
For projects, this can be done via gcloud
Plain Text
gcloud projects get-iam-policy
Or via the Resource Manager API’s projects.getIamPolicy method.
The IAM policy is in the following format, with various role bindings.
{
"version":1,
"etag":"BwWKmjvelug=",
"bindings":[
{
"role":"roles/owner",
"members":[
"user:project-owner@example.com"
]
}
]
}
You will now add a new binding with your desired member and role with the following IAM condition expression:
request.time < timestamp('2020–07–01T00:00:00.000Z')
For example, if you are adding user:test@example.com to iam.securityReviewer with an expiry of July 1 2020 you would create the following binding:
{
"role":"roles/iam.securityReviewer",
"members":[
"user:test@example.com"
],
"condition":{
"title":"Condition title",
"description":"Condition description",
"expression":"request.time < timestamp('2020–07–01T00:00:00.000Z')"
}
}
Next, add the new binding to the list of bindings in the existing IAM policy. Note that even if an existing binding exists to iam.securityReviewer, you’ll still want to create this new binding to add the condition.
Finally, you can set the IAM policy via the Resource Manager API’s projects.setIamPolicy method, or through gcloud projects set-iam-policy.
Limitations
Although IAM conditions are a great way to implement ephemeral access to your Google Cloud environments, this approach has a few limitations.
Basic roles cannot be used with IAM conditions. This means you cannot temporarily grant Viewer, Editor, or Owner using this method.
Some Google resources, such as BigQuery tables, do not support IAM conditions. To grant temporary access to these resources, you would need to grant the role binding on a parent resource that does support conditions (such as the project).
The bindings are not deleted when the access is no longer active. This can make IAM policies harder to understand after some time since they can get cluttered with expired bindings.
Want to stop manually editing IAM policies? Let P0 automate temporary access.
Are you tired of grappling with complex access management processes that slow down your team’s productivity? Say hello to P0 Security, the ultimate solution to streamline access control and elevate your team’s efficiency. You can use our app to grant temporary access to Google Cloud without running a single gcloud command.
After P0 is installed, users can request access simply by typing /p0 request into Slack. Once the request is created, any configured user can approve it by specifying an expiration time and clicking a button on the Slack message. Once a request is approved, P0 automatically provisions the access for the user and will automatically revoke the access after the expiration time.
For Google Cloud, we include the expiration as an IAM condition whenever possible, but we’ll also remove the binding after the access has expired. This allows us to bypass Google Cloud’s limitations and grant any access temporarily, even if conditional IAM isn’t supported. Additionally, it ensures that your IAM bindings aren’t cluttered with expired accesses.
To learn more about how P0 Security can automate access for your team, view a guided tour of our workflows, head over to our docs for more details, or create a free account to get started.