Security Configuration

QuantaStor provides a layered set of security controls: grid-wide password and login policy, role based access control over every management operation, multi-factor authentication, an integrated firewall, TLS certificate management, and endpoint detection and response agent deployment. This page covers each of them.

Many industries require compliance with government security standards covering everything from audit logging to password policies. These include Health and Human Services security standards (HIPAA), federal law enforcement security standards (CJIS), and the general standards outlined by NIST for Controlled Unclassified Information (CUI) in Non-Federal Information Systems and Organizations, covered in NIST 800-53 and 800-171.

Nearly all of the settings on this page are reached from the Security tab of the QuantaStor web management interface, which contains these sections:

Security tab section	Covers	On this page
Management Users	User accounts, password policy, multi-factor authentication	Security Settings, Users, MFA
Management Groups	User groups and their shared POSIX GID	User Groups
Management Roles	RBAC roles and their permission assignments	RBAC
Object Users & Tenants	S3/object storage users and tenants	Multitenancy
Scale-out File & Block Keyrings	Keyrings for scale-out storage	not covered here
Certificates	The grid-wide TLS certificate inventory	Certificate Management
Key Server Profiles	External key server (KMIP) profiles	not covered here
EDR Agents	Endpoint detection and response agents	EDR

Also on this page: Firewall Configuration, SSL/TLS and Web Access Security, System Setup Security Checks, Security Updates and Multi-admin Approvals.

Security Settings Management

Security Manager, General tab -- grid-wide password and login policy.

The Security Manager holds the password and login policy for the entire Storage Grid. These settings apply to all user accounts on all systems in the grid, not per-system.

Navigation: Security → Management Users → User → Security Manager (toolbar)

Choosing Suggested Defaults automatically configures the password and lockout policies to meet the standards listed above. This is the recommended starting point -- apply it first, then tune individual settings for the requirements of your deployment. Discard Changes reverts the dialog to the currently saved policy.

The General tab controls:

• Password Complexity -- the required character-class mix. The factory default is Weak; raise this for any production or compliance-bound deployment.
• Allowed Special Characters -- which non-alphanumeric characters are permitted in passwords.
• Minimum / Maximum Password Length -- both in the range 8 to 80.
• Login Attempts Until Short Lockout and Login Attempts Until Lockout -- consecutive failures before a temporary and then a permanent lockout. Set the second to 0 to disable permanent lockout.
• Bad Logins Sample Period (short and permanent) -- the window, in seconds, over which failed attempts are counted.
• Bad Logins Short Lockout Duration -- how long, in seconds, a short lockout lasts.
• Days Until Password Expires -- 0 to 1000; 0 disables expiry.
• Unique Passwords Until Reuse -- 0 to 20; how many previous passwords are remembered and refused.
• Minimum Days Between Password Change -- prevents a user cycling straight back to a previous password.
• Maximum Days Account Inactive Until Lockout -- locks out dormant accounts.
• Auto Logout From N Minutes Of Inactivity -- idle timeout for the web interface; 0 disables it.
• Default Login Username -- the username pre-filled on the login page.

The Multi-admin Approvals tab chooses which deletes are held until a set number of administrators approve them; see Multi-admin Approvals.

The Advanced Settings tab holds the Web Access Mode (see Web Access Mode), an optional System Use Notification banner shown to users at login, and the LDAP single-sign-on settings described next.

Note: saving a change to the password or login policy prompts a confirmation that the change may log users out of the interface and cause passwords to expire. Plan policy changes accordingly. Changes made only on the Multi-admin Approvals tab save without this prompt.

LDAP Single-Sign-On Authentication

Security Manager, Advanced Settings -- Web Access Mode and LDAP single sign-on.

The Advanced Settings tab can connect the Storage Grid to an LDAP or Active Directory domain for management user authentication.

To configure this:

• In your LDAP/AD environment, create one or more groups for QuantaStor administration -- for example QS-Administrator and QS-Monitor -- and add the appropriate users to them.
• In QuantaStor, edit the Role you want each LDAP group to map to and set its LDAP Group field. For example set the Administrator role's LDAP Group to QS-Administrator, and the System Monitor role's to QS-Monitor. The LDAP Group field is on the Create Role and Modify Role dialogs.
• Set your DNS and NTP servers to point at your AD server, in the Storage System Modify dialog. Do this before enabling single sign-on.
• Return to Security Manager --> Advanced Settings, tick Enable Single Sign-on, and fill in the LDAP settings. The two fields are greyed out until the checkbox is ticked.

The LDAP fields are:

• LDAP Server (FQDN) -- the fully qualified domain name of the LDAP/AD server, for example dc01.example.com
• LDAP Server Base DN for Users -- the base DN under which user accounts are searched, for example dc=example,dc=com

This integration provides single sign-on for administrative access to the Storage Grid via the QuantaStor web interface, CLI, and REST API. It does not provide Active Directory integration for SMB network share access. For that, join each system to the domain via Storage Management --> Storage Systems --> Active Directory (toolbar) --> Join AD Domain.

Audit Logging

Audit logging is always on. Every management operation, login attempt and authorization decision is recorded in /var/log/qs/qs_audit.log on the appliance that handled it. Starting with QuantaStor 7.0 the records are RFC 5424 syslog records, signed with a chained HMAC-SHA256 so that tampering can be detected with qs audit-log-verify. The record format, facility settings, rotation, verification, SIEM forwarding and the Audit Log Analyzer are covered on their own page: Audit Logging.

