You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

tailed

Issue / No IssueField NameDescriptionEELF FieldLog Spec FieldReference
Best Practice Proposal for Jakarta: Existing Fields Recommended

Timestamp

The container and container application MUST log the field “date/time” in the security audit logs. 

The value should be represented in UTC and formatted per ISO 8601, such as “2015-06-03T13:21:58+00:00”. The time should be shown with the maximum resolution available to the logging component (e.g., milliseconds, microseconds) by including the appropriate number of decimal digits. For example, when millisecond precision is available, the date-time value would be presented as, as “2015-06-03T13:21:58.340+00:00”.

BeginTimestamp

Timestamp

LogTimeStamp

R-97445

v1.3 Spec


Log Type Name

The container and container application MUST log the field "Log type" in security audit logs.

This field will adhere to the following ENUM ::= "AUDIT" | "METRICS" | "ERROR" | "DEBUG" | "SECURITY"

This is here for legacy purposes.  Older projects used to generate 4 separate log files. 

*This is a proposed field that came out from discussion with 2 PTLs on 9/17/2021.  This is meant to be a filter to distinguish from other types of logs that other projects are currently generating.

2/4/22 Proposed Changes

  • Changed this from MUST to MAY
  • Also the value "Security" from the  ENUM was removed
  • This has been clarified as a Legacy Field
N/A

p_marker

(4)

Log Level

The container and container application MUST use an appropriately configured logging level that can be changed dynamically.

The intention of this field is to not cause performance degradation via excessive logging. 

This field will adhere to the following ENUM ::= "FATAL" | "ERROR" | "WARN" | "INFO" | "DEBUG" | "TRACE"

The verbosity of the logging increases from left to right.

Category Log LevelLevel

R-28168

(4)


Transaction ID

The container and container application MUST log Transaction ID

A transaction ID is a universally unique value that identifies a single transaction request within the ONAP platform. Its value is conformant to RFC4122 UUID. This value is readily and easily obtained in most programming environments. 

Proposed Changes

The name of the field can lead to confusion as the term transaction may have different meanings.

Provide more explanation.  

Trace ID may be a better term.

Use the term that is in the referenced RFC.

Request IDTransaction ID

v1.3 Spec

(4)


Status Code

The container and container application MUST log a "status code" in the security audit logs. 

This field indicates the high level status for transactional or sub operational events.  

This field will adhere to the following ENUM ::= "COMPLETE" | "ERROR" | "INPROGRESS"

  • COMPLETE when the request is successful
  • ERROR when there is a failure
  • INPROGRESS for states between the COMPLETE and ERROR.

Proposed Changes

  • This field is use case dependent, specifically for API like calls.
  • There are many times you would log items that are just for internal based events and this fields does not apply
Status CodeStatus Code

R-15325

v1.3 Spec

(4)


Severity

The container and container application MUST log the severity level of a processing event.  

This is to be used for error reporting in internal processing in conjunction with the status code field. 

This field will adhere to the following ENUM ::= "NONE" | "WARN" | "ERROR" | "FATAL" 

SeveritySeverity(4)

Principal ID

The container and container application MUST log the Principal identity of a requestor in the security audit logs. 

This field should contain the identification of the entity (user agent, client id, user, user id, login ID, non-person entity (NPE), Token,  etc.)  that made the request of the service or API indicated in the Service/Program Name field. For a serving API that is authenticating the request, this should be the authenticated username or equivalent.

N/AUser

R-89474

 R-89474

v1.3 Spec


Service / Program Name

The container and container application MUST log the field “service or program used for access” in the security audit logs.

This intention is to capture the service name endpoint or an externally advertised API invoked, e.g., where are you connecting to. This is represented as a URI or URL. 

ServiceNameServiceName

R-06413

v1.3 Spec


(4)


Log MessageThe free text payload of a log event. 

detailMessage

p_message
Develop POC and propose as a Best Practice for K Release: New Fields Recommendations

Container Image Name / Tag

The container and container application MUST log the Container Image Name/Tag.

The image name/tag is as returned by the docker images command.

NOTE:  Images are not required to have tags

N/AN/A

Container Image Digest

The container and container application MUST log the container image digest.

The digest is a cryptographic digest as returned by the docker images --digests command.


N/AN/AT1036, T1525

Container ID

The container and container application MUST log the container ID.

The container ID is the same that is returned by the docker ps -q command.

NOTE: The container ID is unique for life time of the the container instance. Once the container is killed, this ID goes away.

N/AN/A

Role / Attribute ID

The container and container application MUST log the Role or Attribute ID of the Principal identity of the entity accessing the requested service or API.

Note: The group ID is in reference to a Role or Attribute as part of a RBAC or ABAC scheme.

N/AN/A

Protocol

The container and container application MUST log the field “protocol” in the security audit logs.

This refers to the communication mechanism for a request.  The value of this field should be representative of the OSI application layer  protocol. This is represented as a decimal formatted TCP/IP port number.

N/AN/A

R-25547


Results from comparison of existing logging

  • No labels