Skip to content
Alien Giraffe

Observability & Audit

Alien Giraffe is designed to provide operational visibility without weakening the data-access boundary. In the current implementation, observability comes from a combination of control-plane service logs, direct audit records written by a10e-manager, and optional Fluentd sidecars that enrich and forward runtime logs from request environments.

Observability layers

Section titled “Observability layers”

The platform generates structured operational signals at multiple layers:

  • control-plane services, including request intake, policy evaluation, orchestration, and environment lifecycle
  • audit events written directly by a10e-manager into the central audit store
  • tunnel access surfaces, including tunnel lifecycle events, credential use, and tunneled query activity
  • data enclave execution, including provisioning, pull start, pull completion or failure, credential clearing, API enablement, teardown, and structured application logs

This allows operators to understand what happened without granting blanket runtime access into the enclave itself.

Logging model

Section titled “Logging model”

The implementation uses two complementary paths:

a10e-manager service and audit path:

  • control-plane services log through the application logger
  • audit events are inserted directly into the audit_logs table with source a10e-manager
  • direct audit entries include actor identity, action type, resource type and id, level, IP address, and structured metadata

Fluentd enhancement path:

  • when Fluentd is enabled, request environments get a Fluentd sidecar
  • Fluentd tails structured JSON logs from the shared application log volume
  • Fluentd also exposes a forward input on port 24224 for forwarded runtime events
  • Fluentd enriches runtime logs with environment and request metadata before routing them to configured outputs

This keeps control-plane auditing available even without Fluentd, while allowing richer runtime observability when Fluentd is enabled.

Request and tunnel visibility

Section titled “Request and tunnel visibility”

Operational visibility is most useful when it can be tied back to a specific request and access path. In practice, that means operators should be able to correlate:

  • request creation, approval, activation, revocation, and expiry
  • enclave provisioning and readiness
  • approved pull start, completion, and failure
  • credential-clear completion before interactive access
  • tunnel creation and deletion
  • tunnel credential use
  • tunneled query execution
  • runtime startup, failures, and teardown

This gives operators a direct line from request intent to access behavior without relying on unrestricted runtime access.

Audit event model

Section titled “Audit event model”

The current implementation records concrete request and tunnel events, including:

  • request approval, denial, and revocation
  • tunnel creation and deletion
  • tunnel credential use
  • explorer query execution
  • tunneled query execution

These records are stored in the audit_logs table and can be filtered by fields such as action_type, actor_email, resource_type, resource_id, and source.

Audit model

Section titled “Audit model”

Auditability is treated as a first-class architectural concern. A useful audit trail should answer:

  • who requested access
  • what data source or dataset path was involved
  • what policy outcome was reached
  • when the approved pull started and finished
  • when credentials were cleared and inbound access was enabled
  • what operations were executed
  • which tunnel or credential was used when access happened through a managed tunnel
  • when the enclave was created and destroyed

This makes the architecture more suitable for security review and for environments with formal compliance requirements.

Fluentd-enhanced capabilities

Section titled “Fluentd-enhanced capabilities”

Fluentd extends the built-in observability model by enriching environment logs with request and environment context and then fanning them out to additional destinations.

When enabled, Fluentd adds fields such as:

  • environment_id
  • environment_name
  • stage
  • app_name
  • container_id
  • source
  • action_type
  • resource_type
  • resource_id
  • ip_address

This is especially useful for runtime logs coming from env-enzo, because those logs can be correlated with the request and retained alongside control-plane audit records.

Fluentd connectors

Section titled “Fluentd connectors”

The current Fluentd image and configuration support these output connectors:

  • PostgreSQL, via fluent-plugin-sql, writing enriched records into audit_logs
  • Slack, via fluent-plugin-slack, for selected alerting levels
  • S3, via fluent-plugin-s3, for archival export

Fluentd can write to multiple enabled outputs in parallel, so organizations can keep a central relational audit trail while also sending alerts and long-term archives to other systems.

Direct vs Fluentd query auditing

Section titled “Direct vs Fluentd query auditing”

Explorer and tunnel query activity can be recorded through either direct a10e-manager audit writes or Fluentd-backed runtime logs, depending on deployment configuration.

  • without Fluentd, a10e-manager writes explorer and tunnel query audit events directly into audit_logs
  • with Fluentd enabled, env-enzo structured logs are expected to be captured, enriched, and inserted by Fluentd with source fluentd

This means Fluentd is an enhancement of audit and observability capabilities, not a replacement for the control-plane audit path.

Compliance-oriented design

Section titled “Compliance-oriented design”

The platform is intended to support compliance-sensitive deployments by making runtime behavior traceable and by separating:

  • request approval from runtime execution
  • data ingestion from inbound interactive access
  • audit retention from ephemeral runtime state
  • operational telemetry from raw credential material

The exact compliance posture still depends on deployment choices and organization controls, but the architecture is designed to support programs such as SOC 2 or HIPAA-aligned environments.

Section titled “Related pages”