Sending Logs to Support

QuantaStor can collect and upload system logs to OSNEXUS Support, scrubbing usernames and other security related information first so that no personally-identifiable information is transmitted, and never including data files from Storage Pools. That makes the collection GDPR compliant.

Full detail is on its own page: Sending Logs to Support.

Multi-admin Approvals

Multi-admin approvals stop a single administrator from destroying data on their own. When the policy covers an object type, a delete of that type does not run when it is requested. QuantaStor holds it as a pending request until enough other administrators approve it, and only then carries out the delete. A mistaken click, a compromised administrator account or a lone insider can therefore no longer remove a pool, volume, share or bucket unnoticed.

The policy is part of the grid-wide password and login policy held by the Security Manager, so it applies to every system in the Storage Grid.

Enabling multi-admin approvals

Security Manager, Multi-admin Approvals tab -- the approval count, the expiry and the object types whose deletes need approval.

Navigation: Security → Management Users → User → Security Manager (toolbar) → Multi-admin Approvals (tab)

Tick Enable Multi-admin Approvals, then set the two fields under Approval Settings and choose the object types under Required Approval Types.

• Minimum Approvals -- how many administrators must agree to a delete, counting the administrator who requested it. The default and the minimum are both 2, which means one other administrator has to approve. Set 3 to require two approvers besides the requester.
• Hours Until Auto-expiration -- how long a request stays open for approval. The default and the minimum are both 48 hours, so a request raised on a Friday is still open on Monday. An expired request can no longer be approved; request the delete again to start over.
• Required Approval Types -- the deletes that need approval. Select All and Clear All tick or clear the whole list.

Required Approval Type	Held for approval
Storage Volume : Delete	Deleting a Storage Volume, including a volume snapshot
Network Share : Delete	Deleting a Network Share
Bucket : Delete	Deleting an object storage bucket
Scale-up Storage Pool : Delete	Deleting a ZFS-based Storage Pool
Scale-out Block Pool : Delete	Deleting a Ceph block storage pool
Scale-out File Pool : Delete	Deleting a Ceph file system
Scale-out Object Pool : Delete	Deleting an object storage pool group
Object Storage Class : Delete	Deleting an object storage class
Ceph Cluster : Delete	Deleting a Ceph cluster

Tick at least one type. With the checkbox enabled but no type ticked, nothing is held for approval, and the tab shows the feature as disabled the next time you open it.

To turn the feature off, clear Enable Multi-admin Approvals and click OK. Requests that are already open stay in the list until they are approved, rejected or expire.

Saving changes that touch only this tab does not raise the Security Manager's "may log users out" confirmation, because approval settings do not affect sessions or passwords.

How a held delete proceeds

1. An administrator requests the delete in the usual way. Instead of deleting, the task completes with a description such as "Multi-admin approval pending for Storage Volume 'vol1' (1 of 2 approvals met). The delete will proceed once the required number of approvals is met." The object stays in place, and its state detail reads "Delete requested, pending approvals."
2. Other administrators approve it from the Approve dialog described below. Each approval raises the count by one.
3. When the count reaches Minimum Approvals, the request becomes approved and QuantaStor starts the delete straight away as a new task, run as the administrator who requested it. The options chosen with the original request carry through. For example, a Storage Pool delete keeps its Shred Encryption Keys and Shred Data choices.
4. QuantaStor records the result. The request is marked completed once the object is gone, or failed if the object still exists after the delete task has finished.

A few rules apply throughout:

• The requester cannot approve their own request, and each administrator can approve a request only once.
• One request per object. QuantaStor keeps a single open request for each object and operation. When a different administrator requests the same delete again, that counts as their approval rather than opening a second request. If the original requester issues the same delete again, it is refused, because they cannot approve their own request.
• Rejecting ends the request. Any administrator can reject an open request, and the delete does not happen. To delete the object later, start a new request.
• Expired requests are closed automatically. QuantaStor checks for expired requests periodically, so a request can still show as pending for a short time after its expiry time. It cannot be approved once it has expired.

Approving and rejecting requests

Multi-admin Approval Request. Select one or more pending requests, then click Approve.

Navigation: Security → Management Users → Multi-admin Approval (toolbar group) → Approve

The Approve dialog lists every request still waiting for approval under Pending Multi-admin Approval Requests. For each request it shows the object's name, type and ID, the Request Status, the Required Count and Current Count, the Request Originator and the Expires Time. Select one or more requests and click Approve, then confirm.

To refuse a request instead, open Reject from the same toolbar group. It lists the same pending requests. Select the ones to stop and click Reject.

Approving and rejecting need the Administrator role, or a custom role granted the approve and reject operations on the PendingOperationRequest object type. The built-in Security Administrator role does not currently include them (see Role Based Access Controls).

You can approve from any system in the grid. QuantaStor forwards each approval to the system that owns the request, and the delete itself runs on the system that owns the object.

Request status

Status	Meaning
Pending	Waiting for approvals. It can be approved or rejected.
Approved	Enough approvals have been received. The delete is about to start.
Running	The delete task is running.
Completed Success	The delete finished and the object is gone.
Completed Failed	The delete ran but the object still exists, or the object or the requesting user no longer existed when the delete was due to run.
Rejected	An administrator rejected the request. The delete did not run.
Expired	The request reached its expiry time before it was approved.

QuantaStor removes finished requests (completed, rejected and expired) automatically after 48 hours.

Multi-admin approvals from the CLI

