Audit logging is built into the same middleware that handles authentication and token decryption.
Entries for auditing
This auditing logs every request and its result to the audit db. This data is encrypted at rest. The dash_audit service provides a REST API interface to get access to audit records. The Audit service will decrypt the log entries.
Audit entries are considered requests of the form: [PUT], [POST], [DELETE] or modify, create and delete. [GET] is not considered an auditable event.
Transactions and Transaction ID's
Each request will create a UUID (Universally Unique ID) that is then included in the request's header. If a request already has a Transaction ID in it's header then it will be used instead of a new one being generated. These headers are then added to requests from The technical services to other technical services as well as being written into the audit records. This simple model enables us to review all the requests processed across all services in support of an initial API request into any microservice.
Transaction audit record retention
GET requests and OPTIONS requests are only retained in the audit DB for 7 days. This insures that we have access to all requests and can use this for the diagnosis of problems in production and elsewhere. However this also presents a very large and potentially unbound data set. As transactions are only useful for diagnosis of errors/defects this data is not retained more than 7 days.
Audit Record Encryption
Each service that is deployed requires an identical audit encryption key as part of the environment variables. This insures that each microservice's middleware instance can encrypt the data in a way that can be decrypted by the audit service.
Resource and Resource Identity for Audit Logging:
For PUT, PATCH and DELETE requests:
r.HandleFunc("/api/travis/v1/config/accounts/{account}", configHandler).Name("Account|{{.account}}") For POST requests we set it as a header as there is no resource identity in URL:
All other operations are handled as organization-level actions. Note the Audit view will be enhanced so that a Tenant Admin can see tenant-level actions or the actions of the organization they are currently working within. All other users will see the audit records solely for their organization.