Data Security Posture

The Data Security Posture page presents an interactive topology of storage relationships and security risk across your Kubernetes workloads. It shows at a glance which pods access which storage volumes and buckets, what risk is associated with each workload, and where PII has been detected.

Overview

The page builds a node graph from the most recent K8 scan data. Nodes represent users, pods, PVCs, buckets, and storage clusters. Edges represent relationships: which user owns a pod, which pod mounts which PVC or bucket, and which backend storage cluster holds each PVC or bucket. Node size and color reflect the risk level of the entity.

The topology fills the area below the top navigation bar. The page header, action buttons, filters, and the time-travel slider float over the canvas as translucent panels:

• Filter bar (top-left): search box, K8 cluster selector, namespace dropdown, and scheduler filter.
• Action bar (top-right): Fit, K8 inventory · lifecycle security, PII Layer, Risk Overview, and Recalculate Risk.
• Time-travel bar (bottom-center): step buttons, the time slider, the Live / Historical indicator, and the zoom controls with View.

Columns and entities

The topology is laid out in columns, left to right: Users → Pods → PVCs → Buckets → Storage Clusters. Each entity type has its own color and icon so you can pick out a column at a glance. A column appears only when it has at least one node, so a cluster with no object storage shows no Buckets column.

• Users: a user node links to the pods that belong to that user. The user comes from the RunAI workload user (the data scientist who submitted the job) for RunAI-managed pods, and for any other pod from the workload author in the Kubernetes API audit (the same identity shown in the Pod Creator column of File Activity). If the workload was only reconciled by a GitOps tool, the user is whoever last modified or deleted it. Kubernetes-internal system:* identities (controllers, service accounts, and nodes) are excluded as noise, except system:admin, which is the cluster admin running kubectl. This attribution requires the Kubernetes API-audit webhook, so a pod with no create, modify, or delete event in the window, or one that has already left inventory, may have no user node. The workload author appears only with the All CSI pods scheduler filter, and RunAI / nvidia shows RunAI users only. A small W badge marks a user inferred from a workload when no RunAI user was recorded.
• Pods: Kubernetes pods that have a PVC or bucket attached. Pods with no external storage (system and monitoring pods) are not shown.
• PVCs: persistent volume claims, backed by PowerScale through the Dell CSI driver.
• Buckets: ObjectScale buckets managed by COSI (the Container Object Storage Interface). Pods connect to a bucket through a COSI BucketAccess credentials Secret, and several pods can share a bucket. The COSI driver for ObjectScale must be installed for buckets to be discovered.
• Storage Clusters: PowerScale clusters (database icon) and ObjectScale devices (cloud icon), each labeled with its type.

Navigating the topology

• Click a node to highlight its data-access chain. Everything not on the chain dims to about 20% opacity. From a pod, the chain reaches the users that own it, the PVCs and buckets it mounts, and the storage clusters behind them. Click the node again or press Esc to clear the selection. This answers questions such as "which storage does this user touch?" or "if I take this PVC offline, which pods break?"
• Drag an empty area to pan, and use the mouse wheel to zoom. Zoom is anchored on the cursor. Fit fits the whole topology in the window, and View returns pan and zoom to the defaults.
• Dragging a node rearranges it for the current session only. Reloading the page restores the automatic layout.

Connection lines

The line style shows the type of relationship:

Connection	Line style
User → Pod	Thin solid line (ownership)
Pod → PVC	Medium dashed line in the pod's risk color (CSI mount)
Pod → Bucket	Medium dashed teal line (COSI mount)
PVC → Storage cluster	Thick solid indigo line (stored on PowerScale)
Bucket → Storage cluster	Thick solid teal line (stored on ObjectScale)

Animated dots appear only on the storage connections. Each PVC → storage connection also carries a storage-path pill showing the PVC's path. Hover the pill to see the full path, the owning PVC, the storage device, and the PVC's capacity and mount count.

Filters

Search

