Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.

User Actions

The User Actions tab answers "what did this user do in Kubernetes?" It is the inverse of the Pod Creator column. File Activity starts from a file or object and resolves who was behind it. User Actions starts from a user and lists every action that the user took against the Kubernetes API, drawn from the Kubernetes API audit stream.

Where: File Activity > User Actions

The tab requires Kubernetes API audit ingestion (Settings > K8s Audit). Without it, there is no audit stream to search. See Kubernetes API Audit Ingestion for setup.

Pick a user​

The User dropdown lists every identity in the audit stream, with the most active first and an action count for each. Select one identity, or leave All users selected to browse the actions of everyone and narrow the results with the other filters.

A user is the username exactly as it appears in the cluster's audit events:

  • A person, for example jane@corp.com or an OIDC subject.
  • A Kubernetes service account, in the form system:serviceaccount:<ns>:<name>.
  • A controller, for example system:...:replicaset-controller.

If an administrator acted as another identity (kubectl --as=…), the row shows the original actor and an as <user> tag with the impersonated identity. The real actor is never hidden.

Filters​

FilterDescription
UserThe identity.
VerbThe API action: get, list, or watch (reads), or create, update, patch, or delete (writes). Whether reads appear depends on your audit policy. The recommended policy drops read-only verbs because of their volume.
ResourceThe object type, for example pods, deployments, secrets, configmaps, serviceaccounts, roles, rolebindings, or persistentvolumeclaims.
NamespaceLimits the results to one namespace.
ResponseThe HTTP status that the API returned, for example 200, 403 for a denied action, or 404.
ClusterThe source cluster, which is the clusterId that you chose when you configured the webhook.
Time1h, 24h, 7d, 30d, or 90d. A lower time bound is always applied.

Read the results​

The summary strip shows totals for the current filter:

  • The total number of actions.
  • The 2xx, 4xx, and 5xx split.
  • The number of distinct resources and namespaces touched.
  • The time of the last activity.

The verb chips are clickable. Click a chip to filter to that verb only.

The table lists one row for each action, with these columns: Time, User, Verb, Resource, Namespace, Name, Response, Source IP, and Cluster. A red or amber Response marks denied (403) or failed actions. These help you find a user who hits permission limits, or a misbehaving controller.

Results are paginated, with 100 rows per page. The CSV button next to Search exports the actions for the current filter to a CSV file, up to 1000 rows.

Storage reach​

When you select a single user, a Storage reach tile appears above the filters. It shows the chain from the user to pods, PVCs and buckets, and files, and how far the activity of the user in Kubernetes reached into storage:

  • The number of pods that the user touched.
  • How many of those pods had storage activity.
  • The number of PVCs and buckets that those pods accessed.
  • The resulting storage events and files.

The Top PVCs chips link to File Activity filtered to that PVC, so you can go from the pods of a user to the files that were touched.

The counts come from the audit streams. The pod names of the user come from the Kubernetes API audit, and they are matched by pod name to the PowerScale and ObjectScale storage audit.

Cross-navigation​

  • Click a user in a row to filter the whole view to the actions of that user.
  • On a pod action, click File activity to open File Activity filtered to that pod. This takes you from "this user created or deleted this pod" to "which files or objects did that pod touch". The full chain is user, pod, PVC or bucket, and files.

Troubleshooting​

  • Empty results, or the message "confirm the webhook is receiving events" — Kubernetes API audit ingestion is not enabled or no events are arriving. Check Settings > K8s Audit, where the receiving-health badge must be green, and widen the time range.
  • A user you expect is missing — the audit stream contains only activity after the webhook was configured, and the audit policy can drop read-only verbs. Also confirm the Cluster filter.
  • Reads (get and list) do not appear — this is expected with the recommended audit policy, which drops read-only verbs because of their volume. Adjust the audit policy of the cluster if you need them.