Package Entitlements
This page describes how package entitlements work and how to configure them.
Package entitlements control the operations a user can perform in relation to a specific package. Packages contain databases, pipelines, and views.
Note
By receiving entitlements to a package, you can connect to any worker in this package and access anything the owner of this package would be entitled to access. In contrast, by receiving entitlements to a database, you can access only data through the API and you would not be able to hop on to a worker.
All packages have their own set of entitlements and each user can have different entitlements for different packages.
Package entitlements include four access levels - All, Read, Write, Execute (ARWX):
- All - No restrictions. Full access to read, write, execute, and delete the package.
- Read - Users can view the package and download its configuration.
- Write - Users can edit pipelines, databases, and views in this package.
- Execute - Users can deploy and teardown this package.
If a user is granted either the Write or Execute access level, they also automatically receive Read access.
Important
To modify entitlements you need to either:
- have the Administrator role, or
- have the Maintainer role and own the package that contains the database.
When you create and push a package, the corresponding entitlements records are created automatically if they didn't already exist.
Implicit entitlements
In certain deployment scenarios, entitlements granted to the owner of one package can implicitly allow access to a package with a different owner. This behavior is referred to as implicit entitlements, and it applies at the package level, not the database level.
Example:
If the owner of Package A receives entitlements to read from or publish to Package B, they also implicitly “inherit” the entitlements of Package B’s owner. This is not exact inheritance — it simply means that the connection between Package A and Package B is no longer blocked. As a result, code can be deployed from Package A into Package B’s workers, and that code will run within Package B, inheriting its entitlements.
Use package entitlements
After you complete the prerequisites, you can begin providing entitlements to user groups. To do this, either follow the quickstart guide or use the configuration details.
Package entitlements in the web interface
Certain actions are only visible on packages in the web interface if you have specific entitlements:
- The package itself is only visible in the web interface if you have Read access to the package
- The Save buttons only appear if you have Write access to the package
- The Deploy/Teardown buttons only appear if you have Execute access to the package
- The Delete button only appears if you have All access to the package
Execute code with entitlements
When you execute code through .kxi.packages.load, kdb Insights Enterprise checks entitlements. You must have execute access level to load a package; without the correct entitlements on the package being loaded, the process fails.
Entitlements are applied to code loaded this way when you use the Scratchpad, a temporary q process, where you can execute UDFs, and when defining UDAs.
Logs for package entitlements
You can view logs for deployed databases and pipelines in packages that you are entitled to.