Vault policy for terraform plan

[maxb]

@aram

Are you trying to do with with an Enterprise license or with OSS? With Enterprise the idea of namespaces makes this a lot safer and easier.

It really doesn’t, namespaces are a solution to a different problem entirely. Namespaces help you safely delegate unrestricted control of a subtree of Vault paths. This question is about how to safely delegate restricted control to propose changes, and obtain a Terraform plan to validate the correctness of the proposal via self-service, but then hold application of the changes for admin review.

@aram

I’d also say that there is no need to run a plan by the user, the pipeline can automatically run the plan on commit on the branch (which the user will have access to as an output) then approval then merged the branch and runs the actual apply .

This misses the point - from a security perspective, the pipeline running a plan on unreviewed Terraform code written by the user, is usually equivalent to giving the user access to the credentials the pipeline uses to run the plan - as there are many exploits a user who can submit arbitrary Terraform code to a pipeline can use, to have it deliver up the credentials it has to the user.

I believe @Cajga is already on the right path, by looking to run the terraform plan on user submissions using separate low privilege credentials.

However:

@Cajga

Does any of you have a vault policy which would be read-only for “normal” configuration paths like sys/ auth/ etc. and can be used for a terraform plan call?
Or a documented/maintained list of paths somewhere, which would need to be allowed for a terraform plan in order to be able to configure vault (without being able to read/generate secrets)?

cannot be simply answered, as what paths you need to allow depends on which secrets engines and auth methods you have mounted in Vault, and which features you want to configure using Terraform.

@jeffsanicola

This policy would be intended to be attached to a “management” role (i.e., a role that creates, updates, and deletes the AppRole roles).

But the context of this question is a low privilege, read only policy, to be used for terraform plan, to sandbox the planning of untrusted Terraform input.