Type in the search box (Search pods, namespaces, PVCs, buckets…) to filter the topology as you type. A pod, PVC, or bucket matches when its name or namespace contains the text, and a user or storage cluster matches on its name. Results update after a short pause in typing. Matched nodes light up their connected chain, and non-matching nodes dim. A counter at the top-right of the canvas shows the number of matches. Clear the search with the × or by pressing Esc.

Cluster selector

Choose which K8 cluster to visualize. Only clusters that have been scanned at least once are listed.

Namespace filter

Select one or more namespaces to restrict the graph to workloads in those namespaces. This includes object-storage workloads: pods that mount only a COSI bucket are scoped by namespace like any other pod. A bucket is shown only while at least one pod in the selected namespaces mounts it. Deselect all namespaces to show the whole cluster again.

Scheduler filter

Switch between All CSI pods (the default) and RunAI / nvidia. Use the RunAI filter when your environment uses RunAI for GPU workload scheduling. Both modes show workloads that use only an ObjectScale bucket, so a data scientist whose workload writes only to object storage is fully traceable under either filter.

Time travel

The time-travel slider lets you review how the topology looked over the last 30 days. Moving the slider back re-draws the topology from the stored snapshots taken before the end of the selected day.

Controls

• Slider: the right edge is NOW (live data) and the left edge is the oldest available day. Drag the thumb, or click anywhere on the rail to jump there.
• ◀ / ▶ buttons: step one day back or forward.
• Keyboard (slider focused): ← one day older, → one day newer, PageUp one week newer, PageDown one week older, Home the oldest day, End today.
• Timestamp label: follows the thumb and reads LIVE · NOW on today, or the date with the number of days ago when scrubbed back.
• Live / Historical indicator: a green Live indicator on today, or Historical: YYYY-MM-DD (Nd ago) when scrubbed back.
• Reset to Today: appears on a historical date.

The slider range is limited by how long inventory snapshots are retained. If no snapshot exists for the selected day, for example because the system was not yet deployed, the topology is empty.

Delta view

On a historical date, the topology shows what changed since that day instead of a static snapshot. The graph is the union of now and then, and each pod, PVC, and bucket is tagged by how it changed:

• New (green): exists now but did not exist on the selected day.
• Deleted (red, faded): existed on the selected day but is gone now.
• Ephemeral (amber): appeared and disappeared within that same 24-hour day. Short-lived churn like this is worth a security review.
• Persistent: existed then and now, and is drawn without a badge.

Changed nodes show a NEW, DELETED, or EPHEMERAL badge and a distinct animation (a breathing pulse for new, an explode-and-vanish effect for deleted, a fade in and out for ephemeral). If your operating system is set to reduce motion, the nodes stay still and only the badge is shown.

To keep the graph readable, the delta view draws only the changed pods, together with the PVCs, buckets, and storage clusters those pods connect to. This keeps the line from a changed pod through to its storage, so you can see what a deleted pod was reading or what storage a new pod mounted. The header strip shows Δ vs {date} with the totals for new, deleted, ephemeral, and persistent entities. If nothing changed, the canvas shows No changes for this date.

Entities are matched by namespace and name (buckets by name), so a pod re-created with the same name on the same day counts as persistent. Only pods with a PVC or bucket take part, as in the live view.

On a historical date, risk scores are not available, so pods and PVCs are drawn in neutral colors.

PII layer

The PII Layer draws a translucent colored disc under each PVC, colored by its PII level (red, orange, yellow, or green). The layer is always on. PVCs with a PII score of 50 or higher (orange or red) also show a pulsing ring and a score badge. Click a highlighted PVC to open the PII detail panel.

Hover cards

Hover over a node to open a card with its details. The card follows the cursor and moves to the other side near the screen edge.

