Table of Contents
When you follow the principle of least privilege, you grant users just enough access so that they can carry out everyday activities, but can do nothing more. Following this principle helps you reduce risk. However, it can create friction for users when they occasionally need to perform a privileged action—such as dealing with an unexpected incident.
The problem is that most companies are unaware of the solutions available to them—so much so that they are spending manpower slapping together internally made solutions for automating access requests to GCP. In this article, we’ll discuss the three ways you can build JIT access to GCP.
Why Automate On-Demand Access Requests for GCP?
As an admin on a large project, it’s common to be inundated with requests from users asking for access to a project. This process is filled with inefficiencies – the admin doesn’t really know how to handle these requests, so they forward the request to the project lead, asking for their approval. Once the project lead approves, then the admin has to manually add them to the right group or project role, enabling them access to the project.
Challenges With Requesting and Delivering Access in GCP
- Doesn’t know what permissions to give. Things are not necessarily mapped out to the task that the requestor needs to do.
- Doesn’t know who needs to approve them. For example, if I’m the person giving the permissions, that’s the one managing the GCP here, but maybe I need to go back to their manager to see if he needs one of these. Maybe the security team; maybe the compliance team.
- Doesn’t know for how long someone needs the permissions. This requires you to go back and forth to ask about the length of time needed.
- Doesn’t know who currently has permissions to what. There’s a lack of visibility into who has access to what environments or resources
Solutions
For companies who want to benefit from JIT access to Google Projects, there are three options available. They are the following:
1. DIY
At Apono, we’ve spoken with many companies who, for lack of a better option, built their own internal solutions for requesting access. One such company, Mednition, recently published an article about it. You can find it in whole here.
The company had a few goals:
- Fewer standing privileges
- Faster submitting of tickets for access requests and waiting for approval.
- Fits within the tech stack currently adopted.
- Creates an audit trail that’s easy to index and search.
- Supports compliance requirements for auditing and logging.
Here’s the solution the company created:
“We decided to create a Slack bot that runs within GCP Cloud Run and logs the audit trail to GCP Cloud Logging. We will leverage Google Groups for provisioning access and Cloud Identity as the mechanism for managing temporary membership. Cloud Identity will add and remove the user from the group for us, so we don’t have to manage any state (which is amazing to avoid sync issues and edge cases). This is particularly interesting because now we can provide temporary access to third party applications if they can map access to Google Groups (outside of our use case but maybe in the future).”
2. Google’s Open Source Solution
Google’s Just-In-Time Access is an open source application that lets you implement just-in-time privileged access to Google Cloud resources. The application lets administrators, users, and auditors do the following tasks:
- Administrators can grant a role to a user or group and make the role eligible by adding the following IAM condition: has({}.jitAccessConstraint)
- Users can search for projects and roles that they’re eligible to access by using the Just-In-Time Access application. (The following screenshot from the Just-In-Time Access application shows a list of roles that a user is eligible for in a project: )
They can then activate one or more roles and provide a justification for getting access:
After a user has activated a role, Just-In-Time Access grants the user temporary access to the project.
- Auditors can use Cloud Logging to review when and why eligible roles have been activated by users.
To protect the application against unauthorized access, the Just-In-Time Access application can be accessed only over Identity-Aware Proxy (IAP). Using IAP, an administrator can control which users should be allowed to access Just-In-Time Access, and which additional conditions those users must satisfy in order to get access.
3. Out-of-the-box tools
Solutions such as Apono provide plug-and-play authorization workflows so that companies don’t need to start from scratch. Apono serves as the intermediary that connects identities with entitlements, enabling access on a just-in-time, temporary basis. Apono’s privilege authorization capability provides a reliable and streamlined approach to permission management and mitigates the consequences of a GCP permissions-related breach, without compromising user experience and productivity.
The image below features an access flow that allows developers to get temporary read-only access to production when needed.
Remember that managing access control effectively is a critical aspect of maintaining the security and integrity of your GCP resources. Regularly review and audit your roles and permissions to ensure they align with your evolving requirements.
New to GCP role management or need a quick refresher?
Here’s a brief overview of everything you need to know.
The Google Cloud Platform (GCP) provides a robust system for managing access and permissions through roles. Roles in GCP allow you to control what actions users and services can perform within your projects and resources. In this beginner’s guide, I’ll provide an overview of GCP roles and their usage.
1. Understanding GCP IAM: Google Cloud Identity and Access Management (IAM) is the central service that controls access to GCP resources. IAM manages permissions and roles across projects, allowing you to grant and revoke access as needed.
2. Predefined Roles: GCP offers a set of predefined roles with specific permissions. These roles are designed to cover common use cases and provide a level of granular access control. Some of the commonly used predefined roles include:
– Owner: Has full control over the project, including managing roles and billing.
– Editor: Can view and modify project resources but cannot manage roles or billing.
– Viewer: Can view project resources but cannot make any modifications.
– Billing Account Administrator: Has access to billing information and can manage billing accounts.
– Compute Instance Admin: Can manage compute instances but not other resources.
– Storage Object Viewer: Can view objects within Cloud Storage buckets.
These predefined roles are useful starting points for managing access, but they may not always provide the precise level of control needed for your specific requirements.
3. Custom Roles: GCP allows you to create custom roles tailored to your specific needs. Custom roles offer fine-grained control over permissions by selecting individual actions or setting broad permissions within a particular service. You can define custom roles at the project or organization level and assign them to users or groups as required.
4. Role Hierarchy: Roles in GCP follow a hierarchy where higher-level roles inherit permissions from lower-level roles. For example, the `roles/owner` role inherits all permissions from the `roles/editor` role, which, in turn, inherits permissions from the `roles/viewer` role. Understanding this hierarchy is crucial for managing roles effectively and avoiding unnecessary duplication.
5. Service Accounts: Service accounts are special accounts used by applications, virtual machines, and other services to interact with GCP resources. Similar to user accounts, service accounts can be assigned roles to determine their permissions. It’s important to grant the minimum required permissions to service accounts to reduce the risk of unauthorized access.
6. Granting Roles: Roles can be assigned at various levels, including the project, folder, or organization level. You can grant roles to individual users, groups, or service accounts. It’s recommended to follow the principle of least privilege, granting only the necessary permissions for users to perform their tasks.
7. Testing Access: GCP provides a tool called the IAM & Admin Policy Simulator, which allows you to test the effectiveness of your roles and permissions without making actual changes to access control settings. This tool helps ensure that users have the right level of access without exposing sensitive resources.
