-
Notifications
You must be signed in to change notification settings - Fork 240
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs(auditlogs): add audit logging sig proposal
- Loading branch information
Showing
1 changed file
with
109 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,109 @@ | ||
| <!-- structure based on https://github.com/open-telemetry/community/blob/main/project-template.md --> | ||
|
|
||
| # Audit Logging | ||
|
|
||
| ## Background and description | ||
|
|
||
| <!-- Add any background that may be needed to introduce the scope of this project. --> | ||
|
|
||
| Audit logging describes the capability of capturing audit-trail relevant events of a system to meet compliance requirements. Such events may originate from the infrastructure (e.g. a Kubernetes cluster) up to the application-level. It is a capability that is particularly relevant for providers of enterprise software. | ||
|
|
||
| Unlike regular application logs, audit logs are usually subject to long retention periods and software providers must guarantee their completeness (i.e. guarantee of delivery). | ||
|
|
||
| Examples of audit logs include: | ||
| - permission changes (e.g. of a service account or application user) | ||
| - modification of data | ||
| - accessing sensitive information | ||
| - failed login attempts | ||
|
|
||
| ### Current challenges | ||
|
|
||
| <!-- List the current challenges that this project aims to solve. Focus on the problem here, how it affects users and what the downsides are if nothing is done, rather than the solution. --> | ||
|
|
||
| Audit Logging is currently not within the scope of OpenTelemetry | ||
|
|
||
| - no semantic conventions for audit logs in OTEL | ||
| - OTEL APIs/SDKs do not provide feedback to the application level whether data (in particular logs) have been successfully delivered to a remote endpoint. To guarantee delivery, either the SDK has to give those guarantees, or provide feedback to the application so that it can take care of guaranteed delivery itself. | ||
| - OTEL collectors may lose audit logs in transit (i.e. no guarantee of delivery) | ||
|
|
||
| ### Goals, objectives, and requirements | ||
|
|
||
| <!-- Describe the aim of this project, including the goals, objectives and requirements needed to solve the challenges presented in the previous section. Include here the motivations for starting the project now, as opposed to later. Call out the benefits for the OpenTelemetry project when this project is completed. --> | ||
|
|
||
| The goal of this project is to make OTEL fit for audit logging purposes that meet compliance requirements of enterprise software providers, in particular: | ||
|
|
||
| - REQ-CON-01: Semantic conventions for application-level audit logs are defined | ||
| - REQ-CON-02: Semantic conventions for infrastructure-level audit logs are defined | ||
| - REQ-SRC-01: Guaranteed delivery of audit logs exported via OpenTelemetry SDK. | ||
| - REQ-PIP-01: OTEL collector must provide guaranteed delivery of audit logs, including when its process is interrupted | ||
|
|
||
| ## Deliverables | ||
|
|
||
| <!-- A description of what this project is planning to deliver, or is in the process of delivering. This includes all OTEPs and their associated prototypes. --> | ||
|
|
||
| <!-- In general, OTEPs are not accepted unless they come with working prototypes available to review in at least two languages. Please discuss these requirements with a TC member before submitting an OTEP. --> | ||
|
|
||
| - semantic convention for audit logs | ||
| - extend OTEL APIs/SDKs for audit logging purposes (in collaboration with the respective SIG) | ||
| - extend OTEL collector for audit logging purposes (in collaboration with the respective SIG) | ||
|
|
||
| ## Staffing / Help Wanted | ||
|
|
||
| <!-- Who is currently planning to work on the project? If a project requires specialized domain expertise, please list it here. If a project is missing a critical mass of people in order to begin work, please clarify. --> | ||
|
|
||
| The following vendors are interested in improving this area: | ||
| - SAP | ||
|
|
||
| Other vendors are invited to join the discussion. | ||
|
|
||
| ### Required staffing | ||
|
|
||
| <!-- Projects cannot be started until the following participants have been identified: --> | ||
| <!-- * Every project needs a project lead, who is willing to bottom line the project and address any issues which are not handled by other project members. --> | ||
| <!-- * At least two sponsoring TC or GC members. Sponsors are dedicated to attending meetings, reviewing proposals, and in general being aware of the state of the project and its technical details. Sponsors guide the project through the spec process, keep the tracking issue up to date, and help to ensure that relevant community members provide input at the appropriate times. --> | ||
| <!-- * A GC liaison to facilitate this SIG's health and ensure project scope remains true to the project description. If a GC member is also a sponsor for this project, they are by default the GC liaison (see [GC check-ins](https://github.com/open-telemetry/community/blob/main/gc-check-ins.md)). --> | ||
| <!-- * Engineers willing to write prototypes in at least two languages (if relevant to project). Languages should be fairly different from each other (for example: Java and Python). --> | ||
| <!-- * Maintainers or approvers from those languages committed to reviewing the prototypes. --> | ||
|
|
||
| * Project lead: SAP (name tbd) | ||
| * Sponsors: tbd | ||
| * GC liaison: tbd | ||
| * Engineers: | ||
| * SAP will provide a prototype in two languages (tbd; likely two of Java, JavaScript, Go) | ||
| * Maintainers/approvers: tbd | ||
|
|
||
| ## Timeline | ||
|
|
||
| <!-- What is the expected timeline the project will aim to adhere to, and what resources and deliverables will be needed for each portion of the timeline? If the project has not been started, please describe this timeline in relative terms (one month in, two weeks later, etc). If a project has started, please include actual dates. --> | ||
|
|
||
| TBD based on community involvement. | ||
|
|
||
| ## Labels | ||
|
|
||
| <!-- Issues should be properly labeled to indicate what parts of the specification it is focused on. List here the labels applicable to this project. --> | ||
|
|
||
| - audit-logging (tbc) | ||
|
|
||
| ## Project Board | ||
|
|
||
| <!-- Once approved, a project should be managed using a GitHub project board (see [open projects](https://github.com/orgs/open-telemetry/projects?query=is%3Aopen)). This project board should be pre-populated with issues that cover all known deliverables, organized by timeline milestones. --> | ||
|
|
||
| <!-- Any [member](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md) associated with the project can create the board. Once created, the creator of the board should: --> | ||
|
|
||
| <!-- - Assign `Admin` privileges on the project to the relevant project members (using a new or existing GitHub team). --> | ||
| <!-- - Change the visibility of the project to `Public` in order to share project status and priorities outside of the OpenTelemetry organization. --> | ||
| <!-- - Configure project workflows to automatically add issues and PRs to the board based on repositories and labels. --> | ||
|
|
||
| <!-- Once created, please add a link to the project board here. --> | ||
|
|
||
| TODO: add link | ||
|
|
||
| ## SIG Meetings and Other Info | ||
|
|
||
| <!-- Once a project is started, its corresponding SIG should meet regularly for discussion. These meeting times should be posted on the [OpenTelemetry public calendar](https://github.com/open-telemetry/community#calendar) and automatically recorded. --> | ||
|
|
||
| <!-- Any relevant information related to the SIG (e.g. sponsors, meeting times, Slack channels, meeting notes, etc.) must be publicly available in the [community](https://github.com/open-telemetry/community) SIG tables, which can be updated via the [sigs.yml](https://github.com/open-telemetry/community/blob/main/sigs.yml) file and running `make table-generation`. --> | ||
|
|
||
| <!-- See [How to create and configure meetings](https://github.com/open-telemetry/community/blob/main/docs/how-to-handle-public-calendar.md) for updating the public calendar or open an issue in the community repository so it's taken care of. --> | ||
|
|
||
| TODO: add information |