gresockj commented on pull request #5391: URL: https://github.com/apache/nifi/pull/5391#issuecomment-922316815
> Thanks for working on this feature @gresockj, this will be a very useful integration option. At a high level, is the a reason for requiring secrets to be stored as JSON objects? It seems like requiring the JSON object wrapping around `value` introduces potential complexity when populating secrets from other tools. Why not just use `secretString` directly as the parameter value? > > On closer inspection, I see that the HashiCorp Vault Parameter Value Provider does require the wrapping object, but perhaps that is something to revisit as well. Great question -- regarding AWS SecretsManager, it looks like I missed in AWS's documentation the possibility of setting a plain value instead of the "key/value pair" format that translates to JSON. I agree that the simple value is the best approach, and will make that change. Regarding HashiCorp Vault, I believe this is the only way Secrets are represented in the K/V Secrets Engine (see https://learn.hashicorp.com/tutorials/vault/getting-started-first-secret). So when you put a secret like this: ``` vault kv put secret/hello foo=world ``` then the secret is represented as { "foo": "world" } in the API. However, if I find a way to avoid using JSON with Vault, I'll address that as well. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
