search

aws-samples / iam-identity-center-team

Open-source temporary elevated access solution for AWS IAM Identity Center.
https://aws-samples.github.io/iam-identity-center-team/
MIT No Attribution
250 stars 59 forks source link

Sending SES emails using SourceARN property does not work when the SES service for the account TEAM is deployed to is still in sandbox mode #201

Closed reidca closed 1 month ago

reidca commented 3 months ago

If TEAM is deployed to specific account as per the recommendations in the documentation, it is unlikely that SES would be configured in this account and use of the SourceArn attribute to send as a verified identity in another account is helpful since it allows you to make use of a pre-configured SES implementation that has all the correct security and anti-forgery setup already.

However, this does work. There is no error reported but the emails do not get delivered. If you look into the lambda logs you will see that the "from" and "to" addresses need to be verified. However, what is not clear is verified where .In my case they were already verified in our SES production account (by virtue of the entire domain being verified). After a fair bit of troubleshooting and reading the document here: Sending emails for the identity owner for Amazon SES sending authorization - Amazon Simple Email Service it says "Additionally, the AWS accounts of both the identity owner and the delegate sender have to be removed from the sandbox"

Therefore you need to verify the source address that the emails will come from (you can do this by attaching the smtp address to your inbox if you have access to do this and then AWS send you a link to click) or verify the entire domain via DNS. Then you need to ask AWS to take the account out of sandbox mode.

Just to be clear, you may already have SES in a production or other account that is already out of sandbox but this is not enough. You need to get SES service in the account where TEAM is deployed to also be out of sandbox.

Also, if you have not seen the other issue I raised around SES regions it is worth also looking at it: https://github.com/aws-samples/iam-identity-center-team/issues/200

github-actions[bot] commented 1 month ago

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 7 days it will automatically be closed.

reidca commented 1 month ago

It is really disappointing to take to investigate and report an issue which receives not a single comment from any of the maintainers then is closed due to it being stale. This does not encourage people to get involved. Do you have any thoughts on this @tawoyinfa

tawoyinfa commented 1 month ago

@reidca one of the prerequisites documented for using SES as a notification source for TEAM is to move SES out of sandbox mode.. This requirement is not controlled by TEAM itself but a function of the SES service.
From your comment, I understand that you have moved the primary SES account out of sandbox mode. Are you struggling to do the same for the account where TEAM has been deployed as well ?

reidca commented 1 month ago

No, I have this working now.

However it is not clear, at least to me, from the documentation that when using the SourceArn which specifies an identity in a different account that both that account and the account where TEAM is deployed need to be taken out of sandbox.

This is pretty confusing if you consider the emails are not being sent from the TEAM account in this situation. Logically it would seem that the client is just connecting directly to the other account but the sandbox requirement exists for both accounts nonetheless.

I am not suggesting this is a fault with TEAM but the documentation could be clearer under these scenarios.

tawoyinfa commented 1 month ago

@reidca makes sense. We would update the documentation to make this clearer