[Policies] Non-existing path value breaking other policies

[kdefives]

Describe the bug

Context: We are using HCL file to manage our Vault policies for each of our groups. We added a policy to the group 1 with this command line:

vault policy write cs-a-group-1 group-1.hcl

The content of group-1.hcl is:

path "secret/data/myCloudProvider/myProjectA" { capabilities = ["read", "list"] } #Secret access

We added policy to the group 2 with this command line:

vault policy write cs-b-group-2 group-2.hcl

The content of group-2.hcl is:

path "myCloudProvider/MyProjectB/sts/MyRoleName" {capabilities = ["read", "list"]} #Vault Secret Engine access

With this config, everything is good and everythings works fine until we did the mistakes explained below.

Today, we had to change the policies of group 1 and we updated the HCL policy file with a mistakes:

path "secret/data/myCloudProvider/myProjectA" { capabilities = ["read", "list"] } #Secret access
path "myCloudProvider/MyProjectC/sts/thispath_not_exists/MyRoleName" {capabilities = ["read", "list"]} #Another Vault Secret Engine access

And we did this in CLI to apply new policy:

vault policy write group-1 group-1.hcl

As you can see, in the HCL file the new path added contains a non-existing path. (Obviously, in reality it was added by mistakes...). But when i did the "vault policy write" above, vault displayed that the update was done succesfully. Even if the path didn't exists in reality.

The problem is, in my case, after we applied the config below with the error, when i tried to get the secret engine with of group 2 with Terraform, i got this error message:

Error: Error refreshing state: 1 error occurred:
    * data.vault_aws_access_credentials.aws_creds: 1 error occurred:
    * data.vault_aws_access_credentials.aws_creds: data.vault_aws_access_credentials.aws_creds: error reading from Vault: Error making API request.

URL: GET https://terraform-secret-vault.subsidia.org/v1/aws/MyProjectID/config/root
Code: 403. Errors:

* 1 error occurred:
    * permission denied

The terraform code to get datasource is this:

provider "vault" {}

data "vault_aws_access_credentials" "aws_creds" {
  backend  = "aws/${var.aws_account}"
  role    = "MyRoleName"
  type    = "sts"
}

provider "aws" {
  access_key = "${data.vault_aws_access_credentials.aws_creds.access_key}"
  secret_key = "${data.vault_aws_access_credentials.aws_creds.secret_key}"
  token      = "${data.vault_aws_access_credentials.aws_creds.security_token}"
  region     = "${var.region}"
  version    = "~> 2.3"
}

To fix this problem, we had to find and fix the wrong value in the path for the other group and when we fix it, we did a new "vault policy write" for both groups and after that, the Terraform stack for group 2 was working.

To Reproduce Steps to reproduce the behavior:

1. I explained everything in detail above

Expected behavior

1. If we the path indicate in the HCL file does not exists, the command "vault policy write" should raise an error.
2. A wrong value set for group 1 should never impact another group (here the group 2). In fact, here the group 2 was impacted even if nothing changed on his side.

Environment:

• Vault Server Version (retrieve with vault status): 1.4.1
• Vault CLI Version (retrieve with vault version): Vault v1.1.1 (cgo)
• Server Operating System/Architecture: Client (linux ubuntu 64 bits) / Server (linux 64 bits)

Vault server configuration file(s):

# Paste your Vault config here.
# Be sure to scrub any sensitive values

# Please let me know if you really need that part.

Feel free to let me know if you need for info and/or if it is not clear enough.

Regards,

[kdefives]

Hello @raskchanky please can you confirm or not if this is a confirmed bug?

Thx in advance. Regards

[raskchanky]

@kdefives Thank you for your patience! I've been able to verify that vault policy write doesn't check if the policy path exists or not before writing the policy, so that part is not a bug.

It's not immediately obvious to me why an incorrect path in the policy for group 1 should affect group 2. I do notice in your example, however that MyRoleName is used by both group 1 and group 2 as well as the terraform, so maybe that's related? I'll have to dig a little further on this one.