Set the policy with qs password-policy-set. The object types are the internal type names, comma separated: StorageVolume, NetworkShare, Bucket, StoragePool, CephPool, CephFilesystem, CephObjectPoolGroup, CephObjectStorageClass and CephCluster. Give the count and expiry explicitly: the CLI does not apply the minimums the web interface enforces. To turn the feature off from the CLI, clear the type list and set the count and expiry to 0 in one command, which is what clearing Enable Multi-admin Approvals in the Security Manager does.

qs password-policy-set --multiadmin-approval-types=StorageVolume,NetworkShare,StoragePool --multiadmin-approval-count=2 --multiadmin-approval-expiration-hours=48
qs password-policy-set --multiadmin-approval-types="" --multiadmin-approval-count=0 --multiadmin-approval-expiration-hours=0

Manage requests with the por-* (por refers to pending-object-request) commands. qs por-list shows each request's object, status (pending, approved, running, completed-success, completed-failed, rejected or expired), current and required counts, expiry time and request ID, and qs por-approve and qs por-reject take a comma-separated list of request IDs:

qs por-list
qs por-get --request-id=<request-id>
qs por-approve --request-ids=<request-id>,<request-id>
qs por-reject --request-ids=<request-id>
qs por-clear-all

qs por-clear-all removes every finished request (completed, rejected and expired) without waiting for the 48-hour automatic cleanup. It leaves pending requests alone.

Role Based Access Controls (RBAC)

Management Roles section with the default roles.

QuantaStor's Role Based Access Control system lets IT and security administrators grant access limited to a job function, following the principle of least privilege.

The RBAC system is highly granular. Each permission has three parts:

• an object type -- for example Network Share, Storage Volume, Storage Pool
• an operation -- for example create, delete, modify, view
• a scope -- system, resource group, user, or none

Every QuantaStor API, CLI, and web interface command goes through the same core service, and every call passes an authentication and an authorization check. Because of that shared path, RBAC applies uniformly no matter how the account connects -- web interface, qs CLI, or REST API.

This granularity is especially useful for automation: a dedicated account can be created for a script whose role permits only the task it performs, such as creating and deleting a nightly snapshot of a Network Share.

QuantaStor ships with four default roles:

• Administrator -- full access to all functions on all systems in the grid.
• Security Administrator -- full control over security-related functions.
• Object Tenant Admin -- for users managing object storage tenants.
• System Monitor -- view only; no configuration changes.

Role Management

Create Role, showing the permission assignment grid.

Navigation: Security → Management Roles → Role → Create (toolbar)

Each user is assigned a single Role, and a role change takes effect immediately. If a user logged in as Administrator has their role changed to System Monitor, which has only view permissions, the new permissions apply to their next action. Tasks already running -- a Storage Volume create, for example -- complete at the authorization level held when the task started.

The Create Role dialog takes a Name, a Description, and an optional LDAP Group used for single sign-on.

Because a role carries hundreds of individual permissions, the dialog provides two shortcuts:

• Copy Permissions from Role -- start from an existing role's permission set (pick the source role in the adjacent dropdown) and adjust from there. This is by far the fastest way to build a new role.
• Apply Permission Scope to Selected -- tick a set of rows in the grid, choose a scope, and apply it to all of them at once.

The Web Interface Customization tab hides web interface tab panels and sections for every user holding the role -- the same mechanism described under Web Interface Customization, but applied per role rather than per user.

Role Permissions - Object Types

The Permission Assignments grid lists every permission as a row of Object Type, Operation, and Permission Scope.

There are 207 object types and 662 individual permissions, covering everything from the common types such as Storage Volume, Network Share, and Object Bucket through to internal types such as Acl, AlertConfiguration, and TargetPort.

Because that list is long, use the <Show All Object Types> filter above the grid to narrow it to the object type you are working on, then set the operations for that type.

Role Permissions - Operation Types

Every permission is a combination of an object type and an operation that can be performed on it. Across the default Administrator role there are 120 distinct operations; the most common are view, modify, create, and delete, with more specific ones such as add, remove, rescan, enable, disable, identify, set, and clear on the object types that support them.

This per-operation granularity is what lets a role fit a job function. A "Provisioning Administrator" role, for example, can be given create but not delete, so the routine task of provisioning storage can be delegated without the risk of data deletion.

All object types also have a view permission, and this one deserves attention: some parts of the web management interface require view permission on a type in order to function. Removing view is useful when a role should have no visibility of a type at all -- an administrator responsible only for Network Shares could have view on StorageVolume set to None, so that no Storage Volumes are visible to them.

Role Permissions - Operation Scope

Each permission's scope determines the breadth of the grant. Click a Permission Scope cell in the grid to change it.

• Global/System -- grid-wide access to the operation on all systems.
• None -- access to the operation is blocked entirely.
• User -- access is limited to objects the user owns. A role with the permission Storage Volume + delete + User allows deleting only Storage Volumes for which that user is the owner.
• Resource Group -- access is limited to the objects in the Resource Group the user is assigned to. This is how QuantaStor implements multi-tenancy; see Multitenancy.

User Management

Security tab, Management Users section.

Users in QuantaStor are management users -- accounts with access to the management interface under a specific Role.

These accounts are also created as local (Linux/Unix) users on every Storage System in the grid, with the same POSIX UID and GID on each. This enables management accounts to be used for SMB file access, which matters in environments where AD/LDAP is not configured, or where direct non-AD user access is needed.

