runtime-tools: log container adjustments.

[klihub]

This PR implements NRI audit logging for OCI Spec adjustments, which has been identified as one of the missing things we need to add (be)for(e) a v1.0. This patch

• adds an extended generator option for runtimes to set an external audit event logger, and
• updates the generator to use the configured logger for audit messages when an OCI Spec is adjusted

Here are updated trees for contained and CRI-O:

• containerd
• cri-o

[klihub]

@mikebrow @samuelkarp PTAL

[mikebrow]

Cool.. Maybe add a little more detail to the short explanation in the README.md maybe links to the containerd/crio use of these opts. (where the integration test happens)

[klihub]

@samuelkarp I have a few questions.

Related to the approach taken here, is this roughly what you had in mind ? Related to event details, how detailed events do we want to log, and do we want to log them unconditionally ? The PR now logs unconditionally and detailed events, except in a few extreme cases where details could get really verbose. But should it be configurable, or should details be logged at a different logging level ? About the logged events/messages. The main messages are now exposed consts, with the idea that someone might want to build some tooling where it can come handy to have them exported. But I don't know if this really makes sense. Any thoughts ?

[chrishenzie]

Thanks for jumping on this, @klihub.

You raised some important questions in your comment that I think we should probably settle on before finalizing the implementation. Since o11y is a key requirement for GA, could we open a GitHub issue to agree on the specific design goals and requirements first?

We can treat this PR as a PoC to inform that discussion, but I'd feel more comfortable if we aligned on the "what" and "why" in a design issue before we iterate further on the "how" here.

[klihub]

could we open a GitHub issue to agree on the specific design goals and requirements first?

I created issue #270 for that.

[klihub]

@mikebrow @samuelkarp @chrishenzie I tried to address/answer the initial round of review comments and took off the draft status.

[klihub]

@chrishenzie Added test cases. PTAL.

PTAL after latest update.

[samuelkarp]

These are all human-readable strings, but I think it'd actually be more valuable to have something that's closer to the actual field adjustment. For example, process.env which matches the JSON path in the OCI bundle. For being the most precise, I think we might want something as expressive as JSON Patch (RFC 6902); this could describe the exact modification that a plugin is making.