• Pod: namespace and pod name, risk score. If the pod has Kubernetes API activity, a View K8s API activity link also appears. See K8s API activity.
• PVC: namespace and PVC name, storage system and server IP, PowerScale export path, PV volume handle, capacity, PII score, top PII entity types, PII coverage, risk score, mounting pods, and a Created / Updated / Deleted by block.
• Bucket: COSI bucket name, ECS namespace, storage device, COSI account ID and claim, credentials Secret name, last-seen time, the pods that mount it, and a Created / Updated / Deleted by block.
• Storage cluster: for PowerScale, the server IP, number of provisioned PVCs, namespaces, and the highest-risk PVC. For ObjectScale, the device name, number of COSI-managed buckets, and their ECS namespaces.

Context menus

Right-click a pod, PVC, or bucket node to open a menu. The header shows the entity type and name.

• Query Audit Activity: opens File Activity for that entity. For a bucket it is pre-filtered to the ObjectScale source, the bucket name, and the bucket's ECS namespace. When the time-travel slider is on a historical day, the query is scoped to that day's 24-hour window and runs automatically. On Live, the default 1-hour lookback applies.
• Copy <Entity> Name: copies the name to the clipboard. The menu shows the name it will copy.
• View Storage Topology (PVC nodes): opens the storage topology detail for the volume, showing the full path from the Kubernetes PVC to the backend Dell storage export.

Right-click a user node to open its attributed reach: the workloads that identity authored, their pods, the PVCs and buckets those pods use, and the files involved. The panel:

• Shows the counts at each step.
• Lists each workload with a human or automation badge and its pod count.
• Shows the top PVCs as chips that link into File Activity filtered to that PVC.

It answers the investigator's question "alice deployed these workloads, so these pods, PVCs, and files are hers". The scope is the Kubernetes identity recorded in the audit as the actor who created, modified, or deleted a workload. An identity that never authored a workload, such as a RunAI submitter that appears only in RunAI, shows an empty chain with an explanation.

Press Esc to close any menu.

Example: review an incident from four days ago

1. Open Data Security Posture.
2. Drag the time-travel slider back four days.
3. The topology shows the pods, PVCs, and buckets as they were on that day.
4. Right-click the bucket of interest and choose Query Audit Activity.
5. The audit query opens pre-filled with the bucket and that day's time window, and shows that day's events.

Risk

Risk overview

Risk Overview opens a panel that summarizes risk across the entities currently shown, and respects the Scheduler and Namespace filters. It has three parts:

• Risk-level distribution: how many scored entities fall in each band (Critical, Very High, High, Medium, Low).
• What's driving risk (avg): the average contribution of each of the three sub-scores (Behavior, Data Classification, and Entropy). A high Data Classification bar means sensitive data is the main driver, and a high Entropy bar means tampered or encrypted-looking content is.
• Top risk: the highest-scoring users, pods, and PVCs, each with its score. Use it to go straight to the worst offenders.

How risk scores are calculated

A risk score is the sum of three sub-scores:

• Behavior: from RunAI and audit-log activity over the last 7 days.
• Data Classification (5–18): the weighted count of PII the AI risk pipeline found on the entity's storage. Credit card and SSN matches weigh the most, and emails, phones, and names weigh little. An entity with no detected PII has the minimum score of 5.0.
• Entropy / content integrity (2–8): driven by Linguistic Coherence verdicts on the entity's files. Content flagged as manipulation, garbage, or gibberish raises the score, and clean, readable content keeps it at the minimum of 2.0. Mixed and structured-data verdicts are neutral. The score is baseline-aware: a garbage verdict on a file whose content has always had high entropy (for example a recurring data dump) does not count, and only a file that deviates upward from its own history does. Files with too little history count every garbage verdict. Manipulation verdicts are never suppressed this way, because they signal tampered prose rather than high entropy.

To reduce false positives, a file must also be anomalous in at least two scans, and still anomalous on its latest scan, before it counts. A single transient blip is ignored, and a file that has recovered to clean stops counting. You can also allow-list known benign sources, by PVC or file key, so they never count. These controls affect only the risk score. The content-integrity drop alarm still fires immediately on a genuine change.

