Hello,
Consider the scenario in which we want to use ansible to deploy software to a remote, non-trusted site by cloning from a GIT repository that needs HTTP authentication.
A solution could be to include credentials for the HTTP authentication inside the repository url: e.g. http://someuser:somepass@git.example.org/path/to/repo.
That way, GIT does not prompt for password input and ansible can continue to run without blocking. However, since we do not trust the remote site, we cannot leave
sensitive data (the credentials) on it. I have made some changes to the git module to do things in such a way that the HTTP auhentication credentials are always
cleared from the remote site.
These changes workaround exposition of sensitive data after the deployment takes place (actually, after the specific step of the deployment is over).
However, while running the deployment, there are moments that sensitive data is exposed before being cleared. That means that this approach is not to make
for situations in which an untrusted person is inspecting the remote system while ansible is running.
Please, take a look at: https://github.com/Ernest0x/ansible/commit/d0d7571fcb6ff5780c3fdbb21b79d572bfaa9b85
I’ m also copying the commit log here:
In git config, any credentials found in the remote repository url (as
in the case of an http-served repo with http authentication in effect),
are removed after cloning. In other words, the remote ‘origin’
url is never left with credentials in it. Other commands (currently only
pull commands) that needed a repo argument, were changed to use the full
repo url passed from ansible and not the ‘origin’ nickname. This is
because the url corresponding to ‘origin’, having been stripped of
credentials, would lead to git prompting for password input and blocking
ansible.
Also, a delete_reflogs parameter has been added to allow for deleting
reflogs after actions that may expose sensitive data to common view.
For example, some actions, such as cloning or pulling from a repository
with a url that includes credentials, produce reflogs with messages that
contain these urls, exposing the credentials to common view.
First, what do you think of that approach?
Second, can you suggest a better solution the scenario above?