Hi. I recently submitted https://github.com/ansible/ansible/issues/10253, but it was closed. I commented before I read the part about comments on closed issues not being monitored, so I’m going to duplicate my thoughts here to discuss.
I don't have a direct answer about whether it should be configurable
or not -- I lean towards no but without a use case to think about it
in context I don't know if there is a valid reason for configurability
that I'm missing. As for ansible specifying the mode, ssh could seen
as a precedent here -- ssh demands that you set file permissions of
private keys and .ssh directory in certain specific ways otherwise it
will not use the data. group is also covered by this.
Right now, when you use vault to encrypt a file, conceptually you are
importing the data into a secure data store. So details of how that
data is protected and represented internally is not really the end
user's concern. The end user's responsible for putting the correct
data into vault and using it via variable names. Ansible is
responsible for keeping that data secure when it isn't being accessed.
Restrictive file permissions are one layer that can help with this
(although the encryption itself is certainly the main protection vault
has).
I think it would be good for encrypt to change the permissions as
well. It's not as essential as for edit because ansible is taking a
user created file and encrypting it. So once ansible starts
manipulating it the data is no longer readable because of the
encryption. When you run ansible-edit, ansible creates a temporary
file for you to edit. this temporary file is in clear text so file
permissions are the only thing protecting the data.
Could ansible edit save off the file permissions before it decrypts to
a temp file and then restore the file permissions on the re-encrypted
data afterwards? that's probably doable but since we generally think
of the encrypted file as just a storage format for the secret data
that it contains, I think it's better to consider the file created by
ansible encrypt not setting the more restirctive permissions to be the
bug.
It would be helpful if you could state your usecase that's being
impacted by the way vault works. Right now, I can tell you how vault
works and how it aligns with vault conceptually. And you can tell us
that the concepts conflict with how you wish you could use vault but
without knowing what it is you are trying to accomplish I can't tell
if vault needs to change conceptually or if there's a more-ansible-ish
method of accomplishing your goals.
-Toshio
IMHO, it's reasonable that Ansible wants to enforce sane file
permissions for the vault file. I think we can argue if Ansible should
refuse to run if the permissions aren't sane (like SSH) or if it should
always enforce them regardless. I'd vote for both 
Submitted PR#10260 to make behavior consistent across operations (i.e.
umask 077). Tested on Fedora/CentOS only.
Giovanni
One thing about SSH keys is that they're generally unique to one person
(or one account anyway). I feel like there's a not-uncommon use case for
wanting your sysadmins (in a Unix group 'sysadmin', say) to be able to
access Ansible vault files as themselves (i.e. without sudo), which would
be easy if files were group 'sysadmin' and group-writable.
I think it'd be fine for Ansible to warn about and/or refuse to run in
this way, by default, but I think it should be an option to allow it.
-Josh (jbs@care.com)
This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.
I would agree that such a use case is certainly foreseeable.
In my mind, vault is responsible for encrypting data within my file, but
isn't responsible for determining a sensible mode or owner for said file.
Also, if I commit a file with mode 0600 into version control, and someone
else checks out the same file, there is no telling what mode it will end up
as in their working tree. So enforcing a mode seems kind of pointless for
many workflows.
Thinking a bit more about this with the aim of finding a compromise, I
wondered if perhaps we could have a setting telling ansible-vault what
would be the expected file's mode in our environment
(vault_file_permission) and if we should warn when that is different
from the actual file's permission (vault_file_permission_warning).
Although I'd prefer to have the vault file to adhere to umask 077
because I'm running from a central location and not sharing anything
with other users (there are other security mechanisms to limit who can
run access the account used for ansible), the warning option might be a
good compromise.
(Un)fortunately I don't have a good criminal mind so I can't think of
many ways this would be a security issue. Perhaps others can weight in
here.
Giovanni