Restore control-side injection of module `invocation`

[nitzmahone]

Proposal: Restore control-side injection of invocation

Author: Matt Davis <@nitzmahone>

Date: 2017/10/24

• Status: New
• Proposal type: (core design)
• Targeted Release: 2.5
• Estimated time to implement: 1 day

Motivation

Until early in Ansible 2.0, the controller injected an invocation key into all task results that included the args passed to the task. Controller-side injection was removed for security reasons several releases ago (since arg-level no_log was not able to be respected), and partially replaced in basic.py. However, any task not implemented with basic.py (eg, control-side actions, Windows modules, other non-basic.py modules) do not have invocation any more, arguably a regression.

Problems

What problems exist that this proposal will solve?

• invocation is useful for more than just debug- it's necessary for some workflows (eg, async in a loop with poll: 0, go do other things, then complete the tasks and use the source args to conditionally trigger other behavior later).
• invocation will be available for all modules and actions, regardless of the technology with which they're implemented

Solution proposal

Restore controller-side injection of invocation data when the invocation key is missing from the task results. The injected data should be run through the standard heuristic filter that masks common sensitive field names. For additional security, a new bit of module/action metadata could be specified that would call out sensitive key names (or the lack thereof) that need to be filtered.

For security purposes, invocation data should not be injected control-side when the module JSON result does not parse properly (as this could allow sensitive values that are being filtered on the target side via no_log to be reintroduced).

There are other ways we could go with this as well- configuration values to opt-in/out of invocation injection, a full control-side argspec, or others..

Dependencies (optional)

N/A

Testing (optional)

Integration tests should be updated to test any new filtering surface area

Documentation (optional)

Module/action dev docs would need to be updated if new metadata is added.

[alikins]

It may be worthwhile to always separately inject invocation data on the controller side in addition to any invocation data returned from the module. I'll call this 'action invocation'

For the cases where there is no returned invocation, the 'action invocation' could be exposed to user on task result (including whatever filtering needs applied).

For cases where there is a returned module invocation, the 'action invocation' would still exist, but it wouldn't be exposed to user level (on a task result or to a callback, etc). But it would be available for things like async, and for general debug/troubleshoot.

For cases where the original invocation may be munged before it makes it to the module/action, it could be useful to have both for debugging/troubleshooting.

(Also very useful info to have at a potential debug logging level)

[bcoca]

This requires 'control side argspec' of modules as no_log observance was the reason it was removed in the first place.