Feature request: vault_hcl_policy_document data source (like aws_iam_policy_document)

[jgiles]

It would be nice to write Vault policies directly as HCL in our Terraform files and have them subject to Terraform validation and editor integrations. Currently it seems the policy documents need to be written as strings (a bit of a pain to edit) or read from files (where you can't do substitutions).

An analogous function is served in the aws provider by aws_iam_policy_document.

The idea is that instead of:

resource "vault_policy" "example" {
  name = "dev-team"

  policy = <<EOT
path "secret/my_app" {
  policy = "write"
}
EOT
}

You could write:

data "vault_hcl_policy_document" "example" {
  path "secret/my_app" {
    capabilities = ["write"]
  }
}

resource "vault_policy" "example" {
  name = "dev-team"
  policy = "${data.vault_hcl_policy_document.example.json}"
}

References

https://www.terraform.io/docs/providers/aws/d/iam_policy_document.html

(Note that I'm new-ish to Terraform and to using it for Vault, so please let me know if I've mixed something up).

[jgiles]

(updated to use "capabilities" param rather than "policy")

[draggeta]

I like this idea. Not having to write unvalidated strings would be nice.

[kmcquade]

@paddycarver - just wondering if anyone has looked into this. This feature would be very welcome for my client (a vault enterprise customer) and I'd love to add this to my code.

[paddycarver]

I haven't looked in depth at this, but at the moment, I think it would take more maintenance and upkeep than we currently have the resources for. I worry about it becoming like, for example, the Nomad provider's jobspec validation, where every Nomad release we need to revendor and send out a release before people can use the new Nomad release, which isn't ideal, and leads to user frustration sometimes.

On another note, the example provided:

data "vault_hcl_policy_document" "example" {
  path "secret/my_app" {
    capabilities = ["write"]
  }
}

Wouldn't actually work, as far as I know, because an anonymous embedded block is not something--again, to my knowledge--something we can support in Terraform. I believe we need a field.

We could do something like this, potentially:

data "vault_hcl_policy_document" "example" {
  path = "secret/my_app"
  capabilities = ["write"]
}

But I don't know whether that's as useful or fits the request here. If it fits, I'd want to, at the very least, talk to the Vault team and get their feedback on how likely they think the structure of this is to change.

[kmcquade]

@paddycarver - I think it would be better to treat each path as the equivalent of a statement block (here). Let me provide an example:

Ideally:

data "vault_hcl_policy_document" "example" {
  policy {
    path = "secret/${var.app_name_passed_via_module_call}"
    capabilities = ["read", "write"]
  }

  policy {
    path = "secret/${var.secret_app_name_needs_to_read_passed_via_module_call}"
    capabilities = ["read"]
  }
}

The above ^^ could be used as a module providing policies via data source, then used with something like the following:

resource "vault_policy" "example" {
  name = "dev-team"
  policy = "${data.vault_hcl_policy_document.example.hcl}" # hcl, not JSON
}

[paddycarver]

I don't see any problem with that structure, and think it would be fine.

[djaboxx]

Ive been using a pattern where my policy definitions are an hcl tenplate, I use a template_file resource and then send the parsed output as the policy for Vault. Just wondering, does this pattern not work for people? Have people had problems using this pattern? Worse yet, would this be considered an anti-pattern?

[kmcquade]

@djaboxx yeah, i started using that pattern as well :) Probably not necessary to have this as a feature then. Especially since it's not like referencing json based AWS IAM, it's importing HCL.

I'm in favor of closing this due to the revised approach djaboxx mentioned.

@jgiles @paddycarver - FYI.

[jgiles]

@djaboxx @kmcquade FWIW, we've been following a probably-nicer pattern where we have a helper TF module accepting a "map" variable and then json-encoding it:

In helpers/policy-value/main.tf:

variable "name" {
  description = "The name of the policy. Can be path-like."
}

variable "policy" {
  description = "The policy value to json-encode and store."
  type        = "map"
}

resource "vault_policy" "policy" {
  name   = "${var.name}"
  policy = "${jsonencode(var.policy)}"
}

In some other TF file:

module "aws_admin_infra_policy" {
  source = "../helpers/policy-value"
  name   = "${var.realm_name}-aws-infra"

  policy = {
    path "${vault_mount.aws.id}/sts/admin-infra" {
      capabilities = ["create", "update"]
    }
  }
}

Basically, it allows you to write HCL policies inline with TF interpolations, and all the basic validations you get from the JetBrains plugin: https://plugins.jetbrains.com/plugin/7808-hashicorp-terraform--hcl-language-support

[sidewinder12s]

@tyrannosaurus-becks This can probably be closed since the data resource was merged?

[fairclothjm]

Closed by #283