Add cloudflare_client_config data source

[rohansingh]

A cloudflare_client_config data source for accessing the configuration of the Cloudflare provider would be very helpful. This would be analogous to the google_client_config data source from the Google provider.

It would allow exporting the current Cloudflare config to other resources.

Expected Behavior

Example of what this could look like:

data "cloudflare_client_config" "current" {
}

output "account_id" {
  value = data.cloudflare_client_config.current.account_id
}

Another use case would be putting the current Cloudflare API token into a Kubernetes secret.

[jacobbednarz]

How does this differ from using variables and referencing them in other resources? I’m struggling to see what we’re getting by adding this as a data source.

[rohansingh]

The big difference is that you don't have to know in advance how things like the API token, account ID, etc., are being passed in. For example, they could be set using Terraform vars, or they could be set using CLOUDFLARE_ environment variables.

Without this, you're left having to ensure that the same variable name is used everywhere. And you have no way of accessing the token if it's passed using an env var.

Another example of this pattern is aws_region. Sure, that has a couple more features, but generally most folks have a region variable. But by using the aws_region data source, you can be sure that the region you're referencing is exactly the one that's used by the provider.

[jacobbednarz]

The big difference is that you don't have to know in advance how things like the API token, account ID, etc., are being passed in. For example, they could be set using Terraform vars, or they could be set using CLOUDFLARE_ environment variables.

Without this, you're left having to ensure that the same variable name is used everywhere. And you have no way of accessing the token if it's passed using an env var.

There is a bit of nuance in here as the only case that wouldn't use the variable is if you're using the environment variable directly. Other than that, passing in variables (either using the -var parameter or using the environment variables as TF_VAR_* approach) makes them available under the same approach as the proposed data source would.

I'm not totally sold on it yet but will leave it here for some consideration.

[rohansingh]

It's true that the only case where there is absolutely no other way is if you're using the environment variable directly. For now, I'm just passing in a variable and using it in multiple places.

However, I think having this data source would also make things less error-prone. For example, let's say you change from using var.foo to var.bar for some attribute of the provider. You might neglect to update all instances of var.foo to var.bar, especially if both variables already existed for some reason.

Being able to say reference something like data.cloudflare_config.current gives you the peace-of-mind that you're always going to be using the exact same value that the provider itself is.

[jacobbednarz]

I'm going to close this one off for now as I don't really have a firm case for why someone would use this over the existing variable reference measures. This isn't to say it's not important, just that right now there isn't a big enough push for it to require further action. If we get more requests for something like this or new information, I'm happy to reopen and reassess from there.

[rohansingh]

Just as another data point, this is becoming a pretty common feature among various providers:
https://github.com/terraform-providers/terraform-provider-github/pull/261