MySQL secret backend and real use case

[Alex Soto]

Hello I am wondering how to use MySQL secret backend with for example a Java pool of connections. I really like the idea of having this temporal users and passwords for your application so you don't need to hard coded in your code or configuration files.

But I was wondering next question, you can create using this backend a user and password with "expiration" time, so after X hours, the user and password is no longer available inside the system.

But for what I see this will have some deep implications which I am not sure it is easy to fix. 

Let me show the example. I have a Java application with a pool of connections. When the application starts, it authenticates with the credentials provided by Vault, and then it can start doing queries to database. 

After an amount of time, the user and password are dropped from database. The problem is that authentication is not produced anymore since the pool of connections is already created. 

So we can do several things, the first one is flushing the pool, but this means one problem, what's happen with current connections? You can block the queue until everything is finished and then flush it, but if you have several incomings per second this may be a big problem.

Of course another option could be make the user and password not expired, you are better than hardcoding passwords but of course you are not taking the full power of Vault.

Any other idea?

[Jeff Mitchell]

A common usage pattern is to either renew the credentials (for
supporting backends), extending their lifetime, or to request new
credentials well in advance. So if your credentials have a lifetime of
three days, and you request new credentials six hours before they are
set to expire, for most use cases this will be plenty of time to
finish any outstanding queries.

Of course, this depends a lot on the behavior of your connection pool;
if it drops idle connections after a credential change, then you
should be fine, as new requests for connections will use the new
credentials. If it never drops connections until flushed, you will
still have a problem.

--Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/bbdafaab-057b-421e-832b-e817fa2f32ce%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Alex Soto]

Yes this is the case, ok then I am at connection pool hands :). It is a problem since I will need to flush manually the pool which I don't like so much because there can be a lot of side effects that I don't want to deal with. 

Well thank you so much for confirming what I was thinking.

Alex.

El dilluns, 20 juliol de 2015 16:38:07 UTC+2, Jeff Mitchell va escriure:

[David Carr]

In my opinion, the biggest problem here is that most Java JDBC connection pools were not designed with the use case of "database credentials change at runtime" in mind.  Instead, they often assume that the credentials are immutable for the lifetime of the connection pool instance.

With HikariCP, there doesn't appear to be an out-of-the box way to tell it "here are new credentials" that it will honor.  You can set the username and password properties, but it caches a "pool" field that's specific to a particular username/password combination.  If you use reflection to set the "pool" field to null, it will then use new credentials.

With BoneCP, if you change the username and password properties on the config, it will use them for new connections, but there doesn't appear to be a way to tell it to stop using the connections from the "old" credentials when they are idle.  The "terminateAllConnections" method on the (protected) connectionStrategy isn't the right approach, as that appears to also kill active connections.

That being said, it doesn't look like it would be a huge amount of work to improve handling of this scenario.