Auditing Service#

Changed in version 2.0.

ESS Auditing service audits various activities from the ESS services, including itself.

By default, auditing is enabled and logs the audit events to sysout.

Note

Auditing service continues to run when auditing is disabled; instead, disabling auditing stops the ESS services from publishing audit events.

Audit Events#

Note

To ensure that audit messages are delivered, the Audit service may send the message more than once.

For instance, multiple instances of the Audit service may exist when applying configuration changes or when performing a rolling upgrade. During this time, duplicate messages (i.e., messages with the same unique id value) can occur if the old Audit instance processes a message but shuts down before acknowledging the message on Kafka, and then, the new Audit instance processes the unacknowledged message.

The following events are audited:

Services	Event Name	Notes
Most Services [3]	`service-started` `service-shutdown`	Service Startup/Shutdown.
Access Grant Service	`access-grant-activated` `access-grant-created` `access-grant-queried` `access-grant-read` `access-grant-revoked` `access-grant-verified` `access-request-activated` `access-request-created` `access-request-read` `access-request-revoked` `access-request-verified` `access-denial-activated` `access-denial-created` `access-denial-read` `access-denial-revoked` `access-denial-verified` `request-authorized` [1] `revocation-status-read` [2]	Access Request/Grant/Denial lifecycle events. [1] `request-authorized` events contain additional information (such as the access grant service endpoint, the WebID, client id, etc.) for authenticated access requests/grants/denial events. For these events, you can find the corresponding `request-authorized` event using the instrument field. [2] As part of the access grant to UMA access token exchange (which is an unauthenticated event), `revocation-status-read` events occur. These `revocation-status-read` events, which are also unauthenticated, do not have an associated `request-authorized` event. New in version 2.1.5.
Authorization Service	`acr-created` `acr-updated` `acr-deleted` `provisioned-pod-access-control` `deprovisioned-pod-access-control`	ACR Lifecycle events.
Pod Storage Service	`resource-created` `resource-updated` `resource-deleted`	Resource Lifecycle events.
	`resource-read`	Successful resource read events (`GET` and `HEAD` operations). To enable, see `INRUPT_STORAGE_AUDIT_RESOURCE_READ_ENABLED` configuration for Pod Storage Service. New in version 2.1.
Pod Provision Service	`pod-provisioned`	Pod Provisioning.
Query Service	`query-succeeded`	Query events.
Query Indexer	`ingest-succeeded` `ingest-failed`	Query Indexer events.
Solid OIDC Broker Service	`openid-backend-idp-login` `openid-token-requested` `openid-authorization-initialized`	Authentication/Authorization flow.
UMA Service	`uma-token-created`	UMA Grant Flow.
WebID Service	`webid-created` `webid-updated` `webid-deleted`	WebID Profile events.

Audit Event Message Internal Format#

Internally, ESS’ audit event messages are in RDF and serialized as ActivityStreams 2.0 JSON-LD documents:

Note

Although the following document shows all possible fields for an event message, the specific events determine which fields appear.

{
   "@context":[
      "https://www.w3.org/ns/activitystreams",
      "https://schema.inrupt.com/audit/v1.jsonld"
   ],
   "id":"<UUID of the event>",
   "type": [ "Activity", <type2>,... ],
   "name":"<event name>",
   "summary": "<event description>",
   "generator": <JSON document identifying the software producing the event>,
   "actor": [ <JSON document identifying the actor associated with the event>, ... ],
   "object": [ <JSON document identifying the object associated with the event>, ... ],
   "instrument": [ <JSON document identifying the client/application associated with the event>,
                   <JSON document with associated OpenTelemetry data>... ],
   "result": [ <JSON document containing associated results for the event, if any> ],
   "published": "<datetime>",
   "identifier":"<identifier to use for correlated events>"
}