For security, the local accounts created for SMB access are given /usr/sbin/nologin as their shell, so they cannot log in over SSH or at the console. By default the only accounts with a login shell are qadmin and root, and those should be reserved for maintenance activities. That restriction can be overridden with standard Linux user management commands, but doing so widens your attack surface and is not recommended.

Adding New Users

Add User dialog, General tab.

Navigation: Security → Management Users → User → Add (toolbar)

The General tab takes:

• Username -- also becomes the local POSIX account name on every system in the grid.
• Password and Repeat Password -- must satisfy the grid password policy set in the Security Manager. The factory default policy is deliberately permissive; raising it with Suggested Defaults is recommended.
• Role -- see RBAC. Assign System Monitor to an account that only needs to observe, rather than Administrator.
• Enable Multi-Factor Auth and Multi-Factor Auth Config -- require a second factor for this account; see Multi-factor Authentication. These are greyed out until at least one MFA configuration exists.
• User Information -- optional First Name, Last Name, and Description.

The default admin account can be modified but cannot be deleted, and cannot be assigned any role other than Administrator.

A newly created user appears in the Users grid with its assigned Role and the POSIX User ID allocated to it, and the matching local account exists on every system in the grid immediately.

Alert Subscriptions

Add User, Alert Subscriptions tab.

Entering a user's email address and selecting the alert severity levels to subscribe to routes email alerts to that administrator. Several users can subscribe at different severities, so that (for example) only critical alerts page the on-call administrator while an operations mailbox receives everything.

Once configured, use the Alert Manager to send a test alert and confirm delivery end to end.

Web Interface Customization

Add User, Web Interface Customization tab.

In larger deployments with many administrators, or on systems built for a narrow use case, it can help to hide the interface tab panels and sections a given user does not need. This reduces complexity and makes the interface clearer for admins with a narrow remit.

Un-check the panels and sections to hide them. The user must log out and back in for the customized layout to take effect.

The same customization can be applied to a Role instead of an individual user, which is usually preferable when several people share a job function -- see Role Management.

User Account Advanced Settings

Add User, Advanced Settings tab.

The Advanced Settings tab holds three things:

• User Default CHAP settings -- a CHAP User and CHAP Password used as this account's defaults for iSCSI authentication.
• Customize UID/GID -- tick this to set an explicit POSIX UID and POSIX GID rather than letting QuantaStor allocate them. Set these deliberately when the account is used for SMB and NFS access and must match UIDs already in use elsewhere in your environment; the fields are greyed out until the box is ticked.
• Enable '[QSCLITKN]' token based authentication for QS CLI via 'root' console account -- lets someone logged into a QuantaStor system as root run qs CLI commands without supplying a password each time.

To use the token authentication, tick that checkbox for the account, then, as root on the system, write a ~/.qs.cnf naming the account:

echo "localhost,admin,[QSCLITKN]" > ~/.qs.cnf

Replace admin with whichever account you enabled the option for.

Note: the first one or two qs commands after creating this file fail with "Service authentication token check failed ... remote caller will update token" while the token is being established. This is expected -- retry and the command succeeds, after which authentication is transparent.

The same mechanism can be used with a remote host rather than localhost by changing the first field.

Modifying Users

Modify User dialog.

Navigation: Security → Management Users → select a user → User → Modify (toolbar)

The Modify User dialog exposes the same settings as Create User across the same four tabs, so a user's role, alert subscriptions, interface customization, and advanced settings can all be changed after the fact. Changes take effect on the user's next action.

To change only a password, use Set Password from the User group in the toolbar rather than the full Modify dialog.

More information: Modify User.

Removing Users

Remove User dialog.

Navigation: Security → Management Users → select a user → User → Remove (toolbar)

The dialog confirms the Username and shows the account's properties before removal.

Removal takes effect immediately and grid-wide. A user who is logged into the web interface when their account is removed loses access to all systems in the grid at once, and the matching local POSIX account is deleted from every Storage System.

The default admin account cannot be removed.

More information: Removing Users.

User Group Management

Create User Group dialog.

User Groups collect users under a common POSIX GID, which is useful when several users need to be owners of the same Network Share.

Navigation: Security → Management Groups → User Group → Create (toolbar)

The Create User Group dialog takes a Name, an optional Description, an optional POSIX GID (allocated automatically if left blank), and a grid from which to select one or more users for the group.

Group membership can be changed later with Add/Remove Users, and the group's other properties with Modify. Delete removes the group; the user accounts themselves are unaffected.

Multitenancy / Resource Group Management

Multitenancy tab.

Resource Groups are multi-tenant containers that group users together with resources -- Storage Volumes, Network Shares -- and with provisioning quotas for self-service provisioning from Storage Pools.

Navigation: Multitenancy (main tab)

The Resource Group toolbar group provides Add/Remove Users, Add/Remove Tenants, Add/Remove Service Configs, and Add Network Association / Remove Network Association for binding a group to specific networks. The Provisioning Quota group provides Create, Modify, and Delete for quotas, plus Add/Remove Volumes and Add/Remove Shares to place resources into a group.

Users assigned to a Resource Group should hold a role whose permissions are scoped to Resource Group rather than Global/System, so that their view of the grid is limited to the resources in their group. The Object Tenant Admin role is the shipped starting point for object storage tenants; for file and block multi-tenancy, create a role with the permissions you want at Resource Group scope -- see Operation Scope.

Further information: Create a Resource Group.

System Setup Security Checks

The steps in this section are the minimum hardening pass for a newly deployed QuantaStor system. All of them should be completed before the system carries production data.

