Skip to content

An access authorization event is an event that Aembit generates that occurs whenever an Edge Component requests access to a Server Workload. When Aembit receives an access request, the generated events include detailed information, providing a granular view of the processing steps to evaluate the request against an existing Access Policy. Once Aembit Cloud processes the request and the evaluation is complete, a result is generated that specifies if access is granted or denied (success or failure).

Having the ability to view information about these access authorization events enables you to not only troubleshoot issues, but also have a historical records of these events. You may also use these logs to perform threat detection analysis to ensure malicious actors and workloads don’t gain access to your resources.

The three different types of access authorization events that you may view in the Aembit Reporting dashboard include:

  • Access Request
  • Access Authorization
  • Access Credential

An access.request event captures the request and associated metadata.

An example of an access.request event type is shown below.

{
"meta": {
"clientIP": "1.2.3.4",
"timestamp": "2024-09-14T20:29:11.0689334Z",
"eventType": "access.request",
"eventId": "5b788a92-accd-49a1-851f-171f7c20d355",
"resourceSetId": "ffffffff-ffff-ffff-ffff-ffffffffffff",
"contextId": "4e876ace-d1b0-4095-ac22-f9c0fb7e676a",
"severity": "Info"
},
"clientRequest": {
"version": "1.0.0",
"network": {
"sourceIP": "10.0.0.15",
"sourcePort": 53134,
"transportProtocol": "TCP",
"proxyPort": 8080,
"targetHost": "server.domain.com",
"targetPort": 80
}
}
}

In an access.authorization event, you can view detailed information about the steps Aembit Cloud Control Plane undertakes to evaluate an Access Policy. Information shown in an access authorization event includes event metadata, the outcome of the evaluation, and details about the identified Client Workload, Server Workload, Access Policy, Trust Providers, Access Conditions and Credential Provider.

The following example shows the type of data you should expect to see in an access authorization event.

{
"meta": {
"clientIP": "1.2.3.4",
"timestamp": "2024-09-14T20:29:11.0689334Z",
"eventType": "access.authorization",
"eventId": "5b788a92-accd-49a1-851f-171f7c20d355",
"resourceSetId": "ffffffff-ffff-ffff-ffff-ffffffffffff",
"contextId": "4e876ace-d1b0-4095-ac22-f9c0fb7e676a",
"severity": "Info"
},
"outcome": {
"result": "Unauthorized",
"reason": "Attestation failed"
},
"clientWorkload": {
"id": "7c466803-9dd4-4388-9e45-420c57a0432c",
"name": "Test Client",
"result": "Identified",
},
"serverWorkload": {
"id": "49183921-55ab-4856-a8fc-a032af695e0d",
"name": "Test Server",
"result": "Identified",
},
"accessPolicy": {
"id": "dd987f8c-34fb-43e2-9d43-89d862e6b7ec",
"name": "Test Access Policy",
"result": "Identified",
}
"trustProviders": [{
"id": "24462228-14c1-41a4-8b23-9be789b48452",
"name": "Kerberos",
"result": "Attested"
},{
"id": "c0bd6c06-71ce-4a87-b03c-4c64cb311896",
"name": "AWS Production",
"result": "Unauthorized",
"reason": "InvalidSignature"
},{
"id": "5f0c2962-2af4-4b5f-97c0-9046b37198a9",
"name": "Kubernetes",
"result": "Unauthorized",
"reason": "MatchRuleFailed",
"attribute": "serviceNameUID",
"expectedValue": "foo",
"actualValue": "bar",
}],
"accessConditions": [],
"credentialProvider": {
"id": "bb7927f8-060c-4486-9a5e-bcbe1efc53d6",
"name": "Production PostgreSQL",
"result": "Identified",
"maxAge": 60,
}
}

If an authorization request fails during the check, a reason property value is returned in either the trustProviders and/or accessConditions elements notifying you that a failure has occurred, and providing a reason for the failure. By providing you a reason for the failure, you can then use this information to diagnose and troubleshoot the issue.

There are several different types of reason values that can be returned with a failure. Some of these values include:

  • NoDataFound - Attestation didn’t succeed because the necessary data wasn’t available.
  • InvalidSignature - The cryptographic verification check failed.
  • MatchRuleFailed - The match rules for the Trust Provider weren’t satisfied.
  • ConditionFailed - The Access Condition check failed.

In the example shown above, notice that the Trust Providers check failed.

For the Trust Provider ID 5f0c2962-2af4-4b5f-97c0-9046b37198a9 here for this example, the reasons specified in the JSON response are:

  • MatchRuleFailed

With this information, you can determine that not only did Trust Provider fail the AWS Production cryptographic check, but the check was also unable to match the Trust Provider to an existing match attribute for that Trust Provider (the check was looking for ServiceNameUID with the expected value foo). Now that you know why the failure occurred, you can troubleshoot the issue.

The access.credential event type shows the result of the Edge Controller retrieval attempt of the required credential when requested. If the request was successful, the Edge Controller acquires credentials for the Server Workload via the Credential Provider and the event will specify the result as Retrieved.

The example below shows what you should expect to see in an access.credential event.

