Brane Log

[DanielVoogsgerd]

While working on CI, MSRV in particular, I'm running into an issue with Brane log.

For MSRV I'm running a script along the lines of find . name Cargo.toml -exec .... However, this is failing now because of Brane-Log. What is the current state of Brane log? Should we keep this around, or can we move this over to a separate branch until it's done, for example?

I could also make my tooling more robust, and ideally I would like to, but I cannot really afford to spend more time on CI right now.

[DanielVoogsgerd]

I worked around the issue in this case, but I'm still curious on the state of log and whether we should move this to a long lived branch while we are not using it. The less is in the main tree, the better if you ask me.

[Lut99]

The only reason I kept it around all these years is a stinging reminder that Brane desperately needs a form of audit logs akin to what the policy-reasoner itself has. Just something that forms as a trusted service per node that collects important events that are relevant to checking policy (although, maybe slightly less necessary with the current policy scheme? Idk, at the very least, warrants thinking about).

So... yeah no worries removing it if we just create an issue or TODO somewhere xD

[DanielVoogsgerd]

Now that we are moving to tracing. Do you think that would suffice, maybe with some annotation on the tags that those are relevant with respect to the audit log, or do we need some out of band mechanism that is purely dedicated to audit logging?

[Lut99]

Well, I think that it may prove important that, eventually, the audit trail may be of different sensitivity / importance than the rest; i.e., we may want to store it differently and/or send the logs somewhere else than the main host of logs.

If that's possible within tracing, then just tagging is enough :) but otherwise, maybe, may be better to keep them split.

[DanielVoogsgerd]

That is tough, I think it might differ whether we could and whether we should.

Tracing is basically a fancy set of event triggers, that enter some chain of different actions registered in the various layers of tracing subscriber. We could add some metadata when emitting them, and filtering them out in one set of layers while keeping them in another.

The main downside might be that it would be easy to mistake the two different APIs in our usage. On the other hand, if something like spans is useful, I would 100% recommend using with maybe an extra endpoint that fixes the annotation issues, as implementing that is nasty, and we are not going to do it better than the Tokio team itself.

[Lut99]

I agree. But due to its sensitive nature, maybe audit traces require special care while writing or something, and this should be as transparent as possible. But that's probably also thought a little too strictly 😂 I think for now using spans would be an excellent idea.