1. Change the qadmin console password from its default.
2. Change the admin management password from its default.
3. Apply Suggested Defaults in the Security Manager to raise the password and lockout policy.
4. Set Web Access Mode to HTTP redirects to HTTPS or HTTP disabled.
5. Replace the shipped self-signed certificate -- see Installing Your Own Certificate.
6. Block unused protocols in the firewall.
7. Consider enabling multi-factor authentication for administrative accounts.

Change Passwords

QuantaStor ships with two default accounts that must both be changed. They are separate accounts with separate passwords: qadmin is the console/SSH account, admin is the management interface account.

Change SSH Console Administrator Account 'qadmin' Password

One of the most important steps in configuring a new QuantaStor system is changing the qadmin console password from its default of qadmin on each Storage System.

Log in at the console as qadmin, or connect over SSH as qadmin, then run:

passwd

Choose a strong password containing upper and lower case letters, numbers, and symbols. Repeat this on every Storage System in the grid -- this is a local console account, so changing it on one system does not change it on the others.

Note that this password is independent of the grid password policy configured in the Security Manager, which governs management users only.

Change Management Administrator Account 'admin' Password

Set Password dialog.

Log in to the web management interface as admin and change the default password, which is password.

Navigation: Security → Management Users → select the admin user → User → Set Password (toolbar)

The new password must satisfy the grid password policy. Use at least 10 characters with upper and lower case letters and numbers -- or raise the policy first with Suggested Defaults so the requirement is enforced for every account rather than relying on convention.

Old Password is disabled while the session is logged in as admin, so changing that account's password needs only the new password and its confirmation. For every other account the field is required and the current password has to be entered as well. The permitted length range comes from the grid password policy rather than being fixed by the dialog.

Unlike qadmin, this is a grid-wide management account: changing it once changes it for the whole Storage Grid.

Firewall Configuration

Storage System Modify, Firewall tab.

QuantaStor has an integrated firewall management system that controls protocol access both at the system level and per network port. For high-security environments it is recommended to block every protocol that will not be used.

Navigation (system level): Storage Management --> select a Storage System --> Modify (toolbar) --> Firewall (tab)

Navigation (per port): Storage Management --> Network Ports --> select a port --> Modify Network Port (toolbar or right-click) --> Firewall (tab)

The Firewall tab lists each service with a description and an Allow checkbox. The services managed are:

• QS Web Management -- web management interface access
• QS REST API -- REST API access to management functions
• iSCSI Target -- iSCSI protocol access to Storage Volumes
• NVMeoF Target -- NVMe over Fabrics access
• SMB -- SMB/CIFS file access
• NFS and NFS Ganesha -- NFS file access, scale-up and scale-out respectively
• Ceph -- scale-out cluster communication
• Grafana -- Grafana monitoring and statistics
• Prometheus -- Prometheus monitoring and alerting
• Chronograf -- Chronograf monitoring

Clear the Allow box for any service you do not use. A common hardening pass on a file-only deployment, for example, is to leave SMB and NFS enabled and clear iSCSI Target, NVMeoF Target, and Ceph.

Be careful not to block the protocol you are managing the system with: clearing QS Web Management on the port you are connected through will cut off your own session. Note also that Web Access Mode set to HTTP disabled installs its own rule dropping port 80, independently of these checkboxes.

Use Apply to commit changes without closing the dialog.

SSL/TLS Certificate & Web Access Security

QuantaStor serves the web management interface, the REST API, and the internal grid communication channels over TLS. The web management interface is served by nginx and the TLS settings, ciphers, and certificates are all managed by QuantaStor.

Web Access Mode

The single most important web security setting is the Web Access Mode, which controls whether plain HTTP is served at all.

Navigation: Security → Management Users → User → Security Manager (toolbar) → Advanced Settings

The three modes are:

• HTTP enabled (INSECURE) -- port 80 serves the interface over plain, unencrypted HTTP. This is the factory default so that a newly-imaged appliance is reachable before certificates are in place; it is not appropriate for production.
• HTTP redirects to HTTPS (recommended) -- port 80 answers with a 301 redirect to HTTPS. Nothing sensitive traverses the network in the clear, but a user who types the bare hostname still lands on the interface.
• HTTP disabled -- port 80 is dropped at the firewall entirely. Use this in high-security environments where an open port 80, even one that only redirects, is not acceptable.

Changing this setting switches the active nginx site configuration and, for HTTP disabled, also installs a firewall rule that drops port 80. The change applies immediately -- no reboot is required.

The Web Access Mode affects port 80 only. The HTTPS listener on port 443 uses the same TLS versions, cipher list, and certificate in every mode, so switching modes does not change the encryption offered to HTTPS clients -- it only determines whether an unencrypted alternative is reachable. Setting the mode to HTTP redirects to HTTPS should nonetheless be treated as a required hardening step on every production deployment.

Changing this setting prompts a confirmation warning that the change may log users out of the interface and cause passwords to expire; the mode change itself takes effect as soon as you confirm.

Supported TLS Versions and Ciphers

QuantaStor's nginx configuration accepts TLS 1.2 and TLS 1.3 only, in all web access modes, with server cipher preference enabled and the cipher list restricted to modern AEAD suites: (Note: due to the frequency of security updates this may be out of date and system configuration files should be referenced.)

ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

SSLv3, TLS 1.0, and TLS 1.1 are not accepted. (Note: due to the frequency of security updates this may be out of date and system configuration files should be referenced.) The interface also sends an HSTS header (Strict-Transport-Security) with a one year max-age.

