Skip to main content
Astro Private Cloud (APC) audit logging produces a structured, per-action record of administrative activity on the Astro Private Cloud control plane. Each event captures who performed the action, what was changed, and the outcome. Events are emitted as JSON by the APC API and APC Worker components and are shipped to one configured external sink by a Vector sidecar. Use audit logging to support internal compliance programs, answer after-the-fact questions about control plane changes, and investigate security events.
APC audit logging is introduced in Astro Private Cloud 2.x.

​
What gets audited

APC audit logging emits an audit event for each successful or failed administrative action, including:
  • Workspace and Deployment lifecycle changes.
  • User, team, service account, and role binding changes.
  • Authentication events such as sign-in, sign-out, and password reset.
  • Cluster registration and cluster configuration changes.
  • Background worker operations that modify Deployments or cluster state.
Each event is a JSON object with stable field names. For the full event schema, the list of audited operations, and message formatting rules, see Audit log schema and operations.

​
How it works

APC audit logging uses a Vector sidecar that runs alongside the APC API and APC Worker Pods.
  1. The APC API writes structured JSON events to standard output as it normally does.
  2. A built-in log wrapper script tees the APC API’s output to a shared volume that the Vector sidecar reads.
  3. Vector parses each line, keeps only entries where audit == true, adds Kubernetes and platform metadata, normalizes the timestamp to @timestamp, and converts the level field to uppercase.
  4. Vector delivers the transformed event to the configured sink.
APC audit logging doesn’t depend on the sidecar. If the sidecar is disabled, the APC API continues to emit audit events to standard output.

​
Supported sinks

Each sink is supported on a specific Kubernetes platform for the Astro Private Cloud control plane. Cross-cloud configurations, such as shipping to AWS CloudWatch Logs from a GKE cluster, aren’t supported.
For this release, exactly one sink can be enabled per installation. Enabling more than one sink results in a Helm validation error. Enabling the sidecar without a sink also fails validation.

​
Default state

APC audit logging is disabled by default. The sidecar isn’t injected and no audit events are shipped to any external system until you enable it through Helm values. Because APC audit logging always writes audit events to standard output, you can inspect recent events with kubectl logs on the APC API or APC Worker Pods even when the sidecar is disabled. Use the sidecar when you need durable, long-term retention in a sink that you can query.

​
Next steps