Search documentation...

K

Label-Based access control

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.

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": "*",
    }
  ]
}

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 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
  • destination.labels.team refers to any team labels on destinations
  • labels.project refers to any project labels on any resources

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"
    },
  ]
}

    Need help?

    Our team is relentlessly focused on your success. We're ready to jump on a call to help unblock you.

    • Connection issues with your data warehouse?
    • Confusing API responses from destination systems?
    • Unsupported destination objects or modes?
    • Help with complex SQL queries?

    Feature Requests?

    If you see something that's missing from our app, let us know and we'll work with you to build it!

    We want to hear your suggestions for new sources, destinations, and other features that would help you activate your data.

On this page

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

Was this page helpful?