Potentially transition to 1password for secrets management

The current methodology for sharing secrets with team members is functional, but has some challenges and limitations that may benefit from utilizing a vault like secrets manager.

Some challenges:

• Unless you rotate all secrets after somebody has been offboarded, they still have access to everything that was true at the point in time they were offboarded. With some of the shared service account credentials, that could mean the keys to the kingdom in perpetuity.
• Permission boundary layers are somewhat rigid, with infra/release/test as our conventions for 'increasing security layers' -> potentially granting overbroad permissions to things volunteers may not need access to.
• change management is difficult because we don't actually have a clear revision history (answering "when was the last time X credential was rotated", is difficult when all the credentials are in one file in git and we cant really diff the file because its encrypted).

The TSC and project itself have a 1password account for the nodejs project, but the build team is not using it/does not have access to it.

I propose we explore leveraging 1password as an option:

1. poc that we can use it for automation with the existing ansible scripts
2. verify that we can maintain the equivalent group permission boundaries that exist now (infra/release/test)

Start by reviewing the existing Ansible scripts and the current infra/release/test permission boundaries. Investigate whether 1Password can support the proposed automation and equivalent access separation. Done means a documented proof of concept and verification of those permission boundaries.