Settings¶
Note
Access to Cluster Manager settings is restricted to SYSADMIN users.
Security¶
Password Policy¶
The Cluster Manager supports password policies to ensure that passwords for local accounts match configurable security standards. With a password policy, the system administrator can specify the minimum length of a password and can require that a password contain a mix of upper and lower case characters, digits, or symbols. Any changes to a policy will apply only when new passwords are created; previously created password will remain valid.
Password Requirements¶
Password requirements allow the system administrator to define a set of rules that enforce password strength. Weak passwords may result in unauthorized access and/or exploitation of the application’s resources.
|
Password Length Password length must be between the given minimum and maximum values. Strong password should contain at least 8 characters. |
aA |
Character Case Indicates whether passwords must contain a mix of upper and lower case characters (e.g., a-z, A-Z). Strong password should contain both. |
01 |
Digits Optionally requires passwords to contain at least one number (e.g., 0-9). Strong password should contain at least one digit. |
!@ |
Symbols Optionally requires passwords to contain at least one symbol (e.g., |
Account Lockout¶
When activated, this option enables the system administrator to define a maximum number of failed login attempts before the account is locked. When a user account has been locked, a message will appear on the login page, and the user will be asked to contact a system administrator. The system administrator can then change the user’s password to unlock their account.
Authentication¶
SAML 2.0 Configuration¶
The Cluster Manager can be integrated with a SAML 2.0 directory. The system administrator can specify connection parameters and account mapping. Once activated, users will be given access based on the user accounts defined in the SAML directory. Accounts with a system administrator role can log in using their local passwords, which enables them to administer the cluster even if there is a problem with the SAML configuration. System administrators will need to log in using the special login page by accessing the /login/admin link at the top of the main login page. System accounts (i.e., accounts with no interactive login) can always gain access using API keys.
Once SAML 2.0 has been configured, the SYSADMIN can login using the page mentioned above with the local system password set in the Cluster Manager, or using the regular SAML Login flow if the username matches the user provided by the IdP.
If a user is enabled in SAML but disabled in cluster manager, a redirection to the error page will be performed and, a log in the system will indicate the cause.
After configuring SAML 2.0 as the Authentication Provider, the username attribute mapping will be employed to associate existing users. Any user not found in the system will be treated as a new user. If it is necessary for existing users to match the format of new usernames, system administrators can rename the users to the desired format in the user table.
When selecting the ID Format from the Identity Provider, make sure to select one of the following:
Persistent:
urn:oasis:names:tc:SAML:2.0:nameid-format:persistentEmail:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Connection¶
Identity Provider SSO URL |
This is the URL where the Identity Provider provides the endpoint to send authentication requests.
|
Identity Provider ID |
The Identity Provider ID identifies the authentication server in the SAML 2.0 protocol. The Cluster Manager will make sure that authentication response are issued by a provider matching this ID, otherwise the authentication request will be rejected.
|
Request Binding |
Preferred method to perform the authentication request from the Cluster Manager to the Identity Provider. Azure, JumpCloud, Google and Okta does support any of the following values.
|
Service Provider ID |
The Service Provider ID identifies the Cluster Manager in the SAML protocol. It is passed as the
|
Cluster Manager base URL |
This field indicates the base URL to receive the authentication responses. It must specify the base URL that can be accessed from the browser when the identity provider has authenticated a user using a POST command. The Cluster Manager generates a default value based on the URL where it is deployed, for example The complete endpoint URL consists of this base URL and the When configuring the Identity provider:
|
Mapping¶
A claim is a piece of information about a user or entity. Claims are used to represent various attributes, such as name, email address, first name, last name and username. The mapping configuration is used to match the claims coming from the Identity Provider into Cluster Manager. Email and Username are mandatory mappings, and usually they can be the same claim.
SAML claim for the Email
|
|
Username |
SAML claim for the username, it should be unique. In many instances, the email assertion serves as an attribute to uniquely identify users. |
First name |
SAML claim for the first name
|
Last name |
SAML assertion for the last name
|
Certificates¶
When the Identity Provider replies to the authenticated request, claims are returned as digitally signed XML assertions. In order to ensure response integrity, you can include the digital certificates provided by the IdP used to verify the assertions. The certificates must adhere to the X.509 standard.
In order to add a new certificate click on this button and copy and paste the certificate provided by your identity provider. When more than one certificate is required, new field for certificates can be added clicking on the same button.
If a certificate field was added by mistake, it can be removed by clicking on the trash bin icon.
The Identity Provider has established expiration dates for the Certificates, making it crucial to regularly verify these expirations and keep the Certificates list in the settings up-to-date.
Upload IdP metadata¶
The Identity Provider (IdP) typically provides a metadata XML file that contains essential information about the IdP’s configuration and capabilities. This XML can be used to automatically configure the following properties, if they are provided: Identity Provider SSO URL, Identity Provider ID, Request Binding and Certificates.
To upload a metadata file, click on this button. A new dialog will be displayed, allowing you to upload a valid XML file.
After selecting a metadata file, click on UPLOAD. If the metadata file is valid, the information will be loaded into the corresponding fields. Otherwise, a specific error message will be displayed.
Download Metadata¶
Some Identity providers, such as JumpCloud, support the upload of a Service Provider XML Metadata file. The Cluster Manager provides the capability to generate this file by clicking on this button. The following information is generated based on the SAML Protocol:
EntityDescriptor - entityID (Service Provider ID)Consumer service - location (Cluster Manager base URL + /api/vi/saml2/callback)Consumer service - binding (urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST)AttributeConsumingService - RequestedAttributes (firstName, lastName and email)
View Metadata configuration¶
If the Identity Provider does not support uploading a metadata file, the properties mentioned above can be reviewed and copied manually by clicking on this button.
Case sensitivity¶
Configure case sensitivity for SAML configuration.
Disable username case sensitivity |
Defines if usernames are case-sensitive. By default, case sensitivity is enabled so that users with different uppercase and lowercase letters are handled as different users. For example, |
Validate case sensitivity |
When disabling the case-sensitivity configuration, you need to make sure that existing usernames do not generate conflicts. For example, if you had 
|
Logout¶
Configure logout for SAML configuration.
Logout page URL |
Defines the URL of the page to redirect to when the user logs out. If not defined, the user is redirected to |
Command line login for SAML with grbcluster¶
If the cluster manager is configured for SAML Authentication, it’s essential to follow the authorization flow for secure access.
When you initiate the login process, the cluster manager will generate a unique URL along with a Device ID Code. By default, this action will automatically open a web browser for your convenience. However, if you wish to disable this automatic browser launch, you can use the --no-browser flag.
The login operation itself must be conducted within the web browser. It’s important to clarify that this web browser doesn’t have to be on the same machine where the login was initiated. You can access it from any device that has connectivity to the cluster manager. This flexibility ensures that you can perform the authorization operation from a location that is most convenient for you.
LDAP Configuration¶
The Cluster Manager can be integrated with a Lightweight Directory Access Protocol (LDAP) repository. The system administrator can specify connection parameters (including the use of LDAPS for encrypted communication), account filtering, and account mapping. Once activated, users will be given access based on the user accounts defined in the LDAP server.
Accounts with a system administrator role can log in using their local passwords, which enables them to administer the cluster even if there is a problem with the LDAP configuration. System administrators will need to log in using the special login page by following the “System Administrator Log in” link at the top of the main login page. System accounts (i.e., accounts with no interactive login) can always gain access using API keys. The Cluster Manager continually synchronizes user accounts with the LDAP server in the background.
If a given user account is no longer mapped to the LDAP filter in place, it will be disabled. In particular, if an account was created before the integration with the LDAP server and if it is not mapped to the defined LDAP filter in place, it will be disabled. The same policy will apply during migration from local accounts to LDAP. Two important exceptions are system administrator accounts and system accounts, which will not be disabled for this reason.
Connection¶
LDAP Server host |
Specifies the Host name or IP address of your organization’s LDAP server. |
LDAP Server port |
The LDAP server port. The default port is |
Bind DN and password |
The admin Bind DN and password, which allow the LDAP connection to gain access to the directory. Ex:
|
Encryption - LDAPS |
LDAPS is the “LDAP over SSL” protocol, which communicates over a secure port such as 636.
It establishes a secure connection before any communication is performed with the LDAP server.
Check the 
This is used to set up the LDAPS directory. The Disable Certificate Validation box determines whether LDAPS will validate certificate signatures. When activated, no validation will be performed, which is insecure. |
Test connection |
The TEST CONNECTION button is used for testing your parameters to the LDAP server. If you cannot connect to the LDAP server, user mapping and filtering will fail as well. |
Filters and Mapping¶
Base DN |
The base DN subtree that is used when searching for user entries on the LDAP server. |
Filter template |
Filter for finding entries in the LDAP base DN (groups) subtree that match the group name. The Ex: |
Unique Username Attribute |
Used for mapping the unique username identifier. If no unique username attribute is specified, it will default to using Ex: |
Firstname and Lastname |
LDAP attributes for user first name and last name. Firstname ex: Lastname ex: |
Email Attribute |
LDAP attribute for user email. Ex: |
Test Mapping |
To make sure that user IDs, real names, email addresses, and groups have been mapped correctly, click on the 
|
Test Login |
As a final test, to ensure users can log in, the TEST LOGIN button prompts for a username and password and ensures that this user can be successfully authenticated with the LDAP server. 
|
Synchronization¶
Configure synchronization between the LDAP server database and the Cluster Manager database. The synchronization with the LDAP server is a background process that runs at the given frequency. At each iteration, it will synchronize a given number of users, i.e. batch size, that have not been synchronized for at least the given minimum duration (Minimum age). These parameters help tune the synchronization to avoid overloading the LDAP server with too many requests.
Minimum Age |
Accounts already synchronized within this time limit will not be synchronized. |
Frequency |
Frequency of the background synchronization. |
Batch |
The field above defines the synchronization batch size. |
Case sensitivity¶
Configure case sensitivity for LDAP configuration.
Disable username case sensitivity |
Defines if usernames are case-sensitive. By default, case sensitivity is enabled so that users with different uppercase and lowercase letters are handled as different users. For example, |
Validate case sensitivity |
When disabling the case-sensitivity configuration, you need to make sure that existing usernames do not generate conflicts. For example, if you had
|
Logout¶
Configure logout for SAML configuration.
Logout page URL |
Defines the URL of the page to redirect to when the user logs out. If not defined, the user is redirected to |
Local Configuration¶
The authentication configuration for local authentication managed by the Cluster Manager.
Case sensitivity¶
Configure case sensitivity for LDAP configuration.
Disable username case sensitivity |
Defines if usernames are case-sensitive. By default, case sensitivity is enabled so that users with different uppercase and lowercase letters are handled as different users. For example, |
Validate case sensitivity |
When disabling the case-sensitivity configuration, you need to make sure that existing usernames do not generate conflicts. For example, if you had
|
Logout¶
Configure logout for SAML configuration.
Logout page URL |
Defines the URL of the page to redirect to when the user logs out. If not defined, the user is redirected to |
System¶
System - Authentication¶
|
Interactive session duration (minutes) When users are authenticated with an interactive login, a session token is created (JWT) to grant access for a specific duration. When the token expires, the user must reauthenticate. Authentication cache max age (secs) Authenticating users or applications through an interactive login or API key requires access to the database. A cache is used to make this process more efficient. Cached entries expire once they reach the specified maximum age. Some actions such as disabling a user or an API key will only take affect once this maximum age has been reached and all cached copies have been discarded. |
Data Management¶
|
Incomplete object expiration (hours) Due to networking or client issues, some objects (e.g., model files) may not be completely uploaded. A background process deletes these incomplete entries after the specified expiration time has elapsed. History expiration (days) Jobs and batches are deleted in the background when they expire. Note that if the number of jobs and batches to delete is very large, these deletions will be performed in blocks to avoid overloading the database. History cleanup batch size When jobs have reached their expiration period, they will be deleted by blocks. This parameter configure the block size for the deletion process. This needs to be tuned according to the usage pattern. If the block size is too small, the process may not be able to keep up with the deletion. If the block size is too large, it may overload the database. Metrics expiration (days) Metrics are deleted in the background when they expire after the selected number of days, it is recommended this setting to be equals to History expiration (days) Metrics refresh interval (seconds) Metrics are stored with the Max value pulled within the refresh interval, change this setting to poll faster the metrics and have more precision on the stored metrics. |
