Send list of resources/data sources in use in Configure protocol message

[paultyng]

Current Terraform Version

0.13.0-beta3

Use-cases

When providers are being configured, if they knew all the different types of resources/data sources that are in use in the configuration, they could make sure their security footprint is as small as possible.

Attempted Solutions

Proposal

In the Configure.Request message, I propose adding the following fields:

message Configure {
    message Request {
        // ...
        repeated string resource_type_names = 3;
        repeated string data_source_type_names = 4;
    }
    // ...
}

These would be populated from the configuration with the list of all resource/data source types names that are in use in that provider.

References

[apparentlymart]

Hi @paultyng,

This sounds like an interesting use-case! Can you say a little more about what underlying concern prompted you to record it? I assume you have a specific provider or set of providers in mind here so I'd be interested to learn how exactly you are hoping those providers would behave with this new information, just in the interests of understanding the underlying use-case as well as your proposed solution to it.

Thanks!

[katbyte]

Hey @apparentlymart - the use case for azure is that we need to register all RP's the provider uses ahead of time. Right now we just register all possible ones which works, but does have some security implications on the microsoft side and they have requested that we stop. So the best solution we have thought of is to get a list of all resources used and then from that determine what RPs we will use and ensure they are registered.

[bflad]

Briefly, here's two other use cases that I believe are related on this topic. Please reach out if you would like me to write up more details or if I am off-base. 😄

• Related to the AzureRM use case, this would enable providers to generate a minimum permissions policy for a given configuration in that provider's permissions format. e.g. Given the usage of the aws_s3_bucket and aws_dynamodb_table resources in a configuration, provide a data source (or Terraform plan output) that shows the minimum IAM Policy necessary (e.g. s3:CreateBucket, s3:HeadBucket, dynamodb:CreateTable, etc.) to manage that configuration that can be supplied for centralized IAM Policy management. Another possibility for providers would be to have a data source for this information or the ability use it in a temporary manner (e.g. IAM Role assumption policy)
• Enables providers to further validate a configuration's functionality during plan. e.g. Certain AWS services only being available in certain regions.

[apparentlymart]

Thanks for sharing those use-cases, @katbyte and @bflad!

I think I can guess what is meant by "RP" from the context -- some sort of intentionally-constrained access token? -- but just for completeness/concreteness can you say what that abbreviation is short for, so we can refer to the documentation about it to understand what it entails?

---

Also, for the use-case of services only being available in certain regions, @bflad can you say a little more about what the AWS provider would do with that information that it couldn't instead do when Terraform sends the resource-specific PlanResourceChange message? I'm sensing that there's some extra validation you can do if there were a point where you could see all of the resource types at once, rather than checking on a per-resource basis, but I don't have enough imagination to come up with it myself! 😀

[bflad]

Interesting question and I apologize I did not think about PlanResourceChange eventually calling the SDK's CustomizeDiff handling, with some caching it would be possible to make that efficient per resource type. I guess the optimization in that case would mean that the upfront provider configuration could catch problems like these instead of potentially spending the time to walk through the refresh operation graph, especially if that graph already contains a large number of resources ahead of any new ones. Not a big deal by any means, but just throwing it out there. 😄

[paultyng]

@apparentlymart RP refers to Resource Providers for Azure: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types

If you limit the providers registered, then the API is unable to create resources of the unregistered types, so yes, essentially constraining the services available to the subscription I believe.

[paultyng]

Another nuance on this, if we also sent counts or something to that effect, we could do quota calculations, or perhaps that could be part of a new call to the provider to check counts against known resource limits or something.

AWS has quota lookup data sources, and an API to check quotas, so knowledge of the full count would allow the provider to validate these things earlier (similar to a dynamic max items on a resource type).