Storage

The Storage tab configures every storage integration that the console collects audit events from. It has two sections: ECS / ObjectScale Devices and PowerScale Clusters.

Overview

Storage devices are the sources of all data movement in the system. Each registered device feeds the audit event pipeline that drives the detectors and alarms.

Adding a device requires a license. Add Device (ECS / ObjectScale) and Add PowerScale Cluster are disabled, with a note above the list, until an active subscription is installed under Settings > Licensing. See Licensing.

• Devices you already have keep working, and you can still edit or remove them, after a subscription expires.
• If the license ends while the page is open, Save Settings still saves your other changes. The new device stays on the page, unsaved, until a license is installed.
• Without a license, removing a saved PowerScale cluster asks you to confirm first. Deleting an ECS device is always safe, because you can restore it from Deleted Devices.

ObjectScale (Dell ECS) devices

Each entry represents one Dell ECS or ObjectScale array that the system ingests audit logs from. Devices are listed in the Registered Devices table at the bottom of this section.

Registered devices table

Column	Description
Device Name	The display name entered in the device configuration.
Type	Always Source.
IPs / Endpoint	The ECS data-node IPs the application connects to over SSH. Truncated if there are more than two IPs.
Version	The detected ECS/ObjectScale software version. A green badge appears immediately after a successful Test Auth. A grey badge shows the previously detected version, which persists across sessions; hover it to see when the version was last tested. Shows — if the version has never been detected.

• Click Edit to expand the device configuration inline.
• Click Delete to move the device to the Deleted Devices panel at the bottom of the tab. You can restore or purge it from there.

Device configuration fields

Fields marked with an asterisk (*) are mandatory. Save Settings is disabled until every registered device has all required fields filled in. After you edit a field, the button reads Save Changes. Empty required fields are highlighted with a red border.

Field	Description
Device Name *	A short label used throughout the UI and in audit event records. Renaming a device does not affect existing records, because events are matched by device identity, not display name.
Node IPs *	Comma-separated list of ECS data node IP addresses or DNS names. Used for inventory collection and for SSH log retrieval.
Management Host / IP *	Hostname or IP of the ECS management API. Do not include the port.
Management Username *	The ECS management API username. Masked after save.
Management Password *	The ECS management API password. For a saved device, leave the field blank to keep the current value. For a new device, enter a password before saving.
Management Port	Defaults to 4443. Change it only if the management API listens on a non-standard port.
Ignore management API SSL certificate	Selected by default. Skips TLS certificate validation for management API connections, which most ECS nodes need because they use self-signed certificates.
Data Access IP or DNS Name *	The S3-compatible endpoint URL for this device, for example https://192.0.2.20:9021. Must include the scheme and port. Used for S3 read-access verification and inventory enrichment.
Ignore SSL certificate (Data Access)	Selected by default. Skips TLS certificate validation for S3 data connections.
ECS Deployment Type	Selects the remote log directory that SSH ingest reads from. See the table below.
Ingest Threads Per Node	The number of worker threads used on each node to read compressed log archives in parallel. See Ingest parallelism.

SSH access to the nodes uses the SSH User, SSH Password, and SSH Port fields in the SSH Credentials section of the device configuration. SSH is the only supported ECS ingest method.

The ingest schedule is not set per device. Configure it globally in Settings > System Jobs > Schedules.

ECS deployment type

Option	Log path used
ObjectScale / Virtual ECS (default)	/var/log/vipr/emcvipr-object
Hardware ECS Appliance	/opt/emc/caspian/fabric/agent/services/object/main/log
Custom	A path that you supply

Select Hardware ECS Appliance for physical Dell ECS hardware nodes. The default is correct for VM-based ObjectScale deployments.

Ingest parallelism

Each ECS node is ingested on its own worker thread, and Ingest Threads Per Node sets how many threads on each node read compressed (.gz) log archives at the same time. Each thread opens its own SFTP session to the node.

• Range — 1 (serial processing) to 8. The maximum leaves headroom under the node's SSH session limit, which is typically 10.
• Recommended — 4 for most clusters.
• Total concurrency — approximately the node count multiplied by this value, with a ceiling of 32 threads per run. If the result would exceed 32, the per-node value is reduced automatically and the Job Detail flyout shows Threads (capped at 32) in amber.
• Active log file — the log file currently being written on each node is always read by a single thread, so a log rotation during a read cannot drop or duplicate records.
• Already-ingested archives — skipped on later runs.

