Okta Privileged Access
Okta Privileged Access is a Privileged Access Management (PAM) solution designed to help customers mitigate the risk of unauthorized access to resources, a critical area of security and risk management in any organization. Okta Privileged Access builds on the current server access control capabilities provided with Okta Advanced Server Access and delivers a unified approach to managing access to all your privileged accounts. It securely connects people, machines, and applications to privileged resources such as servers, containers, and enterprise apps.
A critical capability that Okta Privileged Access offers is the separation of administrative roles and responsibilities. Management of users and groups, resources, and security are separated, with each administrative role designed to perform a specific function. For example, the management of security policies to access resources is separated and decoupled from the administration of the resources. To meet this requirement, the team that sets the policy is separated from the team that administers the resource. Likewise, the administrator managing users and groups can only perform user and group management tasks and isn't involved in administering resources or creating security policies.
Roles and permissions
The level of access within a Okta Privileged Access team depends on the role that you're assigned and the permissions granted to that role. The table below discusses the types of roles, and each has a unique set of permissions and restrictions.
| Role | Description |
|---|---|
| PAM admin | The role with the highest privilege in Okta Privileged Access. The only function of PAM administrator is to assign administrative roles to Okta Privileged Access groups and users. |
| Resource admin | Allows group members to administer project resources. They can create, update, or delete resource groups and assign one or more user groups as owners of a resource group. Also, they have implicit list permissions across all secret folders. |
|
Delegate resource admin |
Can manage projects in the context of a resource group assigned to them. Also, they have implicit list permissions for secret folders within the resource groups they're delegated to. |
|
Can create one or more Okta Privileged Access security policies to control access to the team's privileged accounts and resources. |
|
|
Delegated security admin |
Can create and update policies that apply to resource groups that they're assigned as security admins. |
|
Can view and access resources granted by security policies. Every user who is assigned the Okta Privileged Access app in the Admin Console is assigned this role. |
Components
A Okta Privileged Access deployment contains a combination of the following components:
| Components | Description |
|---|---|
| Clients | The Okta Privileged Access client is a command-line tool installed on a workstation. After a user installs and enrolls the client in an Okta Privileged Access project, the client provides access to server resources enrolled within the same project. |
| Groups |
A group is a collection of users with some set of associated permissions. Two default groups are created for each team: everyone and owners. A group can have one or more team roles assigned to it. Every member of a group inherits the assigned roles. |
| Projects |
Projects exist within resource groups and are administrative boundaries that contain resources and have a set of configuration options such as server tokens, account discovery, password settings, and SSH configuration. Currently, the supported resources within a project are servers and server accounts |
| Policy | A security policy controls which groups (principals) are granted privileged access to resources. |
| Principal | Users and groups that are associated with the policy and are granted access to the matched resources. It can be local groups created in Okta Privileged Access or groups that are synchronized from Okta. The policy applies to any new users added to the group. |
| Resource groups |
A resource group is an administrative boundary that has one or more projects that the owners of the resource group can manage. See Resource groups |
| Resources | Resources are servers and other entities that the end users can access. See Security policy. |
| Servers | The Okta Privileged Access server agent controls SSH (Secure Shell) and RDP (Remote Desktop Protocol) access to remote servers enrolled in an Okta Privileged Access project.
A server is only enrolled in a single project. Teams can automatically enroll servers into projects with an associated cloud account, or manually with an enrollment token. |
| Service user | Service users are special accounts not tied to a real person. Teams can use a service user to automate actions using the Okta Privileged Access API or to grant access to specific operations in the Okta Privileged Access platform. |
| Teams |
A team is a top-level container for your organization’s Okta Privileged Access instance. Each team has a unique name and an associated Identity Provider (IdP). There can only be a single team associated with an Okta org and the team name must be unique across all Okta Privileged Access customers. All other configuration objects in Okta Privileged Access are scoped to a specific team. |
| Users |
A user is a person who belongs to a team and authenticates with that team's Identity Provider. Okta Privileged Access defines user permissions based on group memberships. Users authorize clients to be added to their client inventory so that they can receive credentials. |