This example demonstrates a realistic method of allowing development teams in an enterprise setting to self-manage their
own repo bindings to Vault through modifying JSON files while allowing for security control (via CODEOWNERS or other PR approval)
of changes, if necessary.
Note that this method precludes effective use of vault_policy
resources to generate policy names.
This method is most effective if policies are generated in a separate process and passed in as part of the rest of the JSON configuration.
Dev teams create their own JSON files representing repos they own and wish to bind to a Vault role.
Name |
Version |
vault |
3.12.0 |
Name |
Source |
Version |
github_oidc |
digitalocean/github-oidc/vault |
~> 2.1.0 |
Name |
Description |
Type |
Default |
Required |
vault_address |
The origin URL of the Vault server. This is a URL with a scheme, a hostname, and a port but with no path. |
string |
n/a |
yes |
bindings_json_pattern |
A pattern designating a collection of JSON files to parse for OIDC binding definitions. For pattern format, see fileset . |
string |
"bindings/*.json" |
no |
Name |
Description |
auth_backend_accessor |
The generated accessor ID for the auth backend. Outputting as demonstration of using a data source with the module. |
backend |
Exposing the auth backend path as an example. |
roles |
The list of Vault role names created by the module. This is a reflection of the vault_role_name value of each input item in oidc-bindings . |