This is the Terraform project used to manage Bungie's Vault instances. We use IaC principles to define customer teams' needs in variables, and then create the engines, policies, and auth groups & entities to match, without click-ops.
We are publishing this via the SIE (Sony Interactive Entertainment) OSPO (Open Source Program Office), as an example of production-tested Terraform code for managing Vault. It is not presented as the only way that you the reader should be managing your Vault, but we hope that you may learn from it.
For our most common uses of Vault, we have teams that need their executables to get KV secrets on-demand. Generally, those secrets are set statically, often by a 3rd party we don't control, and thus we don't yet take advantage of any of the dynamic secret engines.
For each team, we expect to have a group of human users that will need to access Vault to add or edit secrets; we call them "editors" and assume that they will be using OIDC, tied to an IdP (Identity Provider), in our case Okta.
We expect that those secrets will be needed by entities we call "readers", and we ensure that they can auth to Vault by identity methods like Kerberos or AWS, or using certificates or approle.
The vault-infra module is where we declare all resources that are not defined by our customers. We set up centralized authentication methods like certificate, OIDC, Kerberos, as well as namespaces if running Enterprise. We create a Vault-rooted two-tier PKI, with the subordinate CA issuing certs for auth, and for signing customer PKI engines.
The customer module depends on the vault-infra being current; it creates engines, auth groups and entities, and ACL policies based on our input variables. We assume that most of our customers have similar needs, so we loop through the variables and create our resources in Vault as specified. If a team has specific needs, a "custom" folder can be created to handle any non-standard resources.
We make new directories for our clusters, each having a vault-infra and customers modules where we define our variables and backends, and then call these as child modules. We separate directories by cluster to maintain state without putting more complexity into the system. One could use other tools to maintain your clusters - stacks, workspaces, or an orchestration platform.
You can see example modules under the environments directory
We make no representation that this is how a PKI should be designed. For more security, the root CA would be offline, not hosted in the same Vault as the issuing CAs. If you are looking to adopt something like this, ensure that what you build meets your requirements for security and performance.
Please see contributing.md