On 2025-06-28 18:06:51 +0200, raphi wrote: > Am 28.06.2025 um 15:59 schrieb Peter J. Holzer: > > On 2025-06-27 19:00:36 +0200, raphi wrote: > > > > > It's the application's password that we want to ensure that it is > > > complex and gets changed after we set an initial password for it. > > Why let a human change that at all? Couldn't you just create a suitable > > random password at deployment time? (And then automatically every n > > months if you want to rotate it.) > > > Because someone has to configure the password in the application, mostly > within WLS or Tomcat
Yeah, my aim would be to eliminate that "somebody" and automate it with
an ansible playbook (or whatever).
> and that's definitely not something that we DBA want to touch, that's
> the devs job. Which means we would have to provide some mechanism for
> the application to grab the password, say from a file or something,
> which has it's own pitfalls. Not to mention that we DBA usually don't
> want to know any application passwords.
If it's automated the DBA wouldn't know the password. The playbook would
generate a random password, create the user in the database and create
an XML file for Tomcat[1] with the connection details (including the
password). It seems to me that this would be a relatively simple change
to your existing "database self service" mechanism.
> The only feasable way to implement this is with hashicorp Vault or
> something similar, then no one knows the password, neither DBA nor Dev
> and it would be guaranteed that it's complex.
That's another possibility. Might be a bit more complex, but I've never
used it so I don't really know.
hjp
[1] There are probably different methods, but wherever I see Java, I
also see XML ;-)
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
