quoted: " Auditing capabilities. You still cannot tell whether a specific secret has changed and by whom. A structure that allows the provability of the source of a security breach is quite important, especially in environments that need to conform to security standards."
Eh, I'm not sold. While it's possible to make arguments in both directions, it is just as easy to state that letting someone know *WHAT* variables are entered into the file makes it more easy to say "this is the file I want to crack". The other thing is that the encrypted values for each "leaf" are going to be crazy long and you are also encrypting *less* data in each. If you do need the data about what changed, you *STILL* have the history of changes on the file, who made them, and can decrypt each step if you really wanted. The data isn't lost. As an aside, I will correct myself -- the password lookup plugin generates passwords, so it's not really an answer to this problem to make a password plugin using VaultLib. However, it should also be noted that the approach of "leaf node encryption" doesn't work for other reasons -- people will quickly want a file *half* encrypted, see OP's post, which just makes everything get really complicated real quick. I'm open to an ansible.cfg option pull request that might enable a mode like this, but it needs to be off by default. On Fri, Mar 21, 2014 at 2:51 PM, Petros Moisiadis <[email protected]> wrote: > On 03/21/14 17:57, [email protected] wrote: > > > Well, it will work, but this is still a workaround. You still have to >> maintain two files and edit them both for a single addition. Also, it >> becomes more complicated if you have repeated variable names and values. >> > It is a trick, no doubt > But it's simple, pretty straightforward and self documented. > We use it everyday and don't feel any overhead because of it. > > Maybe the fact that you try flattening/namespacing your vars as much as > possible, as you are suggesting in your article, helps you in keeping the > complexity of your vault files in sane levels. This is not going to be the > case with people that prefer to have a more hierarchical representation of > their data (dicts nesting other dicts and lists, with possible repeating > identifiers). > > > Passwords are not edited so often, and in the end not that many. > > >> For example, how much complexity you have to introduce in your separate >> vault file in order to handle a simple variable file like the following ? >> > Of course, you end up duplicating your password entries. > But with a consistent convention it's painless. > > Besides duplication of data entry and the increased difficulty coming with > writing vault-files for data with varying hierarchal representation, there > is also another important feature missing from ansible-vault that your > workaround cannot handle too: Auditing capabilities. You still cannot tell > whether a specific secret has changed and by whom. A structure that allows > the provability of the source of a security breach is quite important, > especially in environments that need to conform to security standards. > > > > > Unfortunately, the Ansible team has not (yet) given an answer on >> whether a command-line option to enable a simple syntax for leaf-node >> encryption mode would be considered for ansible-vault (keeping the current >> whole-file encryption mode as the default mode). There was a feature >> request for this mode and discussion by many people _before_ vault's >> release and it seems it is still desired by people _after_ vault's release. > > > I read the thread at the time, and agreed that leaf encryption was a > better way, > but since we use this, I really don't feel it's that necessary, on a day > to day usage. > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/532C8A3D.6030702%40yahoo.gr<https://groups.google.com/d/msgid/ansible-project/532C8A3D.6030702%40yahoo.gr?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAEVJ8QMmdXfUB5xoRY2h0QvxzM7%2B8HbfBs7tYrnQnk7umGwLLA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
