Support control group in vault_policy_document data source

[lawliet89]

This is a feature request to add support for control group in the vault_policy_document data source.

For example:

data "vault_policy_document" "example" {
  rule {
    path         = "secret/*"
    capabilities = ["create", "read", "update", "delete", "list"]
    description  = "allow all on secrets"

    control_group = {
        factor "ops_manager" {
            identity {
                group_names = ["managers"]
                approvals = 1
            }
        }
    }
  }
}

[gg718]

Sorry for the rant, but what's the hold up in getting this implemented? Should we be going via our HashiCorp account managers to get these sorts of things prioritized?

This isn't the first issue of this nature that's been ignored. Various other Enterprise-only features (that HashiCorp customers pay a significant amount in subscription fees for) have been open for ages with barely any acknowledgement.

[heatherezell]

Sorry for the rant, but what's the hold up in getting this implemented? Should we be going via our HashiCorp account managers to get these sorts of things prioritized?

This isn't the first issue of this nature that's been ignored. Various other Enterprise-only features (that HashiCorp customers pay a significant amount in subscription fees for) have been open for ages with barely any acknowledgement.

Hi there! GitHub identity, and trying to determine who our Enterprise customers are is a difficult and sometimes impossible problem to solve. As such, as do always recommend escalating these issues through your sales or support teams. It's not intentional for these to be "ignored" but I can definitely understand how it can be very frustrating. I'm currently brainstorming ways of customer identification with my leadership team. We thank you for your patience!

[gg718]

@heatherezell Thanks, appreciate the response.

My main gripe here is that this is an Enterprise-only feature that, by definition, only Enterprise users have access to, so GitHub identity should not matter, right? It is a given that your Enterprise customers will be the only people who are interested in this.

As a paying customer, it is my expectation that such provider features (especially those labelled with feature-parity) would be prioritized above others and be available soon after the feature is available in your other products, especially those as relatively simple as this one.

Anyway, this issue is not the place for me to continue this discussion, so I'll escalate via the channels mentioned.