A pod or user shows the sub-scores of the PVCs it is recorded as mounting. The PVC's own risk row is the most direct place to read its PII and entropy contribution. Entities that hold sensitive data, or storage that looks tampered with or encrypted, rank higher than clean storage.

Recalculate risk

Recalculate Risk recomputes all risk scores on demand. The same recomputation runs automatically at the end of every K8 scan cycle (typically every hour). Use the button after a new PII classification run, to see the new scores without waiting for the next scan. The button is disabled while the recompute runs, and the topology refreshes when it completes.

K8s API activity

Hovering a pod shows View K8s API activity (N events) on the pod hover-card. It opens a flyout that answers the question "who did what to this pod, through the Kubernetes API, while it was alive?" The link is hidden when the pod has no API activity.

For Created, Last updated, and Deleted, the actor is shown with one of four origins:

• Direct: the identity named on the API request for this pod. This is the strongest evidence.
• Inherited: shown with a via Kind/name badge (for example via Deployment/alice-bert-finetune). A controller creates pods from a Deployment, StatefulSet, Job, or CronJob, so the creator is inherited from the identity that authored the root workload. This means the person authored the workload that created the pod, not that they created the pod directly, and the two can be months apart.
• Correlated: shown with an amber via API response badge. A pod applied directly with a generated name has no workload above it, so the creator is recovered from the Kubernetes API response instead. It is a real person, found in a different part of the same audit event.
• Not resolved: no identity could be determined. Either the pod is newer than the last inventory scan, and will resolve on the next one, or nothing has been captured. This is an honest absence and never reads as "nobody".

Each actor also carries a person or automation tag and the time of the action.

The flyout also shows the window the counts cover, and whether the pod is still alive. It contains:

• Counts strip — total events, ok, denied (4xx), 5xx, and the number of distinct actors. Denied attempts against a pod are highlighted, because they are usually the interesting signal.
• Verbs and Top actors — a summary of the traffic. Each top actor links to the User Actions view filtered to that identity.
• Raw events — the matching API calls, loaded on demand. When a controller-created pod's CREATE event is not in that list, a note says so, because the inherited creator is shown in the actor attribution at the top of the flyout.

Storage creator attribution

Hovering a PVC or bucket shows a Created by / Updated by / Deleted by block, resolved to a person wherever the Kubernetes API audit supports it. It uses the same origins as pod attribution:

• Direct: a person applied the PVC (for example with kubectl apply) or the bucket's BucketClaim. The identity is tagged person or automation.
• Inherited: shown with a via Kind/name badge (for example via StatefulSet/runai-scientist). Storage is often created by a controller, such as the statefulset-controller for a StatefulSet's PVC, or the COSI controller for a bucket. When the direct actor is automation, the creator is inherited from the person who authored the workload that mounts the storage, and the controller is shown on a provisioned by … line beneath.
• Not resolved: no direct event and no mounting-workload attribution yet, for example because the storage is newer than the last scan.

A bucket created directly on ObjectScale has no Kubernetes object and no audit event, so its card reads created outside Kubernetes — no K8s audit record. Attributing it would require ObjectScale's own audit trail.

Attribution is resolved on each K8 scan and stored, so the creator is kept even after the source audit event ages out. It requires the Kubernetes API-audit webhook to be configured under Settings > K8s Audit. Without it, storage cards read "not resolved".

Workflows

Identify the highest-risk pod in a namespace

1. Select the cluster in the cluster selector.
2. Use the namespace filter to select the namespace of interest.
3. Look for the largest pod nodes in the graph. Larger nodes indicate higher risk.
4. Click a pod node to highlight its PVC and storage connections.

Check which pods have accessed PII-tagged volumes

1. Identify the PVC nodes highlighted by the PII Layer.
2. Follow the connections from those PVC nodes to the pods that mount them.

Tips

• The topology reflects the most recent completed scan. If you just deployed a new pod, trigger a manual K8 scan from the Jobs page and then select Recalculate Risk.