Open kujenga opened 2 years ago
👋 Thanks for reporting this issue! It's definitely not the behavior we intended. This is caused by how Ansible interprets no_log
and how we create those generated values.
As you mentioned, the no_log
option is hiding the value you provide to each field.value
configuration. This is in line with how Ansible describes the no_log
option in the argument spec.
The surprising behavior for generated
fields comes from how Connect creates those values. The play simply sends the generator config to Connect and Connect returns the generated secret. As far as I know, the no_log
parameter doesn't sanitize data returned from plays, just data provided to it.
What kind of behavior do you expect when mixing known secrets with values you want to generate?
We designed it the way we did because:
Unfortunately, It looks like there's no easy way to no_log
specific fields using Ansible's built-in options. Best I could find was this SO answer.
Your environment
Collection Version: 2.2.0
Connect Server Version: 1.5.0
OS: macos 12.2
Ansible Version: 2.12.1
What happened?
When creating a new item via
onepassword.connect.generic_item
as specified in the README for this repo, I am unable to reference fields that are explicitly specified through thevalue:
method which are replaced with the valueVALUE_SPECIFIED_IN_NO_LOG_PARAMETER
when creating an item.What did you expect to happen?
I was expecting to be able to reference these values through the registered variable, in the same way that generated values are able to be accessed.
Steps to reproduce
Codeword
field via theop_item
register as follows:{{ op_item.op_item.fields.Codeword.value }}
VALUE_SPECIFIED_IN_NO_LOG_PARAMETER
It's worth noting that this behavior does not happen for auto-generated values, just for ones that are explicitly specified.
Notes & Logs
This appears to be because of the use of
no_log=True
in this line: https://github.com/1Password/ansible-onepasswordconnect-collection/blob/e126355bd11b17e5af733918ea3f775d18cc766b/plugins/module_utils/specs.py#L149There are a variety of ways to work around this issue, but it seemed inconsistent and surprising that values from the task definition are inaccessible, but auto-generated values are readily accessible.