{
"meta": {
"clientIP": "1.2.3.4",
"timestamp": "2024-09-14T20:29:11.0689334Z",
"eventType": "access.credential",
"eventId": "5b788a92-accd-49a1-851f-171f7c20d355",
"resourceSetId": "ffffffff-ffff-ffff-ffff-ffffffffffff",
"contextId": "4e876ace-d1b0-4095-ac22-f9c0fb7e676a",
"severity": "Info"
},
"outcome": {
"result": "Authorized",
},
"clientWorkload": {
"id": "7c466803-9dd4-4388-9e45-420c57a0432c",
"name": "Test Client",
"result": "Identified",
},
"serverWorkload": {
"id": "49183921-55ab-4856-a8fc-a032af695e0d",
"name": "Test Server",
"result": "Identified"
},
"accessPolicy": {
"id": "dd987f8c-34fb-43e2-9d43-89d862e6b7ec",
"name": "Test Access Policy",
"result": "Identified"
}
"trustProviders": [{
"id": "49183921-55ab-4856-a8fc-a032af695e0d",
"name": "Kerberos",
"result": "Attested"
}],
"accessConditions": [],
"credentialProvider": {
"id": "bb7927f8-060c-4486-9a5e-bcbe1efc53d6",
"name": "Production PostgreSQL",
"result": "Retrieved",
"maxAge": 60,
}
}

If an credential request fails during the check, a reason property value is returned with the credentialProvider entity notifying you that a failure has occurred, and providing you a reason for the failure. By providing you a reason for the failure, you can then use this information to diagnose and troubleshoot the issue.

There may be several reasons why credential request fails. Some of these reasons may be:

  • Token expired - The requested token has expired.
  • Request failed with BadRequest - There was a communication error with the credential provider. Note: This will include the encountered HTTP status code.
  • Aembit Internal Error - There was an internal Aembit error during the credential retrieval.
  • Unknown error - An unexpected error occurred during credential retrieval and is being investigated by Aembit support.

With this information, you can determine the reason for the failure and then troubleshoot the issue.

Retrieving Access Authorization Event data

Section titled “Retrieving Access Authorization Event data”

To retrieve detailed information about access authorization events, perform the steps described below.

  1. Log into your Aembit Tenant.

  2. Once you are logged in, click on the Reporting link in the left sidebar. You are directed to the Reporting Dashboard page.

Reporting Main Dashboard

You will see two dropdown menus at the top of the page that enable you to filter and sort the results displayed:

  • Timespan - The period of time you would like to have event data displayed.
  • Severity - The level of importance of the event.
  1. Select the period of time you would like to view by clicking on the Timespan dropdown menu. Options are:

    • 1 hour, 3 hours, 6 hours, 12 hours, or 24 hours.
  2. Select the severity level of the results you would like to view by clicking on the Severity dropdown menu. Options are:

    • Error, Warning, Info, or All
  3. Once you have selected your filtering options, the table displays access authorization event information based on these selections.

When you select an access authorization event from the dashboard, you can expand the view to display detailed data for that event. Depending on the event type, different data is displayed. The sections below show example of the type of data that may be displayed with an event.

If you would like to review detailed information about an access authorization event, click on the event. This expands the view for that event, revealing both a summary of the event with quick links to each entity, and detailed JSON output, including event metadata.

Depending on the type of access authorization event, the information presented in the expanded view will be specific to that event type.

For example, if you review an example below shows an event where Trust Provider attestation failed.

Trust Provider attestation failure example

Section titled “Trust Provider attestation failure example”

In the following example, you can see detailed information about an access authorization event that shows a failure because the Trust Provider couldn’t be attested.

Trust Provider Failed Attestation Event

In the left side of the information panel, you see the following information displayed:

  • Timestamp - The time when the event was recorded.
  • Client IP - The client IP address that made the access authorization request. This will typically be a network egress IP from your edge environment.
  • Context ID - ID used to associate the relevant access authorization events together.
  • Event Type - The type of event that was recorded.
  • Client Workload - The identified Client Workload ID.
  • Server Workload - The identified Server Workload ID.

In the right side of the information panel, you see the more granular, detailed information displayed about each of these entities, including:

  • Meta - Metadata associated with the event.
    • Information includes clientIP, timestamp, eventType, contextId, directiveId, and severity.
  • Outcome - The result of the access authorization request.
    • Options are Authorized, Unauthorized, or Error.
  • Client Workload - The Client Workload used in the access authorization request.
    • Detailed information includes id, name, result, and matches. Note that the matches value is optional, and is only rendered if multiple Client Workloads are matched.
  • Server Workload - The Server Workload used in the access authorization request.
    • Detailed information about the Server Workload includes id, name, result, and matches.
    • Note that the matches value is optional, and is only rendered if multiple Server Workloads are matched.
  • Access Policy - The Access Policy used to evaluate the access authorization request.
    • Information includes id, name, result, and matches.
  • Trust Providers - The Trust Providers assigned to the Access Policy at the time of evaluation.
    • Information in the JSON response includes id, name, result, attribute, expectedValue, and actualValue.
    • The reason, attribute, expectedValue and actualValue fields are all optional; however, in the case of Trust Provider attestation failure, you will see the reason field populated.
    • If a reason value is returned, refer to the Authorization Failure section on this page for more information.
  • Access Conditions - The Access Conditions assigned to the Access Policy at the time of evaluation.
    • Information in the JSON response includes id, name, result, attribute, expectedValue, and actualValue.
    • The reason, attribute, expectedValue and actualValue fields will only be returned if there is a failure, and the reason for the failure is ConditionFailed.
  • Credential Provider - The Credential Provider used in the access authorization request.
    • Detailed information includes id, name, result, and maxAge values.

    • If a failure occurs during credential retrieval, then a reason value will also be included.