@simar7 Since the json schema is built on the state structure field names, the provider blocks will be defined as a service named providers. Will this confuse users when defining Rego policies?

@simar7 Since the json schema is built on the state structure field names, the provider blocks will be defined as a service named providers. Will this confuse users when defining Rego policies?

Hmm, what if we define it at the aws.AWS{} level rather than a struct within a struct (what you have in this PR)?

Another option could be calling it meta. It implies that it's not an actual service as naming it "providers" is a little awkward.

@simar7 You mean add terraform providers here?

I think naming it to meta sounds like a better alternate to me.

@simar7 How about naming this field as meta.tfproviders (tfproviders inside the meta structure)? so that users realise they are dealing with a terraform provider

@simar7 How about naming this field as meta.tfproviders (tfproviders inside the meta structure)? so that users realise they are dealing with a terraform provider

Could you give an example? My assumption was that each cloud can have a meta field, so the policies would look something like the following:

foo = input.aws.meta.bar[_] or foo = input.gcp.meta.bar[_].

@simar7 That's what I meant: arg = input.aws.meta.tfproviders.arg[_]

@simar7 That's what I meant: arg = input.aws.meta.tfproviders.arg[_]

But cloud args aren't related to Terraform. For instance tags is a property of AWS Cloud not something specific to Terraform right? So in short, adding .tfproviders seems unnecessary. WDYT?

@simar7 You're right, the tags are not specific to terraform. But I have added support for AWS provider attributes that are specified in the provider configuration block.

@simar7 You're right, the tags are not specific to terraform. But I have added support for AWS provider attributes that are specified in the provider configuration block.

cool, that makes sense then!