Automatic enabling of an audit device after usealing

[michal-wrobel-telekom]

Hi community,

according to my understanding there is no way to automatically enable an audit device. I think however that such functionality could be very useful for tracking the very first requests to OpenBao. Do you also see that as a desirable feature? Or maybe there is a way for doing it that I'm not aware of 🤔

[cipherboy]

Hey @michal-wrobel-telekom -- this probably relates to #944... Though I could see an argument how audit devices are much more special than secret engines and how they should be configured separately in the config file...

The issue is, placing it in the config file still doesn't allow it to be audited as we will not have a durable HMAC key material storage location (which is why it is currently request based, post-unseal).

I think the question thus is design. Got thoughts for this?

[michal-wrobel-telekom]

I could try to implement some sort of a mechanism which (if desired) would run directly after unsealing - either automatic or manual - to enable an audit device. I would appreciate a hint where to start tho, because I don't have an complete overview over the project yet 🤷‍♂️

[cipherboy]

@michal-wrobel-telekom How are you initializing, btw? If you're using the bao operator init CLI, I wonder if we could add a form of it which behaves like a combined operator init+audit enable form and that'd be the simplest way to do this.

If you're using automation of some sort, that'd be a much different conversation involving internals that might be harder for a newcomer.

[michal-wrobel-telekom]

As for now we're indeed using bao operator init but in the future we're planning to use one openbao instance to automatically unseal another.