Scheduler performs entitlement checks before any user can call any API endpoint and interact with the data resources returned.
For much more information, read our IAM documentation. In summary, each Scheduler user must have (at least one) feature policy and data policy:
A feature policy controls access to API endpoints. This is irrespective of whether a user interacts with Scheduler by calling its REST API directly, or indirectly via a proxy such as the SDK, the LUSID web app or Luminesce (since all proxies themselves call the Scheduler REST API).
A data policy controls access to data resources returned by API endpoints.
To perform any real-world operation in Scheduler, a user must be assigned both types of policy. This is because a feature policy without a corresponding data policy yields no data, and a data policy without a corresponding feature policy cannot perform operations. Work through a tutorial.
The following table lists the data resource entitlement checks that Scheduler performs for each API endpoint. For example, consider a feature policy granting a user the right to call the ListImages API endpoint. In the corresponding data policy, you should include:
The
Repository
resource with theRead
action to grant access to read the repository.The
Image
resource with theRead
action to list any images in that repository.
API endpoint | Date resource checks | Notes | |
---|---|---|---|
Resource type | Action | ||
| N/A | N/A | This endpoint does not interact with Scheduler but rather with Docker CLI. |
|
|
|
|
|
|
|
|
|
| ||
|
|
| You cannot delete an image using the Docker CLI; you must use this endpoint. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
|
|
| You can allow an admin user to see history and results for a job even if they are not the user who originally executed the job. To do this, give that admin user these permissions. |
|
| ||
|
|
|
|
|
| ||
|
|
|
|
|
|
|
|
|
| ||
|
|
|
|
|
| ||
|
|
|
|
|
|
|
|
|
| ||
|
| ||
|
|
|
|
|
|
|
|
|
| ||
|
| ||
|
|
|
|
|
| ||
|
|
|
|
|
| ||
|
| ||
|
| ||
|
|
|
|
|
|