Lamassu IoT DocsAudit logs
Understand which audit events Lamassu generates and how to turn them into a durable trail.
Lamassu instruments the mutable operations of its services with audit events. Each event describes the operation, the principals that matched, the input, the result and whether it ended in error.
What an event contains
The audit body includes:
input: data received by the operation;has_error: whether the service returned an error;output: produced result or error message;principals: identifiers of the principals that matched the request.
Successful operations use a type prefixed with audit.. Failures publish the operation type suffixed with .error. The CloudEvents event additionally adds source, identifier, date and type.
Failed attempts are audited too
The middlewares publish the record after executing the operation, whether it succeeded or returned an error. This lets you investigate attempts as well as confirmed changes.
Coverage
The backend applies auditing to mutations of:
- authorities, certificates and issuance profiles;
- keys and KMS engines;
- devices and identities;
- DMSs and enrollment operations;
- validation functions and CRL;
- principals, policies and authorization grants.
Do not confuse these events with domain events. A domain event announces that a resource changed so another component can react; the audit event keeps input, output and principal context for investigation.
Publication and persistence
Services publish audit records to the event bus when their PublisherEventBus is enabled. The backend code does not, by itself, implement a queryable, durable audit file.
The bus does not replace a compliance archive
If you need retention, search, tamper protection or regulatory export, connect a consumer that persists the events into the system approved by your organization.
Design the consumer to:
- subscribe to the
audit.#types and also to operation types ending in.error; - keep the complete CloudEvent unmodified;
- record the ingestion time and detect duplicates by ID;
- encrypt in transit and at rest;
- restrict reading and deletion to a role separate from the PKI operator;
- apply an explicit retention and legal hold policy;
- alert if it stops consuming or the pending queue grows.
Sensitive data
The input and output fields can contain subjects, metadata, public material, configuration or error messages. Evaluate their classification before sending them to an external platform.
Do not log private keys, provider secrets or full tokens in automations around Lamassu. Restrict export and apply redaction at the destination without destroying the fields needed for attribution.
A reproducible investigation
Bound the interval
Start from the reported time and normalize every source to UTC.
Identify the operation
Filter by event type, service source and resource identifier.
Attribute the principal
Review principals and correlate them with the OIDC provider or the X.509 identity valid at that moment.
Compare intent and result
Contrast input, has_error and output. A failed attempt does not mean the resource changed.
Follow the effect
Look for the domain events and service records that share resource and time window. In a CA revocation, include the cascading operations.
Periodic verification
Generate a controlled mutation in a test environment and check that:
- a successful audit event appears;
- the principal matches the identity used;
- the consumer persists it exactly once;
- it can be retrieved by resource, actor and period;
- a consumer outage raises an alert.
For metrics, traces and technical logs of the deployment, see Troubleshooting. Audit answers "who tried to change what"; observability explains how the system behaved.