Add a header_secret input for uri module

[PierreLesouhaitier]

SUMMARY

We use a lot uri module, and we send API token in the header. These secrets need to be hidden on the log, so we are forced to mark the entire task as no_log: true missing many logs.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

uri module

ADDITIONAL INFORMATION

Just add a header_secret input in uri with no_log=True optional argument.
It would be merged with the header input.

[ansibot]

Files identified in the description:

• lib/ansible/modules/uri.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[imjoseangel]

Hi @PierreLesouhaitier what about using the no_log option in the playbook header? Regards

[PierreLesouhaitier]

I think the no_log option in the playbook header results in the whole task to be not logged. It is a problem for us as we miss many logs. My request is to have only the token in the request header to be obliterated.

[ledgley]

This would be useful for the body in the URI module too.

[al-lac]

This would really be useful to have. We also use no_log, but if errors occur it takes a long time to find out the reason because of missing logs.

[bcoca]

waiting_on_contributor

but instead of 'hiding a special header' this should really be another 'auth type' implementation.

[imjoseangel]

I was thinking on implementing something like this:

        headers=dict(type='dict', default={}),
        secret_headers=dict(type='dict', default={}, no_log=True),

With this approach, any header that would need to be hidden will be in the headers_secret.

    - name: URI Test
      ansible.builtin.uri:
        url: http://www.example.com
        return_content: true
        headers:
          Content-Type: application/json
          Another-header: "another-header"
        secret_headers:
          x-ms-client-auth-token: "{{ token }}"
          another-token: "{{ another-token }}"
      register: myvar
      no_log: false

The header behaves like:

GET / HTTP/1.1
Accept-Encoding: identity
Host: www.example.com
User-Agent: ansible-httpget
Content-Type: application/json
Another-Header: another-header
X-Ms-Client-Auth-Token: mytoken
Another-Token: another-token
Connection: close

And Ansible logs:

            "headers": {
                "Content-Type": "application/json",
                "another-header": "another-header"
            },
            "secret_headers": {
                "another-token": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
                "x-ms-client-auth-token": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER"
            },

@bcoca @PierreLesouhaitier What do you think? It fits the requirements and gives extra functionality to the URI module but not sure if you had another solution in mind.

[sivel]

After a recent conversation, I believe the plan we want to take is to use the upcoming data tagging feature, to allow users to tags data in a playbook with SensitiveForDisplay, and not go down the route of another option in the module. Regardless, either change would need to land in 2.15 at this point.

[imjoseangel]

Thanks @sivel

Then I won't do any change but I think this should be closed IMHO.

Regards

[rverhe]

Any update on this? Or workaround?
no_log is no option of us because we need the logging =D

[jhg03a]

As a partial workaround, I set a play var show_debug: "{{ true if ansible_verbosity > 1 else false }}" then reference that in the individual uri tasks via no_log. It doesn't solve the main problem of partial data hiding, but it does give you all the data only when you're running at higher levels than the default. Another pitfall to avoid here is always specifying your loop_control labels so you don't accidentally leak sensitive info in the item label. This at least will help you understand which items in a loop of a task were responsible for a failure instead of a completely opaque task.

[azrdev]

Another pitfall to avoid here is always specifying your loop_control labels so you don't accidentally leak sensitive info in the item label

Unfortunately this does not cover running in AWX/AAP, which will show the whole loop item(s) in the task details, even when loop_control:label: hides them in the "normal" output

---

Edit:
@sivel the data tagging feature you mentioned is #80747 scheduled for ansible 2.16, correct?

[ansibot]

Thank you very much for your submission to Ansible. It means a lot to us that you've taken time to contribute.

Unfortunately, this issue has been open for some time while waiting for a contributor to take it up but there does not seem to have been anyone that did so. So we are going to close this issue to clear up the queues and make it easier for contributors to browse possible implementation targets.

However, we're absolutely always up for discussion. Because this project is very active, we're unlikely to see comments made on closed tickets and we lock them after some time. If you or anyone else has any further questions, please let us know by using any of the communication methods listed in the page below:

• https://docs.ansible.com/ansible/latest/community/communication.html

In the future, sometimes starting a discussion on the development list prior to proposing or implementing a feature can make getting things included a little easier, but it's not always necessary.

Thank you once again for this and your interest in Ansible!

click here for bot help