Please eliminate Anti-Patterns in Vault Documentation (e.g. Google OIDC)

I would like to express my frustration with Vault’s documentation and the difficulties I faced while dealing with Google OIDC. The format of gsuite_service_account’s JSON key file that we download from Google is already known to Vault, yet the documentation expects users to either store the file as clear text or provide a properly escaped JSON string.

Storing a file containing a secret in plain text goes against Vault’s philosophy, and not providing a one-line command to escape the JSON file properly adds an unnecessary layer of complexity. Despite my coding abilities, I spent hours trying to figure out why the value was failing to parse. When I read related issues, I discovered that many users are struggling with maps, and engineers talk about limitations of shells, making it difficult to navigate the system.

Another frustrating point is that Vault expects the file to stay in the same location forever. If a user deletes the file, the authentication process will fail. It is surprising that Vault, which has a secret engine, does not use it. In case we need to provision a new Vault node, it would be a significant inconvenience to ensure that the file is available at the correct location.

In conclusion, I hope that Vault will improve its documentation and offer a simpler solution for handling Google OIDC. Supporting HCL format and offering an option to read the key.json from a Vault secret would also be helpful.

Finally figured out how to configure Google OICD: