Thanks for confirmation and comments on this topic.
All these suggestions are similar to what I have been trying, in order to accomplish the decryption of my pre-generated vault file, per the original question.
I also keep reading about the alternatives, to setting the environment variable before playbook run.
But this only works when you have hands-on access, mostly when testing my ansible playbook, deployment to remote-host, etc.
All that works, even using scripts when you set your ansible.cfg with the entries like: (which depend on env variable being pre-set)
[defaults]
vault_password_file = ./Orchestration/ansible_get_sec.py
OR
vault_password_file = ./Orchestration/ansible_get_sec.sh
I was hoping to pass in the "-e sec-param=${jenkins-secret}" and use the "$sec-param" in the scripts above. Again, that works when env variable is [exported] first,
which cannot be easily done when automating straight from Jenkins-calling-ansible, yes I still don�t know if I would want that. But I will like to try just to validate the behavior.
However, as soon as the playbook command executes, the first thing that is performed is the [defaults] loading of the [vault_password_file] to resolve vault variables, as defined in the group_vars/all/vault.yml.
Please note, pre-setting the ansibel_vault_password in a file of a "deploy-repo" is not desired, because clear-text passwords, of any kind, are NOT allowed in our repos.
Also notice the suggesting on creating a file (with $sec-param), but how do you inject/stop the playbook-process to write that out, before the vault_password_file via ansible.cfg load?
Therefore, I am discouraged from using vault at the moment. Alternatively, I have overloaded my command with additional jenkins-secret-credentials parameters
==> ansible-playbook -i /inventory . . . "-e sec1=**** sec2=*** etc. etc."
I really wanted to use ansible-vault, because it opens the door more secured options.
It is possible that using the recommended [ansible/latest/modules] mentioned by Zeitounator (Jul 3, 2020 at 7:21) above may actually resolve this.
Still need to work it out with our devSecOps folks.