Skip to content

Entitlements

This page describes how you can use entitlements in Insights Enterprise.

Entitlements overview

Entitlements manage a group of users’ access to specific entities in the system. When entitlements are enforced, a user can access the specific functionality provided by their Roles, but not across the entire system. Functionality is only available to users on the specific packages or data they are entitled to access.

For example: - You may have a scenario where you want to allow an end user to query data in the database, but you don't want them to see all the business logic for data transformation or analytics.

  • A pipeline builder needs the capability to edit and deploy a pipeline, but not all pipelines.

Entitlements help you achieve this. When using the entitlements feature, you must enable Encryption in transit for extra security.

Note

If another user gains entitlements to a package that contains a pipeline, that pipeline's workers also gain delegated entitlements to that pipeline’s runtime entitlements. For more information, refer to Entitlement delegation in pipeline execution context.

Types of entitlements

There are three types of entitlements you can use to control user permissions in kdb Insights Enterprise:

  • Data entitlements - control who is entitled to query data within a deployed database, this includes Stream Processor and pipelines.

    Warning

    Data and Row Entitlements are applied only on the query path. They are not currently applied when streaming data from a Stream Processor or over a WebSocket. Refer to Visualize Streaming Data.

  • Row-level data entitlements - control who is entitled to query specific rows within a table, based on a policy. Note you must have data entitlement enforced on the system to be able to enable row-level entitlements on a database.

  • Package entitlements - control the entitlement each user has to interact with packages that contain databases, pipelines, and views. Each package has its own entitlements.

Policies

Policies enable more granular, row-level data access control for users. They can be applied to each table in a database to manage row-level data entitlements. Find out more how these are configured in row level data entitlements.

Entitlement delegation in pipeline execution context

When working with pipelines in kdb Insights Enterprise, entitlement enforcement behaves differently depending on how a pipeline is deployed and accessed. This section explains how entitlements are delegated during pipeline execution, and how access to packages and workers can implicitly broaden a user’s access to data.

Pipeline execution context is tied to the deployer

Every pipeline runs with the entitlements of the user who deployed it, not necessarily the owner of the associated package. This distinction is important:

  • The pipeline inherits the data access entitlements of the deployer.

  • These entitlements are enforced at runtime across all workers in the pipeline.

Entitlements are delegated with package access

If another user gains entitlements to a package, they also gain delegated access to the entitlements the deployer of the pipeline has within the context of this pipeline.

  • These entitlements are not directly granted to the other user.

  • Instead, these entitlements are implicitly delegated through the pipeline itself.

  • As soon as the user connects to a worker within that pipeline, they enter the same security context as the deployer.

This means:

  • Workers from another package the user deploys can connect into this pipeline and run within its entitlement context.

  • Even if a user doesn't have direct entitlements to a database, they can access it indirectly through the pipeline deployer's entitlements, if they can deploy or connect to a worker in that pipeline.

The security context

Pipelines establish a security context based on the deployer's entitlements. This context governs what the workers in the pipeline can reach: typically databases or other infrastructure components.

  • As more entitlements are given to the deployer, the pipeline’s security context grows.

  • Any additional users with entitlements to the pipeline can now leverage the expanded entitlements implicitly.

For example:

A user with no entitlement to a sensitive salary database might still reach it indirectly, if they gain entitlements to a pipeline who's deployer has that database in its entitlement scope.

Data querying via APIs vs. pipelines

Entitlement enforcement differs between querying as a user and running code within a pipeline:

  • If a user queries a database through the REST API, entitlements are strictly enforced. They cannot access restricted data without explicit entitlements.

  • However, if they deploy additional workers (for example, to q processes) or connect to a pipeline, they can potentially access sensitive resources that fall within the pipeline's security context.

Summary

SCENARIO ENTITLEMENT ENFORCEMENT
Deploying a pipeline Inherits entitlements from the deployer
Connecting to a pipeline worker Gains access to the pipeline’s entitlement context
Querying through REST API Requires direct user entitlements
Accessing a database through a pipeline Indirect access based on the entitlements of the deployer of the pipeline

Next steps

You can configure entitlements using the following guides: