Find a solution for managing (and storing) opera secrets

[anzoman]

Description

Orchestration process often includes sensitive data that should be protected and shouldn't be available to everyone. Especially, orchestration inputs can be very important for the orchestration process as they often include various secrets and variables (e.g. cloud provider credentials, ssh keys, etc.) that are used to authenticate and to deploy applications.

Right now opera copies all TOSCA properties and attributes to its storage file (usually .opera), it also copies all the inputs as a plain text JSON file and if you deploy a CSAR, its copy is also stored in .opera/csars/csar. So, there is a room for improvement and we can find a better way of storing secret data. This can be designed as a new part of opera, or additional plugin or feature that users can download/activate when they want.

Steps

To manage and store secrets several solutions can be used instead of implementing our own one, like Ansible Vault, HashiCorp Vault, secretstorage, CyberArk, Docker secrets, python-secrets and so on.

These tools can all bring additional security and may require extending xOpera.

Current behaviour

Right now opera's secrets defined within TOSCA are stored in opera storage file and can be revealed to anyone.

Expected results

To establish better management (and storage) for secrets.

[alexmaslenn]

@anzoman I've been thinking about this issue for some time. One of the solutions I've implemented is to make an encrypted storage for .opera
https://github.com/SODALITE-EU/platform-discovery-service/blob/master/src/pds/api/storages/safe_storage.py

We also need to address not only the safety of data at rest but also data in use. xOpera dumps all playbook inputs in a tmp file that is also can be considered unsafe. I was thinking about adding Ansible Vault support to xOpera

[anzoman]

@alexmaslenn encrypted opera storage folder (.opera) seems cool. And for inputs it would be welcome if opera wouldn't copy them to storage folder at all, but just use them during runtime. I think that we have mentioned Ansible Vault a few times and it should probably go to xOpera SaaS.

@cankarm, @dradX and @sstanovnik - what do you think about all this?

[cankarm]

It's better if things are encrypted at rest and also if we take extra care of our key for encryption/decryption. Could be a part of xOpera directly or there could be a switch to disable encryption.

Inputs are copied, afaik, to be sure that we have a snapshot of the deployed version. Note that the user (if not using SaaS) can easily change something in inputs later without making a "deploy" and things become inconsistent.

[alexmaslenn]

@anzoman as fa as I understand supporting Ansible Vault would still require implementation in xOpera directly, as current xOpera - Ansible interoperation would not allow encrypted inputs. And additionally we should get rid of writing any sensible data to filesystem to improve overall security. I'll make a separate issue for that.

[sstanovnik]

As this concerns security, we'd need to make a threat model and decide what attack vectors we want to prevent. I don't think blindly implementing features we think improve security will do anyone any good, especially with no way to audit whether we'd actually improve anything.

[dradX]

@sstanovnik, @anzoman, @alexmaslenn I agree with having the possibility to audit security would be a very good path. However regardless of threat model analysis, we may choose, the case is that sensitive data should be protected at the source of creation and since opera takes sensitive data as input and then consumes and stores this data (state) into .opera as output and in other places, as @alexmaslenn explained before, we should enable the user to protect this (state) data with encryption at creation, rest and in use (in case of undeploy or any operation subsequent to deploy). Since we are talking about security attack vectors or security risks, I believe this goes under Sensitive data exposure e.g. number three in the OWASP top ten list.