Search documentation...

K
ChangelogBook a demoSign up

Label-Based access control

Label-based access control is only available on Business tier plans.

Hightouch provides label-based access control (LBAC) to provide granular access control to resources. Workspace owners can use label to:

  • Enforce granular access control
  • Enable cleaner workspace organization
  • Unlock easier collaboration across teams and departments

What are labels?

Labels are structured as key/value pairs. For example, common keys include project, env, folder, and campaign. Values are attached to keys. Values for an env key could include dev, staging, and prod.

Labels are made of key/value pairs

You can apply labels to any top-level resources, including sources, models, syncs, etc. Labels apply across all resources in the same workspace. For example, project labels applied to models can also be used for sources.

Add labels

You can add labels to resources in Hightouch by going to any resource's overview page and clicking Add labels.

Adding labels in Hightouch

Then, enter one or more key/value pairs and click Save. Label names can include letters, numbers, spaces, underscores, and dashes.

Customer Studio only supports adding labels to audiences. Parent models, related models, and events don't support LBAC.

Filter by labels

When viewing a top-level resource page, for example, the syncs page, you can select to Filter by labels, as well as other options like which user created the resource.

When filtering by label, you can filter all resources that include or exclude particular key/value pairs or keys.

Filtering by labels in Hightouch

Label-Based access control

You can restrict access to resources based on labels by creating custom roles. Label-based access is specified through a policy's conditions property. A policy is a JSON object defining the set of actions that users can take on resources. Read the role-based access control documentation to learn more about how a policy is structured.

{
  "version": "2022-04-26",
  "policies": [
    {
      "effect": "allow",
      "actions": "read",
      "resource": "model",
      "conditions": {
        "labels.team": {
          "equals": "marketing"
        }
      }
    }
  ]
}

What are conditions?

Conditions are nested objects consisting of:

  • The resource the condition should apply to, either source, models, destination, or labels
  • A boolean statement evaluating the condition

Resources references

The following are resources you can reference in a condition:

HeaderDescription
sourceReferences the source a sync is connected to
modelReferences the model or audience a sync is connected to
destinationReferences the destination a sync is connected to
labelsReferences the label on the resource

Resources are specified with dot notation: ${resource}.labels.${label-key}.

These are some examples of how you can specify resources in a condition:

  • source.labels.project refers to any project labels on sources
  • model.labels.environment refers to any environment labels on models or audiences
  • destination.labels.team refers to any team labels on destinations
  • labels.project refers to any project labels on any resources

As explained in the Add labels section, parent models, related models, and events don't support LBAC.

Boolean statements

Once you've specified a reference, you need to write a boolean statement to complete your condition. The boolean statement is also a key/value pair. The key is the boolean operator and the value is the operand.

Hightouch supports the following operators:

OperatorDescriptionApplicable Resources
inLabel is a member of an arrayAll
notinLabel is not a member of an arrayAll
equalsLabel exactly matches patternAll
greaterthanLabel is greater than a valueAll
lessthanLabel is less than a valueAll
existsLabel refers to a resource that existsAll

The following are some example boolean statements:

  • "equals": "marketing" evaluates whether the label matches "marketing"
  • "exists": true evaluates whether the label exists
  • "in": ["Marketing", "Sales"] evaluates whether the resource's labels matches any of the items in the array

Example label-based role

In this example, the Lifecycle Team Collaborator role has access to syncs that connect to destinations that have been the label team:lifecycle.

They can create syncs, but are only allowed read-access to destinations with the team:lifecycle label. Therefore, they can only access syncs connected to destinations with that label. Specifically, they can read, update, start, enable, and debug syncs connected to destinations with the team:lifecycle label. They have full-access to audiences.

{
  "version": "2022-04-26",
  "policies": [
    {
      "effect": "allow",
      "actions": "create",
      "resource": "sync"
    },
    {
      "effect": "allow",
      "actions": [
        "read",
        "update",
        "start",
        "enable",
        "debugger"
      ],
      "resource": [
        "sync"
      ],
      "conditions": {
        "destination.labels.team": {
          "equals": "lifecycle"
        }
      }
    },
    {
      "effect": "allow",
      "actions": "read",
      "resource": [
        "destination"
      ],
      "conditions": {
        "labels.team": {
          "equals": "lifecycle"
        }
      }
    },
    {
      "effect": "allow",
      "actions": "*",
      "resource": "audience"
    }
  ]
}

Ready to get started?

Jump right in or a book a demo. Your first destination is always free.

Book a demoSign upBook a demo

Need help?

Our team is relentlessly focused on your success. Don't hesitate to reach out!

Feature requests?

We'd love to hear your suggestions for integrations and other features.

Last updated: Feb 27, 2023

On this page

What are labels?Add labelsFilter by labelsLabel-Based access controlWhat are conditions?Example label-based role

Was this page helpful?