After a long outage with a large backlog, raise Ingest Threads Per Node (for example to 4) to shorten the catch-up window. On a single-node device with a small backlog, the value of 1 is sufficient. The Threads card on the Job Detail flyout shows the planned total parallelism as soon as a job starts.

Status and actions

• Test Auth — validates the management credentials with a full login and logout against the configured endpoint. On success, the detected ECS/ObjectScale software version is displayed inline and saved to the device.
• Run Inventory Scan — queries the ECS management API to enumerate all namespaces and buckets. Requires valid management credentials. Progress is visible on the Jobs page.
• Run SSH Ingest Now — immediately runs an ingest cycle for this device outside the normal schedule. Use it after configuration changes or to recover from a missed window.

The inventory scan keeps the inventory in sync in both directions. Newly discovered buckets are added, and buckets or namespaces that no longer exist on the device are removed in a final reconcile step. The Inventory Diff panel in the job flyout reports how many were added, updated, and removed. If the bucket listing for a namespace fails, that namespace is left untouched rather than emptied.

Each scheduled ingest run connects over SSH to every node IP listed for the device and pulls new rotated dataheadsvc-access* log files plus a slice of the active log. Offsets are tracked per file, so a re-run skips data that was already ingested.

ObjectScale bucket classification service account

This card, above the device list, gives the classifier read access (list and get) to ObjectScale/ECS buckets so the pipeline can scan their contents. It applies to all configured ECS clusters and has two parts: a bucket inventory browser at the top and a Service accounts list at the bottom.

How read access works

Buckets created by Kubernetes pods are owned by the customer's own ECS users, so the application cannot read them without explicit access. The feature creates a least-privilege account with list and get permissions only, with no write or delete, for each namespace. It then grants that account read access per bucket.

• Account naming — one IAM reader user per namespace, named {namespace}aisecroiam (for example teamdataaisecroiam). IAM users are scoped to a namespace, so each namespace needs its own reader. If the identity already exists, it is reused.
• Granted through IAM — read access is granted by attaching a read-only IAM managed identity policy to the reader user. The bucket's own policy is never modified. This works on buckets owned by Kubernetes/COSI applications, which a bucket policy cannot grant without locking out the owner, and it cannot disturb another system's access to a shared bucket.
• Managed policies — grants are held in managed policies named aisec-read-1 to aisec-read-N, so one reader can be granted many buckets.
• Revoke — removes only that bucket's entries from the identity policy.

note

IAM changes take up to about 90 seconds to take effect on the storage system. A bucket that was just granted or revoked may briefly still reflect the old access.

Bucket inventory browser

Use the filters and actions at the top of the card to find buckets and grant read access.

Filters — all filters run on the server, so they match across all pages and all devices. Changing any filter returns the table to page 1.

• A device dropdown (All, or one cluster).
• A namespace dropdown.
• A bucket name search box.
• A COSI discovery dropdown (All, COSI-discovered only, or Non-COSI only).

Run Inventory — starts an inventory scan that discovers namespaces and buckets. It respects the device filter, and All starts one scan per cluster. A job-number link appears so you can monitor the scan on the Jobs page.

• The table shows what the most recent scan found, so run the inventory first.
• Each scan also removes buckets and namespaces that no longer exist on the device. A bucket deleted on ECS disappears from the table after the next scan.
• The Inventory Diff panel and the reconcile step log in the job flyout list exactly what was added and removed.

Table columns — the table is paginated at 500 rows per page.

Column	Description
Device	The ECS device that holds the bucket.
Namespace	The namespace that contains the bucket.
Bucket	The bucket name.
Discovered by COSI	A COSI badge when the bucket was provisioned through a Kubernetes COSI BucketClaim, discovered by the K8 scan. Otherwise a dash. Use it with the COSI filter to find COSI buckets that still need read access.
Read access	A green Granted badge once access is provisioned, with an IAM chip when granted through the IAM identity policy. Buckets provisioned in earlier releases show a policy · legacy chip; run Add Permissions again to migrate them to IAM.

To see exactly which buckets a reader grants, expand its row in Service accounts.

Grant read access

1. Select buckets with the checkboxes. The selection persists across pages.
2. Click Add Permissions (N).