`@context`	Specifies the JSON-LD contexts.
`id`	Universally Unique IDentifier (UUID) for the event.
`type`	An array of event types; e.g., `[ "Activity", "Create" ]`
`name`	Name that denotes the event; e.g., `service-started`, `openid-backend-idp-login`, `resource-created`, `access-grant-created`, etc. See Audit Events for a list of audited events names.
`summary`	Short description associated with the message `name`.
`generator`	JSON document identifying the software (e.g., service) producing the event. For example, the `generator` for a Pod provision event: "generator": { "id": "<service URL>" "type": ["SoftwareApplication"], "name": "<application name>", "qualifiedAssociation": "<processId>", "wasAssociatedWith": "<Kubernetes pod name>" }
`actor`	An array of JSON documents that identify the agents associated with the event. The actor’s identity can be denoted by various combination fo fields, such as (list below is not exhaustive): `id` field; `id` and `type` fields; `name` field. The `actor` field can also be empty (`[]`) for events not initiated by a user (such as service start events, etc.) For example: For a Pod provision event: "actor": [ { "id": "https://id.example.com/someusername" } ] For an Access Request/Grant event, which include the `id` and the `type` (to distinguish between Agent’s WebID and Client ID): "actor" : [ { "id" : "https://id.example.com/someusername", "type" : [ "Agent" ] } ], For IdP login events: "actor": [ { "name": "someusername" } ]
`object`	An array of JSON documents that identify the objects associated with the event; that is, the object(s) against which the action is performed. The object can be denoted by various combination of fields, such as (list below is not exhaustive): `id` field; `id` and `type` fields; `name` field. For example, for a Pod provision event: "object": [ { "type": [ "Storage" ], "id": "<PodURL>" } ] For access request/grant/denial creation events (available starting in version 2.1.5), the object may be the created access request/ grant/denial. Starting in version 2.1, CRUD events, which consist of the resource lifecycle events (`resource-updated`, `resource-created` and `resource-deleted`) as well as the `resource-read` events, include an object (with `type` value `StorageCreator`) that identifies the Pod owner (i.e., the agent designated as the owner during Pod provision): "object": [{ ... }, { "id": "https://id.example.com/someusername", "type": ["StorageCreator"] } ]
`instrument`	An array of JSON documents that identify: The clients associated with the event, if any (events such as `service-started` do not have associated clients). For example: "instrument" : [ { "id" : "https://start.example.com/app/id" } ], The associated OpenTelemetry instrument info for Access Grant service events. (Starting in 2.1.5) For example: "instrument" : [ { "traceId" : "7decd3657a9efffc010a4b6a4b3da586", "spanId" : "91123fce3c668451", "isSampled" : true, "name" : "OpenTelemetry Span Context", "type" : [ "SpanContext" ] } ],
`result`	An array of JSON documents that contains associated results. For example, an `access-request-verified` event includes the results of the verification, or an `access-grant-revoked` or an `access-grant-activated` event includes the updated status. New in version 2.1.5.
`published`	The timestamp of the event.
`identifier`	Identifier to use for correlated events from a service that have occurred within the same request.

For example, the following is an audit event fired by the Broker service for a new token request:

The openid-token-requested occurs for both new and refresh token requests. The summary field specifies whether the event is for a new or a refresh token.

{
   "@context" : [
      "https://www.w3.org/ns/activitystreams",
      "https://schema.inrupt.com/audit/v1.jsonld"
   ],
   "id" : "urn:uuid:5e1fd8ef-c450-4ff9-95fd-dee10cf033b1",
   "type" : [
      "Activity",
      "Delegation",
      "AuthorizationCodeFlow"
   ],
   "name" : "openid-token-requested",
   "summary" : "A new token was requested via refresh code flow",
   "generator" : {
      "name" : "inrupt-openid-postgres",
      "qualifiedAssociation" : "46",
      "wasAssociatedWith" : "ess-openid-6759db7777-flvzs",
      "id" : "https://openid.example.com/",
      "type" : [
         "SoftwareApplication"
      ]
   },
   "actor" : [
      {
         "id" : "https://id.example.com/owliverowner"
      }
   ],
   "object" : [
      {
         "scope" : [
            "offline_access",
            "openid",
            "webid"
         ],
         "name" : "refresh_code"
      }
   ],
   "instrument" : [
      {
         "name" : "Client Application",
         "id" : "https://myApp.example.com/appids/app.jsonld"
      },
      {
         "traceId" : "8609025418643bcb2c3981f1e2bc5163",
         "spanId" : "d016ead32c61ac5c",
         "name" : "OpenTelemetry Span Context",
         "isSampled" : true,
         "type" : [
            "SpanContext"
         ]
      }
   ],
   "result" : [ ],
   "identifier" : "2708696431494132ada7c43d68998449",
   "published" : "2023-07-20T22:08:39.506179932Z"
}

