PolicySync: Attribute-Based Access Control

This feature is being rolled out to all Advanced Server Access customers through Q1 2023. No action is required on your part to enable this feature for your Advanced Server Access team.

Advanced Server Access teams often assign resources to projects grouped by product or team. For example, you might have separate projects for your accounting, marketing, and engineering teams. The standard method to grant users access to a server in Advanced Server Access is to enroll the server in a project, assign the users to a group, and add that group to the project. This grants the members of the group access to all the servers that are enrolled in the project.

However, there's often a need to grant users access to a subset of servers in a project. You might have a team of database administrators that need access to all the database servers, regardless of which project a server is enrolled in. In this case, creating a separate project that only contains database servers would break the model of grouping resources by teams. Okta PolicySync enables Advanced Server Access administrators to apply Attribute-Based Access Controls to user groups, which can be used to provide role-based access to resources. This is accomplished by applying labels to servers and selectors to groups, similar to how clients use label selectors to identify objects in Kubernetes.

Note

The PolicySync feature grants access to servers based on label selectors. The Project Group settings (admin or user access options and any sudo entitlements bound to the project group) control the actions that the user can perform. In particular, sudo entitlements assigned to a user are based on all sudo assignments assigned to project groups that the user is a member of. It's best practice to limit the actions a user can perform with sudo assignments. This ensures that sudo entitlements are only configured on the project group to which the user is assigned.

Note

When PolicySync is enabled in a project, a .asa_authorized_principals file is created for each user, containing the unique Advanced Server Access server ID. If the project has bastions behind a load balancer with PolicySync enabled, user connections may fail if the server ID from the connection request doesn't match the one in the .asa_authorized_principals file. Okta recommends that you don't enable PolicySync on the bastions behind a load balancer.

PolicySync concepts

There are three main concepts used with PolicySync: Authorized principals files, labels, and selectors. The following sections detail each of these concepts.

Authorized principals file

Okta PolicySync uses the OpenSSH daemon (sshd) AuthorizedPrincipalsFile configuration option. See sshd_config for more information on AuthorizedPrincipalsFile.

When PolicySync is enabled, the Advanced Server Access server agent creates the file .asa_authorized_principals in the home directory of each user, on each server that they have access to. You can change where this file is created by setting the AuthorizedPrincipalsFile option in your Advanced Server Access server agent's sftd.yaml configuration file. To configure the location, you must use one of the supported per-user tokens:

  • %h: This expands to the user's home directory path.
  • %u: This expands to the user's username.
  • %U: This expands to the user's UID.

For example, to configure Advanced Server Access to create the authorized principals file in the user's home directory, add the following to a server's sftd.yaml configuration file:

AuthorizedPrincipalsFile: "%h/.asa_authorized_principals"

The Advanced Server Access server agent also updates the server's sshd_config file with the AuthorizedPrincipalsFile directive as defined in sftd.yaml.

Note

While the Advanced Server Access server agent, sftd, modifies sshd_config, it's highly recommended that you do not modify it, either manually or through automation. Modifying the contents of sshd_config can lead to unsupported or broken configurations.

Labels

Labels are applied to individual servers and allow Advanced Server Access teams to categorize and sort server access. You can apply a maximum of 50 labels to a server.

Labels are stored in a key:value format to allow more flexibility for teams. For example, a server might have two labels, env:prod and region:US. As labels can originate from multiple sources, Advanced Server Access automatically adds a prefix to identify the source of the label. If the env:prod label originated from the Advanced Server Access API, the api prefix appears as api.env:prod. This avoids conflicts if the same label was added from multiple sources, which can happen if a label was specified by both the API and an Advanced Server Access server agent configuration file.

Server selectors

Server selectors are applied to groups and control which servers are available to members of the group. A maximum of 10 server selectors are available per group linked to a project. Server selectors have the following characteristics:

  • Users in a group with selectors only have access to servers that meet all the requirements of that selector.
  • Users who belong to multiple groups have access to servers that belong to the union of the selectors of those groups.
  • Selector keys can optionally specify the label's source.
    • If the source is included, then only servers that include the label from that source matches. For example, if you use the selector sftd.role=db, only servers whose sftd.yaml configuration file contains the label role: db will match.
    • If the source is omitted, then any server that contains the specified label matches. For example, if you use the selector role=db, any servers with the label aws.role: db or sftd.role: db will match.
Note

Carefully consider the configuration of your labels and selectors. Ensure that your users have network connectivity to servers in their projects using Advanced Server Access gateways, if required, based on your network topology.

Use labels and selectors for granular server access

Prerequisites

To use labels and selectors in your Advanced Server Access project, the following must be true:

  • The PolicySync feature flag must be enabled for your Advanced Server Access team.

  • The servers in the project must be running Advanced Server Access server agent version 1.52.1 or later.

Add a label to a server

Teams can add labels from the Advanced Server Access dashboard. Also, teams can add labels directly to the server agent configuration file (sftd.yaml). See PolicySync Labels.

  1. Open the Advanced Server Access dashboard.
  2. Click Projects and open a project.
  3. Go to the Servers tab.
  4. Click the gear gear icon. icon beside the server and select Edit Labels.
  5. Enter one or more labels in the Add or Remove Labels field, pressing Enter on your keyboard after entering each label.
    Note: Labels must follow the key:value format.
  6. Click Submit to save the labels.

Add a server selector to a project group

Teams can assign selectors at the project group level. To assign a selector:

  1. Open the Advanced Server Access dashboard.
  2. Click Projects and open a project.
  3. Go to the Groups tab.
  4. Click the gear gear icon. icon and select Edit.
  5. Under Server Access, select Specific Servers.
  6. Enter one or more labels in the Server Selector Tags field, pressing Enter on your keyboard after entering each label.
    Note: Labels must follow the key:value format.
  7. Click Update Group to save the selectors.

Related topics

Configure the Advanced Server Access server agent