This starts one job per device with two steps: creating or verifying the reader IAM identities, then granting read through the IAM identity policy. Job-number links appear so you can monitor the jobs.

Select all N matching grants read access to every bucket that matches the current filters, across all pages and all devices, without checking each row.

1. Click Select all N matching.
2. In the confirmation dialog, review the matching count. When the filter spans multiple clusters, the dialog also shows how many grant jobs will start, one per cluster with matches.
3. Confirm. Buckets that already have read access are skipped.

To grant the common case of all COSI-discovered buckets that are not yet granted, set the COSI filter to COSI-discovered only and click Select all N matching.

Verify and repair

Add Permissions also verifies and repairs access. On every run the job re-checks the real state on ECS and corrects any drift.

• A missing IAM reader identity is recreated with a fresh key.
• Buckets that are already granted are checked against the live identity policy. If the grant is present, the result is Verified OK and nothing is written. If it is missing, the bucket is granted again and reported as Repaired.
• The summary reports Applied, Verified OK, Repaired (drift), and Failed separately.

To repair a broken estate, run Add Permissions again.

Service accounts

The Service accounts list shows the per-namespace read accounts for the selected device, or for all devices. Columns are Device, Namespace, Access Key, Secret, and Last Rolled.

The Access Key is the generated Access Key ID. For IAM accounts it differs from the user name. Accounts provisioned in earlier releases may still appear as the legacy {namespace}-aisec-ro object user until their next Add Permissions run moves them to IAM.

• Expand (chevron) — available on IAM accounts. Shows the account's managed policies (aisec-read-1 to aisec-read-N) and, under each, the buckets it grants, read live from ECS. This is the definitive view of what a reader can read.
• Revoke (per bucket) — removes only that bucket from the account's managed policy. The account keeps its other grants. Takes about 90 seconds to take effect.
• Eye icon — reveals the stored secret key. Click it again to hide the secret. The secret is selected in full for easy copying.
• Roll key (per account) — generates a new access key on ECS and stores it encrypted. For IAM accounts the previous key is deleted, which respects the ECS limit of two keys. The new value is shown immediately.
• Roll All Keys — rolls the key of every account, respecting the device filter (All rolls every cluster). Secrets are not shown in bulk. Use the eye icon afterward to view a specific one.

To grant more buckets to a reader, select them in the bucket inventory browser and click Add Permissions.

Deleted devices

The Deleted Devices panel at the bottom of the ECS section shows deleted devices. Each row shows:

• A Source type badge.
• The original endpoint.
• The deletion timestamp and the reason, if one was supplied.
• A jobs count of job records that still reference the device.

Each deleted device has three actions:

• Restore — returns the device to the active table with its original identity intact, so existing references continue to resolve.
• Purge — a shallow permanent delete. It removes the device, its service accounts, and its discovered bucket and namespace inventory. The device's collected audit, analyzer, and posture data stays in place and ages out under its own retention.
• Full Purge — an irreversible deep wipe of everything the console holds for the device: its configuration and encrypted credentials, all inventory, pod-to-bucket mounts, key-rotation records, and audit-ingest offsets, plus all of its audit events and its file-level analyzer (classification) and posture (transitions and baselines) data.

Full Purge shows an impact preview with the exact number of rows to be deleted per data store, and requires you to type the device name to confirm. It does not remove job history, which is kept as an audit trail, or anything on the remote storage device itself. The {namespace}-aisec-ro object users and bucket policies on ECS are left untouched, because Full Purge only affects the console.

Use Purge to tidy the device list while keeping historical data. Use Full Purge to reclaim storage and remove every trace of a decommissioned device.

PowerScale (Dell OneFS) clusters

Configure the PowerScale clusters whose audit logs you want to ingest. Audit logs are pulled over SSH/SCP from each cluster's SmartConnect FQDN. NFS-mount ingestion is not supported.

SSH fields

Field	Description
Name	Display name.
IP Address	A node IP. Used only by management features, not for ingest.
SSH Host	SmartConnect FQDN (preferred) or a node IP. Used for ingest.
SSH Port	Defaults to 22.
SSH User	The account used for the audit-log pull. Use a dedicated least-privilege account rather than root. See Product Prerequisites.
SSH Password	Stored encrypted (AES-256). When editing an existing cluster, leave the field blank to keep the stored value.
Audit Log Directory	Remote path on PowerScale. Defaults to /ifs/.ifsvar/audit/logs.
CSI Base Path	Audit filter prefix. Defaults to /ifs/data/csi. Only records under this prefix are ingested.
Enabled	Whether this cluster takes part in scheduled audit ingest. This is the ingest switch for the cluster, not a management API setting, even though the checkbox sits below the management fields.

