`!vault` encrypted strings no longer decrypting through `to_yaml` after 2.19 upgrade

Get Help
21

Thanks. That helps me understand the scope of the various issues.

I’m still surprised at the vault-preserving behavior of to_yaml. Apparently I’ve never used it to emit data containing vaulted strings.

Also, the notion that to_yaml would behave differently from to_json or to_toml or to_whatever doesn’t feel right. On the other hand, json doesn’t have a tagging mechanism like yaml, so…:person_shrugging:

So to_yaml is a weird one-off. I’m settling on the opinion that there is no correct default when to_yamling data containing vaulted strings. I could see a tags.vaulted parameter which could be either unspecified or one of ['preserve', 'decrypt', 'obfuscate'], then have it fail when it’s unspecified and passed vaulted data. That would leave the door open to deal with other types of tags (“sensitive”, user-defined) down the road which might require other behaviors. (I’d really like an obfuscate option.) That scheme could be adopted by other filters, too. Alas, the “fail” part would be a breaking change, so it would have to be phased in carefully.

22

I’ve hacked together a community.general.to_yaml and community.general.to_nice_yaml filter which do not preserve vaulted strings:

They work with ansible-core >= 2.16 (which community.general 11.x.y supports; probably also some older ansible-core versions should work).

The obfuscate option sounds interesting, I’ll take a look at that tomorrow. For ansible-core 2.19+ that should be trivial to implement since transform_to_native_types allows setting redact=True; for ansible-core 2.18 and before it’s also trivial since _to_native_types right now calls value.data to decrypt, but can in that case simply return <redacted> (the string that ansible-core 2.19+ returns if redact=True).

1 Like
23

The behavior changed for that filter. Doesn’t matter if the code itself didn’t change or not.

Prior to 2.19 piping a vault encrypted string into it, would render the decrypted string, now it renders a representation of said vault encrypted string.
That is changed behavior. Doesn’t matter why that change in behavior occurs, it’s still a change.

24

Technically every bugfix is a breaking change, since it changes observable behavior.

25

The filter’s behaviour has not changed, the data you are feeding it has changed due to a bug being fixed.

This distinction does matter, because if the filter had been changed in such a drastic way it would be reasonable to revert that change to avoid breaking people’s existing Ansible content. Instead the opposite is true: addressing your case by changing the filter’s behaviour would be a breaking change with security implications.

This is not true. Here’s a demonstration of the filter’s behaviour in 2.13 (the oldest version I can easily test in my environment, released in 2022):

ezekielh@pandora testing $ cat test.j2
{{ ansible_version }}

{{ foo == "hello world" }}

{{ foo | to_yaml }}
ezekielh@pandora testing $ ansible-playbook test.yml

PLAY [localhost] ***************************************************************

TASK [template] ****************************************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

ezekielh@pandora testing $ cat /var/tmp/testfile
{'string': '2.13.13.post0', 'full': '2.13.13.post0', 'major': 2, 'minor': 13, 'revision': 13}

True

!vault |
  $ANSIBLE_VAULT;1.1;AES256
  35623336363236303833623238316533363965316461353465613163626665313735333130626337
  3266353730373737343965336666393166393634306137610a386430336632656532656265393633
  37653832663833383230303435343566313936666136643836336139633965333734303061636332
  3234336633363365610a306533633362323232386163353466346231323765316333393232356230
  3063
26

fwiw, there is an issue about this logged at Inconsistent rendering of vaulted inline vs. file vaulted variables · Issue #85722 · ansible/ansible · GitHub

We haven’t decided on what recommendation we will provide, or what theoretical change we may make to assist users here.

2 Likes