> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/privileged-access-manager/just-in-time-access-jit/keeper-privileged-cloud.md). # Keeper Privileged Cloud
{% hint style="info" %} Contact your Keeper account manager to learn more about Keeper Privileged Cloud {% endhint %} ## Overview Keeper Privileged Cloud provides identity-based just-in-time access across cloud and directory platforms. It grants temporary elevated access by changing identity-layer membership or role assignment for an approved user. Use this model when access is controlled by an identity provider, SSO flow, federated application, group membership, or role-based access control. #### **Understanding JIT and ZSP** **Just-In-Time (JIT) Access**: Provides users with privileged access only at the moment they need it, for a limited time period, and often with approval workflows. **Zero Standing Privilege (ZSP)**: A security approach where users have no permanent privileged access to systems, eliminating the risk associated with compromised privileged accounts. In Privileged Cloud, JIT access is typically delivered through temporary group membership, role assignment, or entitlement grant in the identity provider. ### Supported Identity Platforms Keeper Privileged Cloud supports JIT privilege elevation on the following identity platforms: * AWS IAM * Microsoft Entra ID * GCP through Google identity * Okta * Active Directory {% hint style="info" %} Any cloud platform or SaaS application that uses one of these identity platforms for authentication or authorization can use Privileged Cloud. {% endhint %} ### Supported Record Types Privileged Cloud supports JIT privilege elevation through the following record types: * PAM Cloud record * PAM Machine * PAM Database ### What this model changes Privileged Cloud changes access in the identity layer. It does not rely on standing admin credentials shared with end users. Depending on the target platform, KeeperPAM can: * Add the user to a mapped group * Assign a temporary role or entitlement * Remove that membership or assignment automatically when access expires The target cloud console, application, CLI, or SDK then evaluates that identity change through its normal SSO or authorization flow. ### When to use Privileged Cloud Use Privileged Cloud when: * Access is granted through an identity provider, directory group, or cloud role * Users sign in through SSO or a federated login flow * You want temporary entitlements instead of shared privileged accounts * Access must be approved, time-bound, and fully auditable ### Prerequisites Privileged Cloud extends KeeperPAM's [Just-In-Time Access (JIT)](/keeperpam/privileged-access-manager/just-in-time-access-jit.md) framework. Before configuring Privileged Cloud, ensure the following prerequisites are met: * A [Keeper Secrets Manager application](/keeperpam/privileged-access-manager/getting-started/applications.md) is configured and operational * A [KeeperPAM Gateway](/keeperpam/privileged-access-manager/getting-started/gateways.md) is deployed and can reach the identity provider APIs * [Workflow](/keeperpam/privileged-access-manager/just-in-time-access-jit/workflow.md) is enabled for approval and time-bound access * A [PAM Configuration](/keeperpam/privileged-access-manager/getting-started/pam-configuration.md) exists for a supported identity platform ### What must already exist Before rollout, confirm the following objects already exist in your environment: * The target user exists in both Keeper and the identity source * The target group, role, or entitlement already exists in the identity platform * The target cloud account, tenant, or application already trusts that identity platform * The Gateway has outbound network access, DNS resolution, and HTTPS connectivity to the required endpoints If you use federated access, confirm the trust relationship between the target platform and the external identity provider is already working before enabling Privileged Cloud. ### Installing the Keeper Gateway The [KeeperPAM Gateway](/keeperpam/privileged-access-manager/getting-started/gateways.md) runs inside your managed network and executes the identity-side changes required for JIT elevation. Deploy the Gateway on Docker, Linux, or Windows in each network segment that must reach the target identity platform or managed resource. ### Identity modes Privileged Cloud supports two identity modes. When a request is submitted, KeeperPAM applies the elevation through one of the following paths: * **Direct identity mode** — KeeperPAM communicates directly with the identity system defined in the PAM Configuration. Use this when the target platform manages its own identities and roles. * **Federated identity mode** — KeeperPAM routes the request through a separate identity provider configuration. Use this when the target platform relies on an external IdP for authentication or entitlement mapping. In federated identity mode, enable **Federated Identity** on the PAM Configuration and select the separate PAM Configuration that points to the external IdP. This allows KeeperPAM to apply the temporary identity change in the federated directory, then let the target platform evaluate that change through its normal SSO or federation path. See [Supported Identity Platforms](#supported-identity-platforms). In the example below, an AWS PAM Configuration uses a Microsoft Entra ID PAM Configuration for federated identity mode. If **Federated Identity** is not enabled, AWS IAM remains the identity system used for elevation.
{% hint style="info" %} A PAM Configuration cannot link to itself as the identity provider. {% endhint %} ### What actually happens 1. An admin configures JIT and Workflow on a PAM resource. 2. The record is shared with eligible users. 3. A user selects **Request Access**. 4. An approver reviews the request. 5. After approval, KeeperPAM adds temporary membership or role assignment in the identity platform. 6. The user launches the target console, application, or workflow during the approved window. 7. When the window ends, KeeperPAM removes the temporary access automatically. ### PAM Cloud record The PAM Cloud record is used when access to a cloud account, tenant, console, or federated application is controlled through a supported identity platform. It allows admins to map a requestable Keeper record to the correct group, role, or entitlement in that platform. See [Configure and Elevate Access for a PAM Cloud Resource](/keeperpam/privileged-access-manager/just-in-time-access-jit/keeper-privileged-cloud/configure-and-elevate-access-for-a-pam-cloud-resource.md).
### Configure and share the PAM resource Before a user can receive temporary access, the record owner must configure both JIT and Workflow on the record. This includes the access duration, approval path, target group or role, and which users can request access. The owner then shares the record with eligible users so they can request elevation.
To request access, the user must already exist in the identity platform and in the Keeper tenant. Once the record is shared, the user can request the temporary entitlement mapped to that record.
Once the record is configured and shared, the user can request access. See [User Requests Access](#user-requests-access). ### Configure elevation and access Each PAM resource that uses Privileged Cloud must have both JIT and Workflow configured before users can request access. #### **Configuring JIT Settings** JIT settings define which group, role, or entitlement is granted when a request is approved. For group-based access, the configured group name must match the target group in the identity platform. For role-based access, the mapped role or assignment must already exist on the target platform. #### **Workflow Settings** Workflow settings define the approval and governance controls the requester must satisfy before access is granted. A record can enforce access duration, required approvals, justification, and ticket number collection. This helps align JIT elevation with IAM governance and ITSM processes. ### Accessing a Resource After Elevation Once access is approved, users can access the target resource through Keeper's Remote Browser Isolation (RBI) or through the organization's standard authentication workflow. With RBI, the user launches the protected application directly from the Keeper Vault in an isolated browser session. Users can also access the platform through the same SSO, console, CLI, Terraform, or SDK workflow they normally use. For example, AWS IAM Identity Center users can sign in through the standard AWS access portal. CLI and automation users can continue using their normal login flow if that workflow evaluates the temporary role or group assignment. Because KeeperPAM applies temporary elevation in the identity layer, the user can assume the approved role or receive the approved entitlement only during the approved window. When the access duration expires, KeeperPAM revokes that elevated access automatically. ### Access Workflow The following workflow applies to PAM Cloud, PAM Machine, and PAM Database records that use identity-based elevation. In this example, a PAM Cloud record is configured for access and shared to an end user, who then requests access. ### User Requests Access Once a PAM resource is shared and JIT and Workflow are configured, the user can submit an access request from the Keeper Vault or from Commander. In the example below, the user locates the PAM Cloud record in their Vault and clicks Request Access.
The request is routed to the designated approver or approvers. Notifications are sent through the Keeper notification center. The requester receives an update when access is approved or denied. The requesting user can also check the approval status, send the approver a reminder, or cancel the request.
### **Approver Reviews the Request** Approvers receive real-time notifications across all Keeper clients, including mobile. The approver can review and act on the request directly from their device. * Approval triggers KeeperPAM to perform the configured JIT action in the target identity platform or resource * Denial resets the record status to **Request Access**, allowing the user to resubmit if needed Pending requests are visible to approvers in the Notifications panel (the bell icon in the upper right portion of the Keeper Vault).
### **User is Granted Privileged Access** Once the request is approved, KeeperPAM grants the configured temporary group membership, role assignment, or resource-level privilege. The user can now click **Launch** to open the target resource through the Keeper Vault. When the approved access duration expires, KeeperPAM automatically removes the temporary privileged access. In the example below, the approver has granted access to the PAM Cloud record and the user can launch a remote browser session to the AWS console with elevated permissions.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.keeper.io/keeperpam/privileged-access-manager/just-in-time-access-jit/keeper-privileged-cloud.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.