For this work, let's fork off Jianrong's dbaas branch of the Atlas operator and contribute there. This is what's feeding the current operator on cluster - this way, once you're done, he can own the deployment part of the effort.

What
Programmatically create a new Database user that we can use for binding to Atlas instances.

Why
The Atlas API allows us to fetch a list of database users associated with a project, but we have no way of fetching their password If we provision our own user, we've got the credentials we need.

How

• note that we already have a client connection available that's using the api public/private key pair we supply, so this can just integrate with existing workflow within discoverServices() call (last line of previous link)
• the new db user would need read/write access to all projects within the organization so that it works regardless of which instance we pick to import
• Store the password in a secret on our cluster:
  • I think Atlas does this when provisioning a new user via operator already, but I'm really not sure, I just know that I've seen one around from initial efforts setting up our lab. I could definitely be wrong and we need to create it instead.
• Add the secret name to the AtlasProjectService status:
  • after "service discovery", the AtlasProjectService status already gets a list of fetched DB usernames, so change that to a key/val pair and add the secret name there or add some new entry to the AtlasProjectService status struct just for our own special username/password combo instead, your call

That should be it... I'll consume it off the AtlasService status back inside the dbaas-operator and use the new secret instead of a currently hard-coded one I'm using right now.