Customer managed key associated with topic with the following key policy:
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXXXXXXXX:root"
},
"Action": "kms:*",
"Resource": "*"
}
According to this:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
The evaluated permissions are a union of resource and identity policies (if you disregard policy boundaries and explicit denies).
So my question: my ECS task execution role is still complaining about missing permissions:
arn:aws:sts::XXXXXXXXX:assumed-role/ecs-task-role/XXXXX is not authorized to perform: kms:GenerateDataKey on resource: arn:aws:kms:eu-west-1:XXXXXXXXX:key/XXXXXXXX
I can of course add kms:GenerateDataKey++ to the identity policy of the role in question, but why is this necessary?
I am using Service Catalog to execute the SSM Automation Document, so my Service Catalog has its own Role called "My_END_USER_Role", and I've created another role with permission to stop the EC2 for SSM Automation Document.
My_END_USER_Role this roles has the AWSServiceCatalogEndUserFullAccess, the easy solution is to give this role directly the permission that I need but I do not want the user out of the Service Catalog do any action like stop EC2, so I want to assume MY_SSM_ROLE with extra permission, but I get this error
An error occurred (InvalidAutomationExecutionParametersException) when calling the StartAutomationExecution operation: The defined assume role is unable to be assumed.
base on AWS Troubleshooting - section Assume Role Can't Be Assumed either is role not existed which cannot be true for me or The assume role doesn't have a trust relationship with the Systems Manager service, now I am stuck here how should I give the trust relationship!!?
SSM Automation Document
description: Stop EC2 Instance
schemaVersion: '0.3'
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
AutomationAssumeRole:
type: String
default: 'arn:aws:iam::ACCOUNTID:role/MY_SSM_ROLE'
description: The ARN of the role that allows Automation to perform the actions on your behalf.
InstanceId:
type: 'AWS::EC2::Instance::Id'
mainSteps:
- name: StopInstance
action: 'aws:changeInstanceState'
inputs:
InstanceIds:
- '{{ InstanceId }}'
DesiredState: stopped
just for a test I gave MY_SSM_ROLE the admin permission and also includes this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"iam:PassRole",
"ssm:StartAutomationExecution"
],
"Resource": "*"
}
]
}
found the solution, I had to add a proper services to trust relationship for MY_SSM_ROLE Role.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com",
"iam.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
I am attempting to put a cloudwatch event rule using code:
await cloudwatchevents.putRule({
Name: 'xxx-ec2-start',
EventPattern: '{"source":["aws.ec2"],"detail-type":["EC2 Instance State-change Notification"],"detail":{"state":["running"]}}',
State: 'ENABLED',
RoleArn: `arn:aws:iam::${account.Id}:role/skynet-cloudwatch-eventbus`,
}).promise()
However, I am getting:
(node:29939) UnhandledPromiseRejectionWarning: ValidationException: Provided role 'arn:aws:iam::00000000000:role/xxx-cloudwatch-eventbus' cannot be assumed by principal 'events.amazonaws.com'.
The role already has the assume policy doc to allow events.amazonaws.com. Why does it still fail?
The reason you are getting this error is "events.amazonaws.com" is not listed as a Trusted Entity for role theRole.(in your case skynet-cloudwatch-eventbus)
One way to fix this is by going to https://console.aws.amazon.com/iam/home?region=us-east-1#roles/theRole (adapt this link to your region + real role name) > Trust Relationships tab > Edit Trust Relationships button > paste in "events.amazonaws.com" under services as in the example given below.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com",
"apigateway.amazonaws.com",
"events.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
You've probably already found your answer by now, but you might be able to figure out what's wrong by looking for AssumeRole events in CloudTrail that have errors.
In my case, I set up the assume role policy correctly, but was receiving the same message you've specified. The CloudTrail AssumeRole event provided more meaningful details:
errorCode: RegionDisabledException
errorMessage: STS is not activated in this region for account:xyz. Your account administrator can activate STS in this region using the IAM Console.
Enabling STS in this region resolved the issue in this case.
I have a Route53 health check, which submits its metrics into Cloudwatch, and finally Cloudwatch specifies thresholds and should send alerts through SNS.
However, I would like my SNS Topic to be encrypted. When I turn on SNS Topic encryption using the alias/aws/sns key I receive these messages in the Cloudwatch message history:
{
"actionState": "Failed",
"stateUpdateTimestamp": 123456778899,
"notificationResource": "arn:aws:sns:xx-region-y:zzzzzzzzzz:topic_name",
"publishedMessage": null,
"error": "null (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: ccccccccccccccccccc)"
}
This appears to not be an IAM issue with Cloudwatch, but with SNS itself being unauthorized to use the KMS resources.
I enjoy using the IAM Policy Simulator for IAM users to identify where their permissions are lacking, but there doesn't seem to be a way to validate a Service's access to other services. Is that a thing I can manage?
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html
I have also tried this with a CMK with the following policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "*"
},
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "route53.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "*"
},
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "*"
},
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::XXXXXXXX:role/OrganizationAccountAccessRole"
},
"Action": "kms:*",
"Resource": "*"
}
]
}
I'm pretty much throwing darts at a wall with the principals, but I think there's validation for sns.amazonaws.comfor SNS and events.amazonaws.com for Cloudwatch.
I received the exact same error, "null (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: ccccccccccccccccccc)", when using a CMK in this manner as well. I can understand my CMK not working properly, but the Amazon managed key I think should just work out of the box.
I've tried using a CMK which grants sns.amazonaws.com and events.amazonaws.com with kms:* permissions. Same error.
Just summarizing the correct answer here because the accepted answer seems to be outdated:.
You cannot use the Amazon managed CMK alias/aws/sns because in order to connect cloudwatch with an SNS topic encrypted with a KMS CMK, you need to set a resource-policy/access-policy on the CMK so that cloudwatch service can perform kms:GenerateDataKey* and kms:Decrypt actions on the key and the access-policy on amazon managed keys cannot be edited.
For your case, you would need to create a customer managed symmetric CMK, and edit the access-policy to allow cloudwatch service principal to access that CMK. The access-policy will look like:
"Version": "2012-10-17",
"Id": "key-policies",
"Statement": [
{
"Sid": "Enable IAM User Permissions for administration of this key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxxxxxxxx:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow cloudwatch metric to use this key",
"Effect": "Allow",
"Principal": {
"Service": "cloudwatch.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": "*"
}
]
}
Update: It's likely this information is out of date. Please try the other answers and let everyone know if they work for you.
Apparently, CloudWatch can't send messages to encrypted SNS topics according to Protecting Amazon SNS Data Using Server-Side Encryption (SSE) and AWS KMS:
Currently, CloudWatch alarms don't work with Amazon SNS encrypted topics. For information about publishing alarms to unencrypted topics, see Using Amazon CloudWatch Alarms in the Amazon CloudWatch User Guide.
However, the blog post Encrypting messages published to Amazon SNS with AWS KMS seems to indicate you can...
🤦
The service is not "events.amazonaws.com", it is "cloudwatch.amazonaws.com". You should get the SNS notifications once you change this in the key policy.
See https://docs.aws.amazon.com/sns/latest/dg/sns-server-side-encryption.html for more information.
While some AWS services use an IAM Role in your account, others use a specific principal to be granted access instead. See https://aws.amazon.com/blogs/compute/encrypting-messages-published-to-amazon-sns-with-aws-kms/.
I think in your case you need to allow the cloudwatch principal, events.amazonaws.com, to be allowed to use the KMS key you specified, in the key's policy. See the section "Enabling compatibility between encrypted topics and event sources" in the above link.
Note that as the document says, "Several AWS services publish events to Amazon SNS topics. To allow these event sources to work with encrypted topics, you must first create a customer-managed CMK and then add the following statement to the policy of the CMK." This only works with customer managed keys.
Adding just the below events.amazon.com permissions to the KMS key's resource policy did the trick for me, specifically to allow AWS::Events::Rule that had encrypted SNS topics registered as Targets for 'FAILED' CodeBuild and CodePipeline states.
{
"Sid": "Allow Events use of key (for publishing to CMK encrypted SNS topics)",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": "*"
}
Hope this saves someone else some of the frustration and time this had caused me.
I ran into the same issue today! I see there are suggestions for granting the CMK to cloudwatch.amazonaws.com and also to events.amazonaws.com. For me, I needed to grant to both for that to work. Here is the entirety of my Cloudformation definition for the CMK.
InternalSNSKey:
Type: AWS::KMS::Key
Properties:
Description: IA-Internal-SNS Encryption Key
KeyPolicy:
Version: 2012-10-17
Id: allow-root-access-to-key
Statement:
- Sid: allow-root-to-delegate-actions
Effect: Allow
Principal:
AWS: !Sub arn:aws:iam::${AWS::AccountId}:root
Action:
- kms:*
Resource: '*'
- Sid: allow-cloudwatch-to-use-key
Effect: Allow
Principal:
Service: cloudwatch.amazonaws.com
Action:
- kms:Decrypt
- kms:GenerateDataKey*
Resource: '*'
- Sid: allow-events-to-use-key
Effect: Allow
Principal:
Service: events.amazonaws.com
Action:
- kms:Decrypt
- kms:GenerateDataKey*
Resource: '*'
I am attempting to auto-deploy DAX for DynamoDB, but keep getting the following error from both python and CLI:
An error occurred (InvalidParameterValueException) when calling the CreateCluster operation: No permission to assume role: arn:aws:iam::xxxxxxxxxxxx:role/service-role/230e772f-DAXServiceRole
The CLI command i use is:
aws dax create-cluster --region some.region --cluster-name some.dax_name --node-type some.node_type --replication-factor 1 --subnet-group-name some.subnet_group_name --security-group-ids some.security_group_id --iam-role-arn some.iam_role_arn
Running this directly from the cli, works fine, running it manually through console also works fine. Anyone else had this issue?
OK, looks like my script was attempting to create the DAX cluster too soon after it created the role. This caused it to not be able to find it. I added time between and it was able to find the role.
The IAM role needs to be created with service or else you will face the same error, for example I have created role with below policy and I faced the same issue.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "some role arn"
},
"Action": "sts:AssumeRole"
}
]
}
Basically the above policy will add trust entities under Principal.
Dax IAM role need to create with below policy method to avoid above error.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "dax.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
For more details please check aws doc https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.create-cluster.cli.create-service-role.html