Why I'll never provision another database user

http://borgified.github.io/strongdm/2017/06/20/user-account-creation.html

by sbrown12 • 9 years ago

20 11 9 years ago

borgified.github.io

zie3• 9 years ago

or use an OSS solution: https://www.vaultproject.io/docs/secrets/databases/index.htm... and it conveniently does a lot more than just DB auth.

jldugger• 9 years ago

Or LDAP?

https://dev.mysql.com/doc/refman/5.5/en/pam-pluggable-authen...

zie3• 9 years ago

True, a valid option for MySQL. Not every database handles LDAP, and Vault gives you dynamically created credentials to your DB, so the accounts are created and deleted AS NEEDED.

idrism• 9 years ago

strongDM looks like an alternative to Vault for this one use case. Does anyone have any idea what strongDM's pricing is like?

gerdesj• 9 years ago

I can't help but notice that the script link to GitHub (seriously?) in the OP topic contains something involving NRPE and NSCLIENT++ - that's part of a bloody monitoring system.

There are APIs, connectors and the good $DEITY knows what in so many languages it isn't funny anymore that you decide to re-purpose a monitoring agent to delete an account? I'm no programmer but even I could whip up a link between MySQL/MariaDB and say AD with PHP, Python or Perl

Actually the more I bother clicking on the links in the GH repo and idly browsing the more I wonder what is going on.

Soz: What's Vault?

zie3• 9 years ago

https://www.vaultproject.io

It's like a one-stop shop for most your security needs. They label it as "A Tool for Managing Secrets" which it does, but it does a lot more than that too. One of the things it does (and what applies here) is dynamically create DB accounts AS NEEDED with random usernames and passwords, which auto-expire and are deleted as soon as they are not needed anymore. which is more than strongDM seems to do.

kelnos• 9 years ago

Others embraced it quickly, recognizing the simplicity of being able to connect to localhost:3306 and have instant access to production data.

Well that seems like a huge production outage just waiting to happen.

sbierwagen• 9 years ago

Submission title doesn't seem to have anything to do with the content? The post is mostly about semiautomated user account management, from the title I was expecting some kind of postmortem where provisioning a database user caused some kind of disaster.

welder• 9 years ago

How's this different from https://www.onelogin.com/?

deepsun2• 9 years ago

Or, if you use Google Apps (aka G Suite now), use Google Identity-Aware Proxy [1]

Basically, all it does is adding couple of headers, like user-id, to every single HTTP request. And as soon as you delete user's account in your Google Apps console -- they will lose access to your corporate services.

Drawbacks are:

1. This require cooperation from the services. E.g. you have Jenkins -- it needs to check those headers. I don't know if Jenkins has a plugin for that yet.

2. The service must run on GCP, so Google can proxy requests to it.

[1] https://cloud.google.com/iap/

deepsun2• 9 years ago

Correction: the accounts for the proxy are managed in GCP IAM, not in Google Apps.

Why I'll never provision another database user

Related Stories