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 and Security Updates.

Security Settings Management

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 configures which operation types require a second administrator's approval before they run; approvals are then granted or refused from the Multi-admin Approval group in the Security toolbar.

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 the Security Manager prompts a confirmation that the change may log users out of the interface and cause passwords to expire. Plan policy changes accordingly.

LDAP Single-Sign-On Authentication

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 of management operations is on by default on all QuantaStor systems and cannot be disabled. Every API, CLI, and web interface operation passes through the same core service and is recorded.

The audit log is at:

/var/log/qs/qs_audit.log

It is written in a NIST compliant CEE JSON format, one JSON object per line, so it can be ingested directly by a log aggregator or SIEM without custom parsing. Each record identifies the operation, the user account that invoked it, the source address, and the outcome.

To ship the audit log to a central collector, point your syslog or log agent at this file; QuantaStor does not rotate it out from under a reader.

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.

Role Based Access Controls (RBAC)

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

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

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

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

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

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

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

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

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

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

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.

Change the qadmin console password from its default.
Change the admin management password from its default.
Apply Suggested Defaults in the Security Manager to raise the password and lockout policy.
Set Web Access Mode to HTTP redirects to HTTPS or HTTP disabled.
Replace the shipped self-signed certificate -- see Installing Your Own Certificate.
Block unused protocols in the firewall.
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

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

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

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)

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

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.

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

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 (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

Creating a configuration takes a Provider, a Name, an optional Description, the API Host for your tenant, and the Integration Key and Secret Key issued by the provider. Obtain those values from your Duo or Okta administration console.

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 makes the second factor mandatory rather than optional.

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.