The shipped defaults live in this file, which is replaced on upgrade and should not be edited in place:

/opt/osnexus/common/lib/nginx_quantastor_ssl_default.conf

To customize the TLS settings or point nginx at your own certificate, use the qs-util helper to copy the defaults to a user-editable location that upgrades will not overwrite:

qs-util wuicustomcerts

This creates the following file, which you then edit:

/var/opt/osnexus/quantastor/ssl/nginx_quantastor_ssl_custom.conf

Cipher settings for the QuantaStor grid communication channels (separate from the web interface) are controlled by:

/opt/osnexus/common/lib/qsciphers

That shipped file is replaced on upgrade, so it should not be edited in place. To customize the grid communication ciphers, place your own copy at the override location below. The override does not exist by default -- create it only when you intend to depart from the shipped cipher list, and QuantaStor will use it in preference to the shipped file and leave it untouched across upgrades:

/var/opt/osnexus/quantastor/ssl/qsciphers

Default Certificate

QuantaStor ships with a common self-signed certificate that is pre-generated and included with all deployments. Because it is self-signed and shared across all deployments, browsers will warn on first connection, and it provides no identity assurance. Replacing it is recommended for any deployment reachable beyond a trusted management network.

The certificate and key used by the web interface and REST service are here:

/var/opt/osnexus/quantastor/ssl/qsrestsrv.pem

Grid communication uses a separate pair:

/opt/osnexus/common/lib/qsserver.pem
/opt/osnexus/common/lib/qsclient.pem

All of these are discovered and monitored automatically -- see Certificate Management below, which is the recommended way to review and replace them.

Installing a Custom Certificate

The recommended way to install your own certificate is through Certificate Management -- add the certificate as a template once, then apply it to the NGINX use case on each Storage System. That keeps the certificate inventory, expiry monitoring, and alerting accurate, and avoids editing nginx configuration by hand. See Installing Your Own Certificate.

Use the manual procedure below only when you need to change nginx TLS directives themselves (for example to further restrict the cipher list), since those are not expressible as a certificate template:

• Run qs-util wuicustomcerts to copy the shipped defaults to an editable file that upgrades will not overwrite.
• Edit /var/opt/osnexus/quantastor/ssl/nginx_quantastor_ssl_custom.conf.
• Reload nginx to apply:

systemctl reload nginx

• Verify the negotiated protocol and cipher from a client:

openssl s_client -connect <system-ip>:443 </dev/null 2>/dev/null \
  | grep -E 'Protocol|Cipher is'

Repeat on each Storage System in the grid, or use the Certificate Management section to confirm all systems at once.

Note: if you are using Firefox and have previously accepted the old self-signed certificate, clear the cached certificate exception for the host or Firefox will continue to present the stale certificate warning.

Custom SSL Certificates and TLS Security

• Generating and installing custom SSL certificates, and applying custom TLS security settings. For most deployments the Certificate Management section above is the better route, since it keeps the certificate inventory and expiry alerting accurate.

Custom SSH Ciphers and Key Exchange Algorithms

• Customizing the SSH service to enforce strong ciphers and key exchange algorithms for SSH communication.

Certificate Management

Certificates section showing every certificate on every Storage System in the grid.

QuantaStor discovers, inventories, and monitors every TLS certificate in use across the Storage Grid, so administrators can see at a glance what is installed, what it is used for, and when it expires.

Navigation: Security → Certificates

The Certificates section lists certificates grouped by Storage System. For each certificate the grid shows its file path, State, Use Case, description, certificate modulus MD5, serial number, and the start and end of its validity period. Because the view spans the whole grid, a single screen confirms that every system is using the certificate you expect.

Certificate Use Cases

Each certificate is tagged with the service that consumes it:

• NGINX -- the certificate served to browsers for the web management interface.
• Rest Service -- the certificate presented by the QuantaStor REST API service.
• QuantaStor Service [Grid Communication] -- the server-side certificate for inter-node grid communication.
• Client [Grid Communication] -- the client-side certificate a node presents to its peers.
• HAProxy -- the certificate used by the integrated load balancer, when configured.
• Object Gateway -- the certificate used by the Ceph S3/Object Gateway. Two use cases are available, for a first and second gateway instance (cephrgw-1 and cephrgw-2 on the CLI).

Note that the same PEM file may appear more than once with different use cases when one certificate serves several roles -- for example qsrestsrv.pem is used for both NGINX and Rest Service.

Certificate Expiration Alerts

QuantaStor monitors validity dates and raises alerts as a certificate approaches expiry, so a certificate never lapses unnoticed. Alerts are raised at 90, 60, 30, 7, and 2 days before expiry, and again once the certificate has actually expired.

The longer-lead warnings are only raised for certificates with a correspondingly long lifetime -- the 90 day warning applies to certificates valid for more than 18 months, the 60 day warning to those valid for more than a year, and the 30 day warning to those valid for more than 90 days. This prevents short-lived certificates from generating alerts the moment they are installed. The 7 day, 2 day, and expired alerts always apply.

Alerts are delivered through the standard QuantaStor alerting system, so they reach whatever email and SNMP destinations you have configured in the Alert Manager.

Certificate Templates

A certificate template holds a certificate (and its private key) that you have obtained from your CA, stored once in the grid so it can be applied to any service on any Storage System. Templates are what make it possible to roll out your own certificate across the grid from the management interface instead of copying PEM files onto each node by hand.

