Way to disable auto rotation of static db roles

[mikebell90]

Is your feature request related to a problem? Please describe.
DB static roles require a rotation period, where automatic rotation is done. We want to disable that and only manually apply per api call. Otherwise there is no good way to orchestrate application container restarts during credential changes.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Change it so you can disable auto rotation

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

The only alternative is implementing events on this and making them synchronous and reliable. That's way too messy

Explain any additional use-cases
If there are any use-cases that would help us understand the use/need/value please share them as they can help us decide on acceptance and prioritization.

We want to have a "god" program orchestrating restarting. We want to have overlapping periods of validity. Easiest way to do this is control the rotation via api. automatic rotation seems honestly useless unless you have limited apps and can afford to write custom code to - detect change, clear connection pools, restart.

Additional context
Add any other context or screenshots about the feature request here.

[cipherboy]

@mikebell90 Do you mind expanding on what your threat model might be?

The issue I have, conceptually, with my understanding of this is, suppose an attacker compromises a credential of this application at time t. With automatic rotation at interval n, if that credential is fresh, the attacker has at most t+n time to use it. If the attacker can maintain persistence, they can continue getting subsequent tokens. But if the attacker only got a point-in-time snapshot (say, token was leaked in a backup or log and only scraped later), they might not be able to use this credential at all, if n has expired. (Which is to say, this isn't about absolute risk and absolute prevention of compromise, just that the incrementally value of this credential becomes lessened). This also has an added benefit that any inadvertent copying of a credential from system A to B is detectable upon expiry, when B's copy is expired and it has no way to get a newer one.

In other words, dynamic passwords give you a guaranteed date of expiry, preventing the need to manually track password ownership & lifecycles in the event of compromise (db roles + lease expiry give you bulk revocation + rotation).

As you mentioned, with dynamic credentials, there's some necessity for the application to be aware of this. My understanding (and it might be wrong) was that few if any databases actively terminate connections on password rotation. Instead, the existing app's connection would remain. If it failed to re-authenticate on startup/reconnect, it could re-read credentials at this point. When the app isn't modifiable, something like OpenBao Agent (with templating capabilities) would let you handle the OpenBao server interaction on behalf of the client, templating passwords into a file and handling SIGHUP if necessary (I believe, via script).

The alternative is, perhaps you don't really want dynamic credentials. And that's fine. K/V is meant for the completely static, manual control use case. Your orchestration program would take on the work to rotate passwords (talking to the DB/...) and place them in K/V with some metadata so it knows who the owner is and that it needs to revoke them later. It can hand them out to instances of your application, and you can control (via control of this orchestrator's code) what you want lifecycles to be like.

My 2c.?

[mikebell90]

1. The issue is we want to control when the rotation occurs. This doesn't allow for exceptions for services like time of day or weekends.
2. "As you mentioned, with dynamic credentials, there's some necessity for the application to be aware of this. My understanding (and it might be wrong) was that few if any databases actively terminate connections on password rotation. Instead, the existing app's connection would remain." - This is true until you add connection pools. And the need rotate those connections or grow or shrink. Now you have the hellish issue of flushing, setting the connections, meanwhile dealing with down time, and in our case writing coe to handle this for 4 different DB types across 4 different stacks.

Auto rotation is useful sure. But you should be able to choose to turn it off and activate rotation according to your own needs.

[cipherboy]

@mikebell90 Hmm... I agree with the premise of this (and thanks for explaining the shortcomings!), but I'm still rather convinced you want some upper bound on the validity period of this secret. Otherwise, things like accidental leakage (logging, ...) coupled with a bad tear down procedure (e.g., some earlier step in decommissioning failed before you revoked the creds and thus they get leaked forever if you don't have really great monitoring & retry logic) mean that an attacker could discover still-valid creds for shared database instances, which wouldn't be ideal...

Have you considered a shorter auto-rotation window (1h-2h) with lease renewal? I'm not quite sure if that will interact the way we'd hope it would (https://openbao.org/docs/commands/lease/renew/ seems to suggest it might?)... And at least reading the API docs https://openbao.org/api-docs/secret/databases/#generate-credentials it isn't clear to me whether static roles use the same generate credentials endpoint as dynamic roles (I must admit, I was originally a crypto guy, so my experience using database backends is a bit lacking)...

But if they do, what I'd be proposing more concretely is that, for the lifetime of the application, it could periodically renew (via agent or otherwise) the lease over this static role, preventing dynamic password rotation (I think we'd need to update the plugin to make this possible, but I don't see why it wouldn't be), but having the nice property that once it expires (or orchestration kicks in and rotates it manually &c), you wouldn't have to worry about the infinitely-valid scenario earlier?

I think, assuming you can trigger lease renewal frequently enough (and here, you could even do something longer than I suggested, like 96h expiry and trigger non-fatal renewal every 12h to give you a less fragile ops platform while still having a better security trade-off than limitless) this should still allow the connection pool properties you wanted (this one password would be static from the PoV of the app while it is running and thus new connections from pools would be fine).

Let me know your thoughts, but to me this sounds like it might be a better security/convenience trade off than either of us were first thinking? :-)

[mikebell90]

That's places a tremendous amount of logic at the application. With 5 stacks we simply can't do that. We also have 7 different persistence systems each with different connection pool types.

So a draining the connection pool option really isn't an option.

[mikebell90]

Plus again - if you have auto renew it assumes something "ran right". If it didn't, vault changes the password, no one knows and apps just start failing.

[mikebell90]

I guess we have a fundamentally different perspective

1. Agree: It's nice to have the OPTION for auto rotate as it closes a security issue
2. Disagree: I feel if a customer wants to OWN rotation conrol they should own it. And Openbao should get out of the way ;)