1Password / ansible-onepasswordconnect-collection

The 1Password Connect collection contains modules that interact with your 1Password Connect deployment. The modules communicate with the 1Password Connect API to support Vault Item create/read/update/delete operations.
https://developer.1password.com/docs/connect/
Other
113 stars 16 forks source link

Unable to access fields explicitly defined through `value` via register variables #55

Open kujenga opened 2 years ago

kujenga commented 2 years ago

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 the value: method which are replaced with the value VALUE_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

  1. Create an item as described in the README here: https://github.com/1Password/ansible-onepasswordconnect-collection#example-usage in the "Create a new Item" sub-section
  2. Attempt to access the value of the Codeword field via the op_item register as follows: {{ op_item.op_item.fields.Codeword.value }}
  3. Observe that the output value is 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#L149

There 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.

verkaufer commented 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:

  1. We wanted to protect the secrets you were providing to Connect (i.e. not leaking them when sending to Connect)
  2. We assumed the generated secret needed to be returned in plaintext so you could pass its value to some other Ansible play.

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.