search

studentenportal / deploy-new

🚜 New deployment setup (Docker based)
1 stars 0 forks source link

Ansible-Vault #21

Open mattbaumann opened 6 years ago

mattbaumann commented 6 years ago

We used to have an ansible-vault file with the secret variables.

Steps:

  1. Generate ansible-vault file
  2. Add to GPG keyring
fabianhauser commented 6 years ago

I just stumbled over the pass plugin, which is integrated into ansible from version 2.3

It would be nice if we could use that, so that we don't have to use two separate secret stores.

mattbaumann commented 6 years ago

I just stumbled over the pass plugin, which is integrated into ansible from version 2.3

It would be nice if we could use that, so that we don't have to use two separate secret stores.

We can do so.

Remember, this means that the tool stack rises and another tool is mandatory for deployment. Ansible Vault is a very user-frendly solution, because it does not mandate following:

  1. GPG Key
  2. The script PASS installed
  3. Key-Management for allowing certain keys to decrypt passwords

And there are a lot more troubles. For a professional team this would be a very good choice. Especially, because it is very hard to crack. But remember, the project has to be deployable by noobs. As a dummy, I would not have a lot of nerve to setup GPG before seeing something happening.

Therefore, I would still recommend Ansible Vault. I would also recommend to integrate all keys currently held by GPG into Vault. What's your take?

Matt

fabianhauser commented 6 years ago

I see your point @mattbaumann, but still prefer the pass Password Store. The main reason is that we have some passwords that are not part of the deployment (but used by humans) and the (in my opinion) easier key management and tooling.

Still, we should first check if a variable is set (we can use that with the local vagrant deployment) and only do a lookup as second step. That should be as easy as:

{{ super_secret_key | default(lookup('passwordstore', 'super/secret/key')) }}`
mattbaumann commented 6 years ago

Sure, therefore I will implement it with PASS.

{{ super_secret_key | default(lookup('passwordstore', 'super/secret/key')) }}`

Do you propose to have a dual solution:

local builds production builds
Vault + Vagrant PASS + GPG

Local Builds use Ansible-Vault as Key-Management for simplicity reasons and fast and simple deployment for the application programmers. I would recommend to set a default password like, studentenportal and make it public with the recommendation to change it immediately after cloning of the repository.

Production Builds use Ansible with the PASS Module to access a GPG-Key-Store with the production passwords saved inside. Therefore the production is very secure. So far so good.

Questions

  1. Do we include the GPG-Key-Folder encrypted inside this repository?
  2. How do we switch between the password managers? => Default Ansible-Vault, when Host is Production set Host Variable and switch to PASS with your statement above
  3. We should also have a discussion which information is security-relevant to hide?
    1. I recommend to hold same information in both stores and sync the variable-names
    2. All classified information must be inside of stores and not publicly visible
    3. The concept resembles public-key-encryption: The method how to deploy is publicly visible in the repository, but the key to do so is locked away in GPG-store.

Your Work

My Work

fabianhauser commented 6 years ago

Local Builds

I'd suggest to just store unencrypted variables (not even in a Vault), as these are public either way.

Do we include the GPG-Key-Folder encrypted inside this repository?

No, we should keep them separate in a private GitHub-Repo (it already exists, it's called pass 😉).

How do we switch between the password managers?

We can set the variables for the vagrant host, but not for other machines and use pass as fallback like described above.

We should also have a discussion which information is security-relevant to hide?

Personally, I think it is sufficient to hide (long generated) passwords, as other things as db-names are usually easy to guess ("studentenportal" 😉) and are more obscurity than security.

Btw. If you are interested in a secure GPG-Key setup based on Yubikeys, I started to write a documentation some time ago.

mattbaumann commented 6 years ago

I got it. May I have access to the repository? I need to see the whole picture in order to understand the problem. Plus I would like to use it for testing.

Greetings and good exams next week Matt