RodrigTech

Google Cloud Privileged Access Management

—

by

rodrigtech
in

Today’s vast array of identities whether they are human-centric identities or machine-identities have a large amount of permissions tied to them, given the attack surface of cloud identities can be tied to resources that are also mapped to other services this can be a sticky situation. Most hyperscalers have best practices documented on Identity and Access Management but as far as native integration of use of entitlements, just-in-time access it appears the last one standing from a security perspective would be Amazon Web Services.

Google Cloud Platform recently put Privileged Access Manager a part of the IAM Admin suite in preview. For those that are new to using Privilege Access Manager similar to the concept as having separate accounts for admin activity whether that is practiced with (-a/ad) account requires some process planning. In a move similar to Entra Privileged Identity Management, Google has rolled out an offering that addresses Privileged Access Management. This solution manages entitlements and audit logs, providing a centralized view of who had access to what and when.

Accessing Google PAM Service

First to access this service its important to note you’ll need the API enabled on the project, for this you can navigate to the Enabled APIs & Services page and select the Enabled APIs this redirects to the API library page.

If you type in Privilege Access Manager API this should look like the image below.

Then once you select the PAM API this will redirect to the page and let you know if it’s enabled as you can see the green check is enabled.

Components of PAM

As of this writing in July 2024, the following components make up the GUI interface and likely will change but can be summarized as the following

  • Entitlements (You create a entitlement that support the principles who are allowed to request a grant against a entitlement, if a justification is needed and other parameters)
  • Grants (What has been granted in terms of access)
  • Approve Grants (Is any pending approvals in the history? This is essentially your queue)
  • Audit Logs (Who has accessed using Privileged Access Manager Events) listing of any events related to use of this service

Permissions Required

Prior to leveraging this service after enablement the following roles need to have these permissions. Documentation Link.

  • To create, update and delete entitlements: Privileged Access Manager Admin (roles/privilegedaccessmanager.admin) Additionally either Folder IAM Admin (roles/resourcemanager.folderIamAdmin), Project IAM Admin (roles/resourcemanager.projectIamAdmin), or Security Admin (roles/iam.securityAdmin)
  • To view entitlements and grants: Privilege Access Manager Viewer (roles/privilegedaccessmanager.viewer)
  • To view audit logs: Logs Viewer (roles/logs.viewer)

Creating a entitlement

A note of caution provided by the documentation.

  • Roles with permissions to grant and revoke IAM roles (that is, roles with permission names that end in setIamPolicy).
  • Roles with iam.roles.update permission, which lets users modify custom roles.

These types of roles contain the permissions that could let a user modify their own IAM permissions. As a result, requesting principals can use these roles to increase their own access to resources, or give themselves additional access to resources.

For using the GCloud CLI for this we have to reference the following YAML. Create a entitlement.yaml

privilegedAccess:
  gcpIamAccess:
    resourceType: cloudresourcemanager.googleapis.com/Project
    resource: //cloudresourcemanager.googleapis.com/projects/{project-id}
    roleBindings:
    - role: AI Platform Admin
    - role: AI Platform Developer
maxRequestDuration: "30m0s"
eligibleUsers:
- principals:
  - <requesting-member>
approvalWorkflow:
  manualApprovals:
    requireApproverJustification: true
    steps:
    - approvalsNeeded: 1
      approverEmailRecipients:
      - <APPROVING_EMAIL_1>
      approvers:
      - principals:
        - <APPROVING_MEMBER_1>
requesterJustificationConfig:
  unstructured: {}
additionalNotificationTargets:
  adminEmailRecipients:
  - <ADMIN_EMAIL_ADDRESS_1>
  requesterEmailRecipients:
  - <REQUESTER_EMAIL_ADDRESS_1>

Once you fill in the values you can pass this into the gcloud CLI with the following.

gcloud beta pam entitlements create \
    aiplatformentitlement \
    --entitlement-file=entitlement.yaml \
    --location=global

Once created we can navigate to the console.

If we want to see this programmatically we can run the following command.

gcloud beta pam entitlements list \
    --location=global

This should have the state ‘Available’.

So if we switch identities to the requestor account we can now see the following Request Grant.

We are prompted to give a justification we can input the following as example.

This will shift the Status to Approval Awaited.

If we navigate to the Approval Grants section in our PAM page we can see the request with Approve/Deny.

We can add content to this approval for administrative purposes.

After we hit Approve this will log if we switch to Pam -> Audit Logs

Testing Access

Assuming the role of AI Platform Admin in the next account we can now interact with various API’s related to AI Services.

If we navigate to our IAM Admin Center and Find Roles we can see that this annotation is added to our user that is elevated with a label notated Created by: PAM.

Since I’m using the elevated role of AI Platform Admin I’ve navigate to the Vertex AI Service to send a query to Gemini-1.5.

I can send queries to the Generative AI model and also issue the management of the services with the elevated role.

While the permission set for AI Platform Admin provides me more access then a general viewer in this you’ll still see some limitations in the platform such as if I wanted to use the Vertex AI Agent builder I’ll get a error.

To stop the use of the elevated role once you’ve completed whichever activity you’d needed the elevation for you can navigate to PAM -> Grants this should tell you how much of a duration you have left on the assignment.

Conclusion

In this article we’ve explored the use of Privilege Access Management in regards to use of elevated privileges in a duration based process. The concept of this specific offering are notable from the perspective that now if you are a current customer of Google Cloud Platform you can natively support elevated access for your teams throughout projects and folders. This coupled with the balance of constraints can be a real game changer in lessening the attack surface of dormant identity roles that can be leveraged for attacks on your infrastructure. In all respects of reading this exercise caution on cloud permissions and understand the impacts of widely opened roles consider limiting the surface with custom roles but know you’ll have to manage changes which happen at least monthly in the cloud.