addusers Kaizen OpenStack creds visible in config file

[ianballou]

The password for Kaizen user addusers is visible in a configuration file in the moc private repo. It would be a better practice to keep a dummy password there and store the real one on the VM(s) that are running the software.

[jeremyfreudberg]

it's in a lot more places than just there... but yeah accepting "private repo" as an adequate solution was supposed to be temporary.

[ianballou]

I'll probably end up working on getting this set first, it's one of a few issues that came up from the meeting last night with @kamfonik

[greyspectrum]

I would like to see this change, as well. The settings.ini does need to be backed up somewhere, otherwise rebuilding the moc-openstack-tools vm in a timely way becomes a headache.

This is a tool I recently became aware of, but haven't yet played with, that purports to address this problem:

https://www.hashicorp.com/blog/Vault-announcement/

Here's a general overview:

https://www.vaultproject.io/intro/index.html

Source:

https://github.com/hashicorp/vault

[ianballou]

Which part of the process would become more difficult? Are there many places that need the Kaizen password to be inserted?

[greyspectrum]

@Izhmash Whenever moc-openstack-tools talks to Keystone, it needs the addusers password. The advantage to using Vault would be twofold: we could remove the addusers password from the private Github repo and we could remove it from the moc-openstack-tools VM, as well.

Instead, moc-openstack-tools could query Vault, either with vault read or the Vault API, fetch the addusers password, and use it to authenticate to Keystone, all without storing that password on disk. That's my understanding of how Vault would work. The same thing could be done for the Google API key that moc-openstack-tools uses, as well.

Using Vault just to manage secrets for moc-openstack-tools is probably overkill, but it would be an interesting place to experiment with using it, in case it turns out to be a useful way to manage secrets, like API keys, for other systems.

[ianballou]

For this particular password, Laura mentioned to me that having a separate gitignore'd config file saved locally on the machine with the password could be a solution. I would just need to create a 2nd ConfigParser object to read in the password. It would also need to be made known that the password is there for those who need it so it isn't forgotten.

This solution would be a more secure workaround for now, but having a credential service in the future would probably be very helpful, especially since so many OpenStack services are being communicated with.

Edit: just noticed that the engage1 credentials are out in the open too, those should probably be hidden as well.

[greyspectrum]

I'm not sure I understand how adding another config file to the .gitignore would help. The settings.ini is already in the .gitignore, so adding another credential file and keeping it on the production VM wouldn't solve the problem of securely backing up those credentials, in case something happens to that VM.

Maybe you're saying something else, though?

[ianballou]

I see, so the local configuration on the VM is already saved locally on the machine. In that case we don't need the second config, just need to make sure that the current one is kept up-to-date.

I'm not sure what our usual path of action is for backing up passwords, but I thought that the password(s) would be something known and kept only by those who need to know it. I just talked to Rado and he wishes to make sure that the passwords visible in the moc private repo are made invalid as soon as possible.

Perhaps we could change it now and later implement some sort of backup utility like Vault?

[greyspectrum]

I see, so the local configuration on the VM is already saved locally on the machine.

Yup, that's right. In this case, the password & Google API key can't stay in a human or humans' head, since the scripts use it to authenticate to Keystone and Google, respectively, any time a user needs to be added or a quota needs to be changed, for example.

So, if we took the credentials off of the VM, then it would break the automation. Having a human enter those credentials from memory would also be sub-optimal, since that's the sort of toil the scripts were designed to eliminate.

Vault would be a potential solution, since the credentials could be kept off of the helpdesk VM's disk (they would of course be in the helpdesk VM's memory when called from Vault in order to authenticate to Keystone or Google, but that's a necessity unless we get into storing secrets on hardware tokens, which I don't think would work on a virtualized machine in any case).

Vault itself would have to be backed up, but after that, things look pretty good. Any secrets (API keys, passwords, etc) that any automated service requires can be called with the Vault API, so that those secrets aren't distributed among many machines.

In the short term, one solution to the backup-creds-living-on-Github problem (that doesn't involve Vault) would just be to encrypt the settings.ini file with GPG and push it to the same private repo. The private key that was used would have to be distributed to a few key people. Alternately, if GPG is used in symmetric mode, then the corresponding password would have to be similarly distributed among those who might need access.

Just deleting the settings.ini from that Github private repo seems a bit risky, since if the settings.ini on the helpdesk VM were lost or erroneously edited, then it's a bit of a headache to reconstruct it, which would potentially increase downtime if that were to become necessary.

[kamfonik]

My suggestion to Ian was that as a short term solution, the password could be removed from settings.ini and placed in a different config file, so you could continue to back up settings.ini in the private repo - since that file can otherwise take time to recreate if lost. The other file would contain just the user/password combo.

[greyspectrum]

Oh OK, I see. Yeah, that makes sense.