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 of time: maybe access for an hour to debug a production incident, or access for a week related to a feature they’re working on. If this is addressed by granting them the required access normally, it’s likely they’ll 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.
It turns out that 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 they need to use it
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 exists, but it will no longer grant any access because the condition will evaluate to 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 on a project, you’ll need resourcemanager.projectIamAdmin .
Using the Google Cloud Console
Begin by going to the “Grant access” page for your desired resource.
Specify the role and principal, and then click “Add IAM Condition”.
Next, specify the condition type: click “time”, and then “expiring access”.
Finally, you can specify your expiration either by entering an expiry timestamp or by specifying 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 projects get-iam-policy or the Resource Manager API's projects.getIamPolicy method.
The IAM policy is in the following format, with an array of 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 in order 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, there are a few limitations to this approach.
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. In order 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 type of access on a temporary basis, 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 can automate access for your team, view a guided tour of our workflows, head over to our docs for more details, or create an account to get started.
Top comments (0)