Navigation: Security → Certificates → Certificate Templates (tab)

The toolbar provides Add Template, Update, Remove Template, and Certificate Template Manager for reviewing and maintaining templates.

Installing Your Own Certificate

This is the recommended way to replace any of QuantaStor's default self-signed certificates, including the one served by the web management interface.

• Obtain a certificate and private key from your CA.
• Add a template from the certificate. Supply a name, a description, and the PEM file containing the certificate and key block. If the private key is in a separate file, supply it as well.
• Apply the template to the use case you want it to serve on a given Storage System -- for example apply it to the NGINX use case to change the certificate browsers see for the web management interface.
• Repeat the apply step for each Storage System, and for each use case the certificate should cover.

IMPORTANT -- the certificate must contain a Subject Alternative Name (SAN). QuantaStor validates certificates before accepting them as a template and rejects any certificate without a SAN extension, with the error "Certificate validation failed. Unable to create certificate template out of invalid certificate." A Common Name alone is not sufficient. Include every name and address the systems will be reached by -- the FQDN, the short hostname, and the management IP. When generating a self-signed certificate with openssl req, add the SAN explicitly:

openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -subj "/C=US/ST=<state>/L=<city>/O=<org>/CN=<fqdn>" \
  -addext "subjectAltName=DNS:<fqdn>,DNS:<hostname>,IP:<system-ip>" \
  -keyout mycert.key -out mycert.crt

cat mycert.crt mycert.key > mycert.pem

You can check a certificate against QuantaStor's validation rules before importing it:

/opt/osnexus/quantastor/bin/qs_certutil.sh validate --pem-file <path-to-pem>

From the CLI the two steps are:

qs cert-tmpl-add --name=<template-name> --description=<text> \
                 --certificate-pem-data=<path-to-pem> \
                 [--privatekey-pem-data=<path-to-key-pem>]

qs cert-update --storage-system=<system> --cert-use-case=2 \
               --cert-tmpl=<template-name>

Note: --cert-use-case currently requires the numeric use case value rather than its name. The values are 0 none, 1 haproxy, 2 nginx, 3 cephrgw-1, 4 cephrgw-2, 5 qsrest, 6 qsserver, 7 qsclient.

QuantaStor reloads the affected service automatically once the certificate is applied, so the new certificate is served without further action -- nginx for the NGINX and Rest Service use cases, HAProxy for HAProxy, and the Object Gateway services for the gateway use cases. nginx is reloaded rather than restarted, so applying a web interface certificate does not disconnect your own management session.

Note for QuantaStor releases prior to 6.9: the nginx reload was not performed automatically, and the appliance would continue to present the previous certificate until nginx was reloaded by hand:

systemctl reload nginx

Confirm what is actually being served, including the SAN:

openssl s_client -connect <system-ip>:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Rescanning Certificates

If a certificate is replaced outside of QuantaStor -- for example by editing the nginx configuration directly, or by a external renewal process dropping in a new PEM -- use Rescan to re-read the certificates from disk and refresh the inventory, validity dates, and alert state.

Navigation: Security → Certificates → Rescan (toolbar)

Reviewing Certificates from the CLI

The same inventory is available from the QuantaStor CLI, which is convenient for scripted compliance checks:

qs cert-list
qs cert-get --cert=<name-or-id>
qs cert-rescan --storage-system=<system>

Certificate templates have a matching set of commands:

qs cert-tmpl-list
qs cert-tmpl-get --cert=<name-or-id>
qs cert-tmpl-rm --cert=<name-or-id>

For TLS version and cipher settings, see Supported TLS Versions and Ciphers.

Endpoint Detection & Response (EDR)

EDR Agents section. Agents are installed per Storage System and report vendor, status, version, and enabled features.

Many security standards and cyber-insurance policies require an endpoint detection and response (EDR) agent on every server, including storage appliances. QuantaStor can deploy and manage a vendor EDR agent on each Storage System in the grid directly from the web management interface, so the appliances are covered by the same endpoint security tooling as the rest of the fleet without hand-installing agents over SSH.

Navigation: Security → EDR Agents

The EDR Agents section lists the installed agents with their Name, State, Storage System, Vendor, Status, Version, and the set of Features the agent has enabled.

Supported EDR Vendors

Bitdefender GravityZone is the currently supported EDR platform, on Ubuntu 22.04, Ubuntu 24.04, RHEL 8, and RHEL 9. Additional vendor modules use the same framework and are being added; contact OSNEXUS at info@osnexus.com if you need a specific EDR platform supported.

Vendor modules are defined on the appliance in:

/opt/osnexus/quantastor/conf/qs_endpoint_security.conf

Installing an EDR Agent

Install EDR Security Agent dialog.

Before starting, create an installation package for Linux servers in your Bitdefender GravityZone console and note either the package id or the full setup downloader URL the console provides. The feature set of the agent (which protection modules are enabled) is chosen in the GravityZone console when the package is created, and QuantaStor reads that selection back from the installer. Individual protection modules can optionally be overridden from the QuantaStor side at install time -- see the --feature-flags argument in the CLI section below.

OSNEXUS recommends a package with Antimalware, Advanced Threat Control, Advanced Anti-Exploit, Network Attack Defense and the EDR Sensor enabled. These are our recommended settings, but you may find further customization is needed for your environment. In our testing we did not find that Bitdefender was using much CPU and other resources, but depending on your configuration settings you may need to narrow scanning and other options to reach a fair compromise of strong security with minimal performance impact.