For more examples, see Appendix: Audit Events Examples.

Integration with Syslog#

The ESS Auditing service can integrate with Syslog. When integrating with Syslog, ESS audit events are converted to Syslog message format:

<priority>version timestamp hostname service processId messageId message

Where:

hostname, service, processId and messageId values are taken extracted from the audit event agent field.
message is the full ESS audit event message in JSON.

For example (the event message has been abbreviated):

<110>1 2022-01-12T20:17:08.387Z ess-pod-storage-84648cfc95-qs865 inrupt-storage-postgres-s3 85 urn:uuid:579668c1-4e14-4fad-aea3-0000000005 { "@context": [ "https://www.w3.org/ns/activitystreams", "https://schema.inrupt.com/audit/v1.jsonld" ], "id": "urn:uuid:579668c1-4e14-4fad-aea3-0000000005", "type": ["Activity", "Create"], "name": "resource-created", "summary": "Resource has been created", ... }

By default, the Auditing service logs to sysout. To have the service output to Syslog instead, see Manage Auditing.

Integration with Sentinel#

The ESS Audit service can integrate with Microsoft Sentinel

When integrating with Microsoft Sentinel, the ESS audit events are converted into a Sentinel-specific format and POST’ed to the Sentinel service.

By default, the Auditing service logs to sysout. To have the service output to Sentinel instead, see Manage Auditing.

Configuration#

As part of the installation process, Inrupt provides base Kustomize overlays and associated files that require deployment-specific configuration inputs.

The following configuration options are available for the service and may be set as part of updating the inputs for your deployment. The Inrupt-provided base Kustomize overlays may be using updated configuration values that differ from the default values.

Auditing Service: General Configuration#

QUARKUS_HTTP_PORT#

Default: 8080

The HTTP port the audit service runs on.

QUARKUS_LOG_LEVEL#

Default: INFO

Logging level.

Audit Service: Kafka#

Tip

Auditing Service: Syslog Configuration#

By default, the Auditing service logs to sysout. To have the service output to Syslog instead:

Customize your deployment to output to Syslog. See Manage Auditing for details.
Update configuration for Syslog integration. The following configuration options are available for integration with Syslog.

INRUPT_AUDIT_SYSLOG_HOST#

Default: localhost

The syslog server hostname that the audit service will connect to.

INRUPT_AUDIT_SYSLOG_PORT#

Default: 514

The syslog server port that the audit service will connect to.

INRUPT_AUDIT_SYSLOG_PROTOCOL#

Default: TCP

The protocol used to connect to the syslog server. Valid values are:

TCP
SSL_TCP

Auditing Service: Sentinel Configuration#

By default, the Auditing service logs to sysout. To have the service output to Microsoft Sentinel instead:

Customize your deployment to output to Sentinel. See Manage Auditing for details.
Update configuration for Sentinel integration. The following configuration options are available for integration with Microsoft Sentinel.

INRUPT_AUDIT_SENTINEL_API_VERSION#: The Sentinel API version.

INRUPT_AUDIT_SENTINEL_LOG_TYPE#

Default: Audit

The Sentinel Log-Type of the message.

INRUPT_AUDIT_SENTINEL_SHARED_KEY#: Shared key used to access the Sentinel API.

INRUPT_AUDIT_SENTINEL_WORKSPACE_ID#: Workspace ID used to access the Sentinel API.

QUARKUS_REST_CLIENT_SENTINEL_API_URL#: The Sentinel base URL that the audit service will connect to.

Auditing Service#

Audit Events#

Audit Event Message Internal Format#

Integration with Syslog#

Integration with Sentinel#

Configuration#

Auditing Service: General Configuration#

Audit Service: Kafka#

Auditing Service: Syslog Configuration#

Auditing Service: Sentinel Configuration#

Additional Information#