AWS: How to attach a policy to an IAM user that grants him the privilege to create a verified identity and not access root identities?

Question

In the root account, I have a verified domain identity that I used to create an email identity for transactional emails.

Now, I created a new IAM account.

I would like to attach a policy to this IAM account that allows it to create a verified email identity using that verified domain identity in the root account.

And he must not be able to list nor use the verified email identity in the root account.

Should I use an inline policy for this (which I know should be avoided and left as a last resort) or normal permission configuration?

If so how should I write or pick such a policy?

---

EDIT 1: When I tried to create an email using the IAM account, just to see what AWS would say, this is what's written in the notification:

You do not have sufficient access to perform this action.

User: arn:aws:iam::122443365328:user/iam-user-name is not authorized to perform: ses:CreateEmailIdentity on resource:

arn:aws:ses:us-region:122443365328:identity/test@dmain_name.com because no identity-based policy allows the ses:CreateEmailIdentity action

And when I searched for the CreateEmailIdentity in the inline policy creation dashboard, it was not found:

---

EDIT 2:

I have actually found it when I picked SES-v2 as a service:

I have granted the IAM user these privileges:

And in resources section:

I added the ARN of the verified domain name:

This is the result:

But, still when I try to create an email identity using the IAM account, I still get this:

You do not have sufficient access to perform this action. User: arn:aws:iam::12xxxxxx5328:user/iam-user-name is not authorized to perform: ses:CreateEmailIdentity on resource: arn:aws:ses:us-west-2:122443365328:identity/dev@domain_name.com because no identity-based policy allows the ses:CreateEmailIdentity action

What I don't understand here is the meaning of not being authorized to perform ses:CreateEmailIdentity on the resource that I am trying to create which is the new email.

How can I be authorized to do that on an email identity that still doesn't exist.

---

EDIT 3:
Even after created an email using the root user and granted the IAM user the privilege of sending emails using that email using this policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "stmt1643366831422",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::12xxxxxx328:user/iam-user-name"
      },
      "Action": [
        "ses:SendEmail",
        "ses:SendRawEmail",
        "ses:SendTemplatedEmail",
        "ses:SendBulkTemplatedEmail"
      ],
      "Resource": "arn:aws:ses:us-west-2:12xxxxxxxx28:identity/test2@domain_name.com",
      "Condition": {}
    }
  ]
}

When I send email in the backend, this is what gets logged:

~ file: emailServices.js ~ line 297 ~ .then ~ error AccessDenied: User arn:aws:iam::12xxxxx5328:user/iam-user-name' is not authorized to perform ses:SendEmail' on resource `arn:aws:ses:us-west-2:1xxxxx28:identity/domain_name.com'

Then I authorized the iam user to send email on the Domain Identity using the same policy but applied on the Domain Identity.

Now, sending emails using the IAM user credentials works.
The problem is that he can send emails using all verified email idenitities.
But, I want him to be able to do so by only using the corresponding email identity that was created specifically for that IAM user.

---

NOTE 1:
I am aware that I should not use the root account and should instead only use IAM accounts.

Answer 1

IAM policy to create email identities for any email in a domain

Your IAM policy needs to be something similar to the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CreateEmailIdentity",
            "Effect": "Allow",
            "Action": "ses:CreateEmailIdentity",
            "Resource": "arn:aws:ses:us-west-2:12xxxxxxxx28:identity/*@domain_name.com"
        }
    ]
}

Notice that I am using *@domain_name.com instead of domain_name.com. This would allow you to create email identities for test@domain.com, test2@domain.com, etc. since '*' is a wildcard. You can also specify "arn:aws:ses:us-west-2:12xxxxxxxx28:identity/test@domain_name.com" as the resource if you want to restrict it to a specific email identity.

Fixing the send email issue

I can replicate the issue if:

1. domain_name.com email identity is properly created and verified
2. I create test@domain_name.com email identity using sesv2 CreateEmailIdentity, but not actually verify it by clicking on the confirmation link in the verification email sent by AWS. The console would say the email identity is verified (because the email identity domain_name.com for the overall domain is verified) but this is NOT correct. aws sesv2 list-email-identities gives the actual verification status of all email identities.

In scenarios where the domain identity (domain_name.com) is verified but not the specific email identity (test@domain_name.com), AWS tries to use the domain_name.com email identity to send the email, which is blocked by your IAM policy. If you try to force it to use the test@domain_name.com email identity (SourceArn in SES SendEmail, FromEmailAddressIdentityArn in SES V2 SendEmail), it will give you the correct 'Email identity is not verified' error.

If the test@domain_name.com email identity is actually verified, it works correctly.

Side notes:

1. The correct terminology is IAM user, not IAM accounts.

2. Should I use an inline policy for this (which I know should be avoided and left as a last resort) or normal permission configuration?

I have no idea what you mean by 'normal permission configuration', but there are three types of policies you can attach to an IAM user:

• AWS managed policies: These are almost impossible to use for any granular policies and are not applicable for your requirements.
• Customer managed policies: You can create your own custom managed policy and use it for multiple IAM users, roles, and groups. Can be used for your requirements.
• Inline policies: You can create an inline policy which is only applicable to a specific IAM user, role, or group. Can be used for your requirements.

3. How can I be authorized to do that on an email identity that still doesn't exist.

The ARN format is purely dependent on the email or domain being verified, which is why you can add it in the IAM policy even if the resource does not exist beforehand.