This article looks at the new custom labels feature in Okta Privileged Access (OPA) and how they can be used to make policy management and assignment more flexible.
This is a parity feature that was available in Okta Advanced Server Access and is now available in OPA.
Labels in Okta Privileged Access
When a server is enrolled in OPA, the system will generate a set of labels for that server.
The system will generate labels for the hostname, canonical name (if set in the agent configuration file), operating system, and os type. If the server is hosted in a cloud environment like AWS, you will also get labels pertaining to that cloud service (like the cloud_provider, aws_account_id and aws_availability_zone labels shown above). As these are system-generated, they are prefixed with system (e.g. system.hostname).
These labels are like tags and can be used to assign sets of servers to a Security Policy Rule. For example you could have a Policy Rule to apply to all Linux servers, or only those running a specific ubuntu version. Or you could have a Policy Rule that applies to all servers belonging to a specific AWS account or availability zone.
Whilst this may be enough for some OPA deployments, there has been calls to allow custom labels. For example you may want to categorize servers into PROD, UAT, DEV etc. and have different Policy Rules. Or maybe you want to have different uses of servers (e.g. DB, Web) and have different Policy Rules for the different types.
This calls for custom labels. They were available with Okta Advanced Server Access and are now available with OPA.
Defining Custom Labels
Before implementing custom labels, you should have a think about the taxonomy you want to apply. You should identify the types of labels and their possible values. That way you can define Policy Rules and then have new servers automatically assigned to them via the labels. You don’t want to have to revisit your policy rules each time you run up a new server instance.
A note of caution on using custom labels. If someone has access to the configuration file that can set labels and dictate what OPA policies apply to accessing the server. You could allow someone to access that shouldn’t and you could potentially lock out access to the server. As per the documentation “Okta recommends exercising caution when using custom labels.“
Defining the custom labels is straightforward – you add them to the agent configuration file sftd.yaml.
The file is in different locations for Linux and Windows – see Configure the Okta Privileged Access server agent in the product documentation. It talks about the file location and has a section on custom labels.
A Linux example is shown below.
In this case there are two labels – environment and function.
It is important to note that the sftd.yaml file is very sensitive to spacing. You need to make sure that there are two spaces before each label (e.g. <space><space>environment).
Custom Labels in OPA
One the agent is recycled (or it rereads the configuration file) you will see the new labels in OPA.
Notice that the new labels are prefixed sftd (e.g. sftd.environment and sftd.function). This is to distinguish them from the system-generated labels.
These labels are ready to use.
Using Custom Labels
Custom labels are no different to system-generated labels when defining policy rules.
When creating or editing a Policy Rule, if you enable the Select resources by system generated label option and click into the Add resources field, you will see the custom labels as well as the system-generated ones.
That’s it, very straightforward – add the labels to the agent configuration file and them apply the labels to policy. If you use automation to add the agent to servers, you could extend the automation scripts to set relevant labels. If you have the Policy Rules already set, there’s no additional human intervention required.
IAMSE