OneFS management API fields

These fields are separate from the SSH fields and are used by different features. Audit ingest never uses the management API, so a cluster with incorrect management credentials still ingests normally.

Field	Description
Mgmt Host	IP or DNS name of the OneFS platform API. Leave the port off. The platform API is expected on the default port 8080.
Mgmt User	An account that holds the ISI_PRIV_LOGIN_PAPI privilege. This is usually the same account used for SSH.
Mgmt Password	Stored encrypted (AES-256). When editing an existing cluster, leave the field blank to keep the stored value.
Ignore TLS certificate errors on mgmt API	Selected by default. OneFS ships a self-signed certificate, so most deployments need this on. Clear it only if you installed a trusted certificate on the cluster.

The four action buttons

• Test SSH Connection — opens an SFTP session and reports reachability, credentials, and path. It walks the same audit-log layout the ingest uses, so the count reflects real audit files. No audit data is read.
  • The result names the detected layout: node-subdirs on a normal cluster, where files live at <node>/protocol/, flat on a single-node or test setup, or empty when the path holds nothing.
  • The count is a total across all nodes. Discover Files breaks the same files down by ingest state, so the two panels report the same files but not the same number.
  • If the result is 0 audit files, the message also shows what was found at the configured path, for example 1 subdir(s) [node001], 0 file(s) [], so you can tell an empty cluster from a wrong path.
• Test Mgmt API — signs in to the OneFS platform API with the Mgmt user and password, and reports the cluster's OneFS version on success. It uses a different port (8080), protocol, and possibly different credentials than Test SSH Connection, and a failure does not affect audit ingest.
  • If the message says the login succeeded but OneFS refused the request, the password and ISI_PRIV_LOGIN_PAPI are already confirmed. Check the account's privileges for that endpoint, or whether the platform API is restricted on the cluster. The message includes the reason OneFS gave.
• Discover Files — a read-only preview. Lists every file the ingest would process on the next run and shows each file's ingest status as NEW, IN_PROGRESS, or COMPLETE. No data is ingested.
• Run Ingest Now — the only button that moves data. It copies the discovered audit log files over SCP, decodes them, keeps the records under the CSI Base Path, and stores the resulting events.

All four buttons show their status line in the same fixed area directly beneath the button row, so the buttons do not move when you click one. Discover Files also shows its file listing in a larger panel below that area.

Ingest schedule

The PowerScale audit ingest schedule is global. Configure the interval and enabled state for all PowerScale clusters in Settings > System Jobs > Schedules.

Workflows

Add an ECS source device

1. Click Add Device in the ECS / ObjectScale section.
2. Enter the Device Name.
3. Enter the Node IPs as comma-separated ECS node IPs or hostnames.
4. Enter the Management Host / IP, Username, and Password for the ECS management API (port 4443).
5. Enter the Data Access IP or DNS Name, the S3 endpoint URL including scheme and port, for example https://10.x.x.x:9021.
6. Enter the SSH User, SSH Password, and SSH Port in the SSH Credentials section.
7. Click Test Auth to validate the management credentials and detect the device software version.
8. Click Save Settings. The button stays disabled until all required fields are filled in.
9. Click Run SSH Ingest Now and confirm that the first ingest completes without errors.

Add a PowerScale cluster

1. Click Add PowerScale Cluster.
2. Enter the display name, SSH Host (SmartConnect FQDN preferred), SSH User, and SSH Password.
3. Set the Audit Log Directory and CSI Base Path. The defaults are correct for stock PowerScale layouts.
4. Click Test SSH Connection to confirm that the credentials and path are reachable.
5. Click Save Settings.
6. Optionally, fill in the OneFS management API fields, click Save Settings again, and then click Test Mgmt API. Test Mgmt API reads the saved settings, so on an unsaved cluster it reports cluster not found instead of a credential result. This step is not required for audit ingest.
7. Optionally, click Discover Files to preview what will be ingested, then click Run Ingest Now to run the first ingest.