# Entitlements Visibility {% hint style="info" %} This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the [StrongDM Help Center](https://help.strongdm.com/hc/en-us). {% endhint %} ### Overview The StrongDM Admin UI provides admins with a comprehensive view of all entitlements that exist for a user. Entitlements visibility enables admins to know who has access to which resources and why at any given point in time. In the case of entitlements, access to a resource means being able to connect to a resource (as opposed to being able to request access to a resource). Entitlements are shown for users, resources, and roles in a tab called **Entitlements** in the following areas of the Admin UI: * **Principals** > **Users** * **Resources** * **Roles** The **Entitlements** tab helps admins to easily identify entitlements that exist in StrongDM. Entitlements visibility allows admins to review, audit, and make access decisions confidently. It helps to reduce the risk of over-provisioning and having compliance gaps. ### Use Cases Common use cases for using entitlements visibility include the following: * User entitlements insight: Admins want to see a breakdown of a user’s entitlements across resources, including access type, source, and last-accessed timestamps. * Resource entitlements insight: Admins want to see a list of users that have access to a specific resource and why they have access. * Role entitlements insight: Admins want to know what entitlements a particular role gives. ### User View of Entitlements To view a user's entitlements in the Admin UI, go to **Principals** > **Users**. Select the user and click on the **Entitlements** tab. A table displays all the resources that the selected user is entitled to access, with the following fields. | Property | Description | Example | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | | **Access From** | Start timestamp of the access grant; this field is blank for standing access granted by role membership | `Mar 8, 2025 11:15 AM` | | **Access Type** | Type of access, either permanent (via role membership) or temporary (due to an access request or admin assignment) | `Permanent` | | **Access Until** | End timestamp of the access grant; in the case of permanent access, this field is empty | `Mar 12, 2025 12:00 PM` | | **Granted By** | Details on what (role or access workflow) gave access | `Example Role` | | **Hostname** | Resource hostname | `example.com` | | **Last Accessed** | Last accessed timestamp; this field is empty if the user never accessed the resource | `Mar 16, 2025 1:45 PM` | | **Mapped Identities** | Identity or identities that a user assumes when accessing a resource, linking their primary identity to the account or role used on the target system; for Kubernetes resources, mapped identities represent privilege levels (Kubernetes groups assigned to the user for requests made to the cluster through StrongDM); note that mapped identities are distinct from Identity Aliases | `alice-glick` | | **Name** | Resource name | `Example` | | **Reason for Access** | How access was granted to the user (for example, role assignment, admin assignment, or access workflows) | `Role` | | **Type** | Resource type | `Redis` | ### Resource View of Entitlements To view all entitlements for a resource in the Admin UI, go to **Resources**, select the resource type (for example, **Servers**), and select the desired resource to view. Click on the **Entitlements** tab to view a table of all the users that are entitled to access the resource. The table has the following fields. | Property | Description | Example | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | | **Access From** | Start timestamp of the access grant; this field is blank for standing access granted by role membership | `Mar 8, 2025 11:15 AM` | | **Access Type** | Type of access, either permanent (via role membership) or temporary (due to an access request or admin assignment) | `Permanent` | | **Access Until** | End timestamp of the access grant; in the case of permanent access, this field is empty | `Mar 12, 2025 12:00 PM` | | **Granted By** | Details on what (role or access workflow) gave access | `Example Role` | | **Last Accessed** | Last accessed timestamp; this field is empty if the user never accessed the resource | `Mar 16, 2025 1:45 PM` | | **Mapped Identities** | Identity or identities that a user assumes when accessing a resource, linking their primary identity to the account or role used on the target system; for Kubernetes resources, mapped identities represent privilege levels (Kubernetes groups assigned to the user for requests made to the cluster through StrongDM); note that mapped identities are distinct from Identity Aliases | `alice-glick` | | **Name** | User name | `Glick, Alice` | | **Reason for Access** | How access was granted to the user (for example, role assignment, admin assignment, or access workflows) | `Role` | | **Type** | User type (user or service account) | `User` | ### Role View of Entitlements To view all entitlements for a role in the Admin UI, go to **Principals** > **Roles**, select the role from the list, and click on the **Entitlements** tab to view a table of all the roles that are entitled to access the resource. The table has the following fields. | Property | Description | Example | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- | | **Hostname** | Hostname | `https://dev.example.com` | | **Last Accessed** | Timestamp of the last time the resource was accessed by *any* user, not just a user in this role; this field is empty if the resource was never accessed | `Mar 16, 2025 1:45 PM` | | **Mapped Identities** | Identity or identities that a user assumes when accessing a resource, linking their primary identity to the account or role used on the target system; for role entitlements, these mapped identities come from the role's access rules; for Kubernetes resources, mapped identities represent privilege levels (Kubernetes groups assigned to the user for requests made to the cluster through StrongDM); note that mapped identities are distinct from Identity Aliases | `devops` | | **Name** | Role name | `Dev-k8s` | | **Type** | Resource type | `Kubernetes` | ### Entitlements Options This section describes the options available on the **Entitlements** tab for users, resources, and/or roles. #### Remove role The **Remove role** button provides the option to remove a user from the role that gives access the given resource. Some common reasons to remove a user from a role include when the user has never accessed the resource they are entitled to access, or the last time they accessed it was a long time ago. To remove the user from a role, click **Remove role** and then confirm. Once you confirm, the user is removed and they no longer have access to the resource. #### Search, filter, and sort You may use the **Search** bar to find a specific resource or user quickly. You may also sort and filter the results using the following filters: * Reason for Access * Granted By * Access Type * Last Accessed * Type (resource type) #### Download CSV The **Download CSV** button allows you to export entitlements data in CSV format. You can export either all rows of data or only filtered rows shown on the **Entitlements** tab. The fields present in the downloaded CSV file are the same as the fields for the user view of entitlements, the resource view of entitlements, or the role view of entitlements. #### Add temporary access The **Add temporary access** button allows you to grant the selected user temporary access to a specific resource for any duration. The duration is the amount of time that the user will have access to the resource, in minutes, hours, or days. The duration settings let you set the time zone, date range, and the amount of time (30 minutes, 1 hour, 4 hours, until 5pm, until tomorrow, until end of week, or custom) before the access expires. ### Additional Information #### Reason for access The only valid reasons for access are role assignment, admin assignment, or access workflows. Note that policy cannot solely grant or revoke entitlement, and policies in the policy editor won't affect the set of resources that are shown in entitlements. For example, if you have a policy statement such as the following, that policy won't, by itself, grant every user access to connect to every resource. Users still need role membership or an access grant to be able to connect. ```cedar permit ( principal, action == StrongDM::Action::"connect", resource ); ``` Similarly, the following policy statement prevents users from connecting to resources, but it won't cause entitlements to be removed from the entitlements view. ```cedar forbid ( principal, action == StrongDM::Action::"connect", resource ); ``` See the StrongDM documentation to learn more about how to set up users and resources in StrongDM. --- # Agent Instructions: 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.strongdm.com/admin/access/entitlements-visibility.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.