Application Access
Overview
Some Qarbine features may not be available based on the edition, release level, and other factors.
Access to Qarbine is managed through Principals. Principals include permissions on what tools and what parts of the catalog they can access. As a convenience multiple Principals can belong to an “Access Group'' which defines these permissions. Below is the table listing the initial Qarbine Principals and their usage.
| Account | Usage | Permission Comment |
|---|---|---|
| q_compute | Initial sign on | Should only be used to obtain an API key that is used by other endpoints. |
| q_admin | Sign on | |
| q_runner | Access group | May only run components. |
| q_user | Access group | May read the example folder.May read\write the public folder.Pro Plus tool access. |
| q_pro | Access group | May read the example folder.May read\write the public folder.Pro tool access. |
| q_pro_plus | Access group | May read the example folder.May read\write the public folder.Pro plus tool access. |
| developer | Initial sign on | References q_user access group which has ProPlus tool access. |
| guest | Initial sign on | References q_pro access group which has Pro tool access. |
Note - A compute node using a bootstrapURL with an account and password must have its associated Qarbine principal defined with the CSV tags containing “computeNode”. This is not required when the apiKey parameter is used.
Managing Principals
Principals are listed in the Principals tab.
The first type of a Principal is one that defines all of the permissions inclusively.
The second type of a Principal is one where the permissions are defined by an access group.
The third type of a Principal is one that acts as an Access Group. Other principals refer to this principal to obtain their permissions.
The permissions of a principal can be segmented by
- active state,
- tool access,
- data service access,
- catalog access,
- timeframe access and
- network access.
Defining a Principal
When you define a principal you provide an initial password and whether the user must subsequently change it. This is done in the area shown below.
Principals can be used as the basis for programmatic access using API keys. This is done in the area shown below.
You can associate generic tags to a principal which are accessible using the signedOnTags() macro function. This list can be used to control template processing.
Active State
Principals can easily be activated and deactivated by adjusting the field shown below.
If this applies to an access group then many principles may be affected.
Tool Access
Access to tools is set using the drop down shown below.
The permission levels are described below.
Data Service Access
Data services define on what compute node data queries run and their eventual endpoints. The visible data services are set in the list shown below.
Elements are removed using the right click pop up menu.
Catalog Access
All principals have a private catalog folder. Access to other folders is set in the area shown below.
Catalog groups are a convenient way to aggregate many catalog folders into a single object. They are described in a separate document.
Timeframe Access
You can specify that a Principal expires at a point in time using the fields shown below.
Network Access
You can restrict access based on IP addresses by setting the Principal property field shown below. The tested IP is the one observed by the Qarbine endpoint service.
This is a CSV list of values which are IP addresses and masks commonly referred to as Classless Inter-Domain Routing (CIDR) values. Below is a table of sample CIDR mappings.
| CIDR | Dotted Quad Mask |
|---|---|
| /8 | 255.0.0.0 |
| /16 | 255.255.0.0 |
| /24 | 255.255.255.0 |
| /32 | 255.255.255.255 |
To restrict access to the 192.168.1.x subnet use a CIDR value of 192.168.1.0/24. A useful CIDR calculation tool is available at https://www.subnet-calculator.com/cidr.php