You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.
Initially, we were using the main Terraform configuration file main.tf.json to specify provider credentials in a per-resource manner. However, due to some security concerns associated with putting credentials into Terraform configuration files and to prevent accidental leaks (such as credentials appearing in logs * in other diagnostic info) we had switched to injecting credentials via env. variables.
Now that at least for the provider logs part we are implementing a more secure strategy with #143, we are in a position to reconsider this decision. While doing so we should consider security best practices but also specifying provider configuration/credentials in the main Terraform configuration file makes scenarios such as #38 easier even may be possible.
We had a discussion with @muvaf and @turkenh to open this issue to track this line of thought.
The text was updated successfully, but these errors were encountered:
Currently, there are two fields that authenticate Terraform call that are used for authentication, Configuration and Env:
typeSetupstruct {
VersionstringRequirementProviderRequirementConfigurationProviderConfiguration// this is a map[string]interface{}Env []string
}
Configuration could take information like region, project etc. where as Env is usually used for credentials. However, I think having two different information source for auth adds unnecessary complexity and the initial reason we had this separation is now gone with #143 . I believe we should remove either one of them and have a single place to contain all information necessary to authenticate; if it is possible let's use Env []string for all authentication and remove Configuration OR have Configuration ProviderConfiguration only to contain everything. FWIW, relying on Env is a bit riskier since provider may accept some auth configs that are not exposed as env vars (very rare?) whereas HCL file can contain any information TF allows you to set.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
What problem are you facing?
How could Terrajet help solve your problem?
Initially, we were using the main Terraform configuration file
main.tf.json
to specify provider credentials in a per-resource manner. However, due to some security concerns associated with putting credentials into Terraform configuration files and to prevent accidental leaks (such as credentials appearing in logs * in other diagnostic info) we had switched to injecting credentials via env. variables.Now that at least for the provider logs part we are implementing a more secure strategy with #143, we are in a position to reconsider this decision. While doing so we should consider security best practices but also specifying provider configuration/credentials in the main Terraform configuration file makes scenarios such as #38 easier even may be possible.
We had a discussion with @muvaf and @turkenh to open this issue to track this line of thought.
The text was updated successfully, but these errors were encountered: