aws_iam_access_key: parameter ses_smtp_password only valid in Ireland region ?

[Dylan-Feith]

Hello,

regarding the following code, I just create a user for SES as described here : https://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html#smtp-credentials

When I use the output aws_iam_access_key output with my local MTA, it successfully connects with Ireland SES service :

  SMTP<< 235 Authentication successful.

  => dylan.feith@smile.fr R=send_via_ses T=ses_smtp H=email-smtp.eu-west-1.amazonaws.com [52.213.231.181] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes DN="CN=email-smtp.eu-central-1.amazonaws.com" A=plain C="250 Ok 010701701ac250c4-6abedeee-4133-4aba-a633-3ca20aac8550-000000"

but not Frankfurt SES service:

  SMTP<< 535 Authentication Credentials Invalid
LOG: MAIN
  plain authenticator failed H=email-smtp.eu-central-1.amazonaws.com [18.196.240.113] 535 Authentication Credentials Invalid

When looking to the documentation, the SES SMTP Credentials depends on region : https://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html#smtp-credentials-convert

However, I can't see any dependency to the region when this provider generates it.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Affected Resource(s)

Run Version :

Terraform Configuration Files

$ terraform -v
Terraform v0.11.14

• provider.aws v2.47.0

Executed code :

variable "region" {
  default = "eu-central-1"
}

provider "aws" {
  version    = "~> 2.47"
  region     = "${var.region}"
  profile    = "XXX"
}

resource "aws_iam_user" "ses" {
  name  = "ses"
  path  = "/"
}

resource "aws_iam_access_key" "ses" {
  user    = "${aws_iam_user.ses.name}"
}

resource "aws_iam_user_policy_attachment" "ses" {
  user       = "${aws_iam_user.ses.name}"
  policy_arn = "${aws_iam_policy.ses.arn}"
}

resource "aws_iam_policy" "ses" {
  name        = "AmazonSesSendingAccess-frontnodejs"
  description = "Ses access"
  policy      = "${data.aws_iam_policy_document.ses.json}"
}

data "aws_iam_policy_document" "ses" {
  statement {
    actions = [
      "ses:SendRawEmail"
    ]
    resources = ["*"]
  }
}

Expected Behavior

I expect to create another input smtp_region and include it in the hash calculation or dynamically use the current run region in the calculation

Actual Behavior

It seems that the user is only useful for Ireland region

Thank you in advance
Best regards

[tsrivishnu]

As a temporary solution, I used the python script from AWS documentation on this topic to generate the SMTP password using the secret from aws_iam_access_key resource.

https://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html#smtp-credentials-convert

You might want to add more regions into the python code's --region argument to support accept them

[bflad]

Support for generating SES SMTP v4 passwords into a new ses_smtp_password_v4 attribute has been merged and will release with version 2.50.0 of the Terraform AWS Provider. Thanks to @n3ph for the implementation. 👍

Please note: The password value is region-specific to the provider region of the aws_iam_access_key resource. To work across multiple regions, separate resources are necessary.

[ghost]

This has been released in version 2.50.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!