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
I am using resource auth0_email_provider with AWS SES provider.
To avoid exposing credentials I am using AWS Secret Manager and terraform data source, like this:
resource "auth0_email_provider" "prod_ses_provider" {
name = "ses" # Provider type
enabled = true
default_from_address = "[email protected]"
credentials {
access_key_id = jsondecode(data.aws_secretsmanager_secret_version.auth0_ses_provider.secret_string)["aws_access_key_id"]
secret_access_key = jsondecode(data.aws_secretsmanager_secret_version.auth0_ses_provider.secret_string)["aws_secret_access_key"]
region = "us-east-1"
}
}
When I am rotating credentials manually from Auth0 interface, terraform plan doesn't show the difference between NEW values in Auth0 backend and OLD in AWS Secret Manager. It makes me think the provider is not rendering a remote state and is not validating changes. Probably this issue is related to #873 .
Expectation
I am expecting output:
# auth0_email_provider.prod_ses_provider will be updated in-place
~ resource "auth0_email_provider" "prod_ses_provider" {
id = "terraform-20240723194522071200000001"
name = "ses"
# (2 unchanged attributes hidden)
~ credentials {
~ access_key_id = (sensitive value)
~ secret_access_key = (sensitive value)
# (11 unchanged attributes hidden)
}
# (1 unchanged block hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
because I am reverting my manual remote changes and it's expected behavior.
But I see that my state is the same:
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
And it's not expected, it might follow a compromised configuration.
Reproduction
Create secrets in AWS Secret Manager
Add access key and secret access key from SES user to secret
Create Data source for terraform to get secrets from AWS Secret Manager
Configuring auth0_email_provider with those secrets as in my example.
Apply changes with terraform in Auth0.
Now we have Email provider configured (we don't need to make it work, it's not related)
Do terraform plan and we see no changes.
Go to Auth0 management console and change SES configuration with random credentials.
Do terraform plan and we see no changes but it's wrong.
Now I go and change secrets in AWS Secret Manager to the same as I used in p8
Do terraform plan and terraform show differences, but values are the same now.
At this moment nobody knows what are the secrets in Auth0 Management Console
Details are totally masked and there is no chance to validate even Access ID:
I hope it will help you to make auth0 provider even better and safer, folks! Thank you for your effort.
Auth0 Terraform Provider version
1.9.1
Terraform version
1.3.2
The text was updated successfully, but these errors were encountered:
Checklist
Description
I am using resource auth0_email_provider with AWS SES provider.
To avoid exposing credentials I am using AWS Secret Manager and terraform data source, like this:
When I am rotating credentials manually from Auth0 interface,
terraform plan
doesn't show the difference between NEW values in Auth0 backend and OLD in AWS Secret Manager. It makes me think the provider is not rendering a remote state and is not validating changes. Probably this issue is related to #873 .Expectation
I am expecting output:
because I am reverting my manual remote changes and it's expected behavior.
But I see that my state is the same:
And it's not expected, it might follow a compromised configuration.
Reproduction
terraform plan
and we see no changes.terraform plan
and we see no changes but it's wrong.terraform plan
and terraform show differences, but values are the same now.I hope it will help you to make auth0 provider even better and safer, folks! Thank you for your effort.
Auth0 Terraform Provider version
1.9.1
Terraform version
1.3.2
The text was updated successfully, but these errors were encountered: