Skip to content

Audit Log

EasyLab records a lightweight audit trail of lab, workspace, and credential actions: who did what, and when.

Viewing the audit log

Navigate to Audit Log in the admin sidebar. The page lists the 200 most recent recorded actions, newest first:

  • Time — when the action was recorded
  • Actor — the email of the person who performed the action, or a generic label (see the identity caveat below)
  • Role — admin, student, or system
  • Action — e.g. lab.create, workspace.delete, credentials.set
  • Lab — the affected lab's ID, when applicable
  • Detail — a short, human-readable note (stack name, workspace name, or similar) — never a credential, kubeconfig, or secret

If nothing has been recorded yet, an empty state is displayed.

A single lab's own entries are also shown, pre-filtered, in the Activity section of its detail page — handy when you only care about one lab's history rather than scanning the global log.

What's tracked

  • Lab actions: create, dry run, launch, destroy, retry (with or without an edited configuration), recreate, delete, template upload, template removal, template promotion from another lab (lab.template_promote, recorded on the target lab), lifecycle edit, closing or reopening a lab to new students (lab.disable / lab.enable), closing or reopening one template (lab.template_disable / lab.template_enable, with the template name as detail)
  • Workspace actions: student-initiated creation, student-initiated deletion (Clear / Clear All on the My Workspaces page), admin-initiated deletion (single, bulk, or as part of removing a template), an admin opening a student's workspace (workspace.open), a workspace being paused for inactivity (workspace.stop, role system, with the idle timeout as detail) and its owner resuming it (workspace.resume)
  • Credential changes: saving OVH or Azure credentials (the credential values themselves are never recorded)
  • Credential storage actions: setting or changing the passphrase (credential_vault.set_passphrase / credential_vault.change_passphrase), unlocking (credential_vault.unlock), a failed unlock (credential_vault.unlock_failed), locking (credential_vault.lock) and resetting (credential_vault.reset) — never the passphrase
  • DNS profile changes: dns_profile.create, dns_profile.update, dns_profile.delete, with the profile name and provider as detail — never its credentials
  • Detect from cluster scans (cluster.detect), recorded whenever an admin runs one, with only what was found as detail (Kubernetes version, node count, ingress controller location and class, cert-manager namespace and ClusterIssuer count, warning count) — never the kubeconfig or the API server address
  • Admin viewing the shared student portal login password
  • Admin saving the GitHub login settings (github_auth.update, with whether it is enabled and for which organizations as detail — never the client secret)
  • Admin saving the GitLab login settings (gitlab_auth.update, with whether it is enabled, the GitLab host and the allowed groups as detail — never the secret)
  • Automatic (system) actions: workspaces deleted for exceeding their configured lifetime, labs auto-destroyed past their scheduled deletion date

Admin identity caveat

EasyLab's classic admin login is a single shared password (LAB_ADMIN_PASSWORD) with no concept of individual admin accounts — so an action taken by an admin who signed in this way is recorded with the generic actor admin, not a name. If Azure AD admin login is configured, the real signed-in email is used instead, since that flow verifies the admin's identity against your directory. Student actions (workspace creation and deletion) always show the student's real email, since student login always identifies an individual.