Navigation: Security → EDR Agents → Install Agent (toolbar)

You can also right-click a Storage System to install an agent on it.

In the Install EDR Security Agent dialog:

• EDR Module -- select the vendor module, e.g. Bitdefender.
• Install Key / URL -- paste either the short GravityZone package id (e.g. aabbccdd) or the full setup_downloader.tar URL copied from the GravityZone console. Both forms are accepted, which matters because the vendor's URL format changes from time to time.
• Storage Systems -- tick each system to install the agent on. The grid shows the service, kernel, and distribution version of each system so you can confirm platform support before installing.

QuantaStor then downloads the installer package from GravityZone onto each selected system, installs the agent, and registers it. Because the appliance must reach the GravityZone service to download the package, ensure outbound access to your GravityZone endpoint is permitted -- see Firewall Configuration.

Note that the registration key is supplied at install time and stored per node; it is not kept in the vendor module configuration file.

Monitoring and Removing Agents

Once installed, an agent's Status and Version are refreshed automatically and shown in the EDR Agents grid, so an agent that has stopped running is visible from the management interface rather than only from the vendor console.

To remove an agent, select it and choose Uninstall Agent.

Navigation: Security → EDR Agents → Uninstall Agent (toolbar)

EDR Management from the CLI

The same operations are available from the QuantaStor CLI:

qs edr-agent-list
qs edr-agent-get --edr-agent=<name-or-id>
qs edr-agent-create --system-list=<systems> --module=Bitdefender \
                    --registration-key=<package-id-or-url>
qs edr-agent-delete --edr-agent=<name-or-id>
qs edr-agent-rescan

--module takes the module's vendor name exactly as qs edr-agent-module-list shows it -- Bitdefender, with a capital B. The match is case-sensitive.

The create command also accepts an optional --feature-flags argument taking a JSON object, to override individual protection modules without changing the GravityZone package:

qs edr-agent-create --system-list=qs-node-a --module=Bitdefender \
                    --registration-key=aabbccdd \
                    --feature-flags='{"FileScan":1,"Firewall":0}'

To review the available vendor modules and their supported platforms:

qs edr-agent-module-list
qs edr-agent-module-get --module=Bitdefender

Custom S3 SSL/TLS Certificate

• Installing a custom certificate for the S3/Object Gateway endpoint. See also the Object Gateway certificate use cases under Certificate Use Cases.

Multi-factor Authentication

Multi-Factor Authentication Manager.

Multi-factor authentication (MFA) requires a user to present a second factor, such as a device, in addition to their password. QuantaStor supports MFA for management logins.

Navigation: Security → Management Users → User → Multi-Factor Auth Manager (toolbar)

An MFA configuration must exist before MFA can be enabled on any account. The manager lists the existing configurations by Name and Provider and provides Create..., Modify..., Delete..., and Assign/Unassign... for attaching a configuration to user accounts.

The supported providers are:

• Cisco Duo -- see Cisco Duo Multi-Factor Authentication for the full setup walkthrough
• OKTA -- see Okta Multi-Factor Authentication for the full setup walkthrough

Creating a configuration takes a Provider, a Name, an optional Description, the API Host for your tenant, and the keys issued by the provider:

• Cisco Duo -- the Integration Key and Secret Key from your Duo Auth API application.
• OKTA -- an Okta API token as the Integration Key, and no Secret Key (the field is disabled when OKTA is selected). The API Host is your Okta org host name, such as yourcompany.okta.com. QuantaStor finds each user in Okta by the account's Email Address, so every Okta-protected account needs one that matches its Okta user.

Once a configuration exists, enable MFA per account with Enable Multi-Factor Auth and Multi-Factor Auth Config on the Add User or Modify User dialog. The Force (required when in use) option in the manager applies to Delete...: it allows deleting a configuration that is still assigned to accounts, and turns MFA off on those accounts.

Contact OSNEXUS at info@osnexus.com for guidance on additional MFA options.

Security Updates

QuantaStor supports automatic security updates through the Upgrade Manager in the web management interface.

Navigation: Storage Management → Upgrade Manager (toolbar)

Applying security updates through the Upgrade Manager is the supported path -- it applies the updates OSNEXUS has qualified against the running QuantaStor release, in the correct order, across the systems you select. Installing distribution packages directly with apt is not recommended, as it can introduce package versions that have not been qualified against the release.

Encrypting NFS/SMB/iSCSI via IPsec

Protocols such as NFSv3 do not encrypt data on the wire. Where the storage network is not itself trusted, set up an encrypted tunnel between the client and the QuantaStor system so that protocol traffic is protected in transit.

More information on configuring IPsec on QuantaStor systems is available here.

Note that IPsec protects data in transit. For data at rest, QuantaStor provides Storage Pool encryption, which is configured when the pool is created and is covered separately in the administrator guide.

Related pages

• Send System Log Report -- collecting and sending a scrubbed log bundle to support
• Duo Multi-Factor Authentication -- setting up the Cisco Duo MFA provider
• Custom SSH Security -- hardening the SSH service and managing key access
• Custom S3 SSL/TLS Certificate -- certificates for the S3 gateway
• IPSec -- encrypting protocol traffic in transit between client and appliance
• Storage Pools -- pool encryption, which protects data at rest
• Upgrade Manager -- applying security patches and QuantaStor updates
• Alert Manager -- alert delivery, including certificate expiry alerts
• Storage System -- system-level configuration and the Modify dialog

---

Verified against QuantaStor 6.9.0.