Back to main page
GCP Privileged Access Management – next step implementing Least Privilege Access
In today’s complex digital landscape, security is paramount. One of the foundational principles in building a robust security posture is the principle of least privilege. This seemingly simple concept dictates that user accounts and processes should only possess the essential permissions required to perform their designated tasks. Think of it like this: a key that opens the front door shouldn’t also start the car or access the safe.
This principle extends beyond individual user accounts. In organizations embracing Infrastructure as Code (IaC), the very way infrastructure is managed shifts. Instead of individual administrators directly creating, modifying, or deleting resources, these actions are automated through code executed by service accounts. This inherently enforces least privilege, as these service accounts are granted only the precise permissions needed for their specific IaC workflows.
For teams responsible for specific resource types – be it network infrastructure, databases, or servers – the focus shifts from granting broad permissions to individual team members to meticulously defining the necessary permissions for dedicated service accounts. This significantly reduces the attack surface and minimizes the potential for human error or malicious activity.
However, what happens when manual intervention becomes necessary? This is where Privileged Access Management (PAM) steps in, offering a controlled and auditable way to grant temporary, privileged permissions when needed.
Understanding the Building Blocks: Roles, IAM, and PAM
To truly appreciate how PAM enhances least privilege, let’s briefly touch upon some key concepts:
Roles: Roles are collections of permissions that define what actions an identity can perform on a resource. For example, the role “Logging Admin” has permissions to create, delete, and modify everything related to logging: log buckets, log sinks, metrics, etc.
Identity and Access Management (IAM): IAM is a service that lets you control who has access to your cloud resources. It enables you to manage permissions, granting or denying access to specific resources. You can assign these permissions at the organization, folder, and project levels, providing a hierarchical approach to access management.
Privileged Access Management (PAM): PAM takes the principle of least privilege a step further by managing and monitoring privileged access. Instead of granting users permanent broad permissions, PAM allows for the temporary elevation of privileges under specific conditions and for a limited time. This significantly reduces the risk associated with standing privileged accounts. For example, an engineer can get permission to modify resources for half an hour to fix a production incident.
Implementing Least Privilege with PAM on GCP: A Step-by-Step Approach
Let’s outline the steps involved in implementing a PAM-based least privilege model within Google Cloud Platform (GCP):
- Administrators Create Entitlements: This crucial first step involves defining what privileged actions can be requested by whom, for how long, and the optional approval workflow. For example, the DevOps team is entitled to request Project Editor permissions for up to 2 hours. Approval should be granted by the security team, and the request should contain a justification explaining why privileged permission is needed.
- User Requests Grant for a Specific Time: Users initiate these requests through a PAM interface, typically under a section like “My Entitlements” -> “REQUEST GRANT.” They need to specify the duration and, when required, a justification for why the permissions are needed. For example, a DevOps engineer requests Project Editor permissions for 0.5 hours for a production issue quickfix.
- Approver Approves (Optional): Depending on the defined entitlement, the request may need to be approved by a designated approver before the permissions are granted. The PAM system usually sends notifications to the designated approvers, who can then review the request details and approve or deny it within the PAM system. For example, a security team receives an email from PAM about the request and needs to approve or deny it in the GCP console.
- User is Allowed to Perform Actions: Once the request is approved (or if no approval is required), the PAM system temporarily grants the user the requested permissions for the specified duration. Behind the scenes, PAM updates the IAM policies for the user, granting them the requested role(s) with a defined expiration condition.
- Permissions are Removed After Requested Time Passes: Once the specified duration expires, the temporarily granted permissions are automatically revoked by the PAM system.
Grants can be assigned at various levels within the GCP hierarchy: organization, folder, and project. This allows for fine-grained control over where these temporary privileges are effective.
What did we do in Mooncascade while trialing the PAM approach?
- Replaced the allocation of IAM permissions directly to administrative groups (i.e., Organization Administrator, Billing Administrators) with PAM entitlements.
- Getting any permission other than “view” requires a teammate’s approval through the PAM process.
- Sandbox projects have the same approach, but approval is not required.
- Entitlements: Google-suggested GCP administrative group based.
- IAM permissions: Team based.
The Result: Enhanced Security and Simplified IAM
Implementing a PAM strategy on top of a foundation of least privilege and IaC yields significant benefits:
- Automatic Removal of Privileged Permissions: The temporary nature of PAM grants means that additional “privileged” permissions are automatically revoked once the specified time expires. This eliminates the need for manual tracking and removal of privileged permissions, reducing the risk of orphaned or excessive permissions.
- Simpler IAM Setup: By relying on PAM for temporary privileged permissions, you can maintain a simpler and cleaner IAM setup for regular users and service accounts. There’s less need to grant users broad, standing “create/edit/delete” (Owner/Editor) permissions, simplifying your overall access control model.
- Stronger Security Posture: A four-eye principle reduces the risk that one person can cause harm to your systems, whether due to leaked credentials or malicious intent. Improved auditability allows you to see why privileged permissions are requested.
References
Least privilege principle: https://en.wikipedia.org/wiki/Principle_of_least_privilege
IAM: https://cloud.google.com/resource-manager/docs/access-control-org
PAM: https://cloud.google.com/iam/docs/pam-overview
Summary
By embracing the principle of least privilege and leveraging the capabilities of PAM, organizations can significantly strengthen their security posture, reduce the risk of breaches, and simplify their access management practices. Remember, security is not a destination but an ongoing journey, and implementing these principles is a crucial step in the right direction.
