AWS EC2: IAM policy for ec2:RequestSpotInstances - amazon-web-services

I need to create policy that would allow user to create spot requests, but with specific subnet and security group only. This is what I did:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RequestSpotInstances",
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:image/ami-*",
"arn:aws:ec2:us-east-1:123456789012:subnet/subnet-af016c92",
"arn:aws:ec2:us-east-1:123456789012:subnet/subnet-12a34d3c",
"arn:aws:ec2:us-east-1:123456789012:subnet/subnet-f0e844cd",
"arn:aws:ec2:us-east-1:123456789012:subnet/subnet-026ae728",
"arn:aws:ec2:us-east-1:123456789012:key-pair/*",
"arn:aws:ec2:us-east-1:123456789012:security-group/sg-b5dd94cd",
"arn:aws:ec2:us-east-1:123456789012:security-group/sg-3bda8c42"
]
}
]
}
But my spot request creation still fails:
botocore.exceptions.ClientError: An error occurred (UnauthorizedOperation) when calling the RequestSpotInstances operation: You are not authorized to perform this operation.
What is the minimum subset of permissions for RequestSpotInstances action?
Is there some possibility to debug this?

I know this is an old issue, but I just ran across the same issue in my environment. The solution for me was adding an IAM permission for "PassRole"
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1479335761363",
"Action": [
"ec2:DescribeInstances",
"ec2:RequestSpotInstances",
"ec2:RunInstances",
"iam:PassRole"
],
"Effect": "Allow",
"Resource": "*"
}]
}

According to the EC2 docs (here), ec2:RequestSpotInstances is an action which falls into the category of "Unsupported Resource-Level Permissions." Unfortunately, you will have to set the resource tag to all resources, like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RequestSpotInstances",
"Resource": [ "*" ]
}
]
}
As far as debugging goes, don't forget about the IAM policy simulator, which can be accessed from the AWS Console => IAM => User page.

Related

aws IAM role is not authorized to perform: route53:ListHostedZones

When I try to deploy terraform script using gitlab runner I am getting the following error
Error: Error finding Route 53 Hosted Zone: AccessDenied: User: arn:aws:sts::12345678:assumed-role/dev-runner/i-01b2f123f1e1a127c is not authorized to perform: route53:ListHostedZones because no identity-based policy allows the route53:ListHostedZones action
The IAM role that is attached to the runner has the following policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "*",
"Resource": [
"arn:aws:route53:::*",
"arn:aws:acm:us-east-1:12345678:certificate/*",
]
}
]
}
What I am missing here? All the actions are allowed on arn:aws:route53:::* resource.
Try to check role with AWS Policy Simulator
Here is
This action does not support resource-level permissions. Policies granting access must specify "*" in the resource element.
error is raising with your role.
Resource should be "Resource": * to be able run ListHostedZones. However, in this case the permissions will be totally insecure, so I recommend to separate the statements:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"route53:ListHostedZones",
... any other specific permissions for R53 ...
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "*",
"Resource": [
"arn:aws:acm:us-east-1:12345678:certificate/*"
]
}
]
}
And just a personal opinion: using wildcard * actions without specifying at least services (route53:*) is not looking like a good idea

AWS System Manager GetParameters permission being implicitly denied

I am trying to setup eksctl for eks but it throwing
"Error: unable to determine AMI to use: error getting AMI from SSM Parameter Store: AccessDeniedException: User: arn:aws:iam:::user/cnc is not authorized to perform: ssm:GetParameter on resource: arn:aws:ssm:us-east-1::parameter/aws/service/eks/optimized-ami/1.18/amazon-linux-2/recommended/image_id".
The IAM Permission Policy I am using is
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters",
"ssm:GetParametersByPath"
],
"Resource": "arn:aws:ssm:::parameter/*"
}
]
I also tried using policy simulation for check the permissions , it is giving me "Implicitly Denied (No matching statement)"
I had the same issue. The way I resolved it was by adding the region to the ssm resource. And also added a ssm:GetParameter like this:
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action":[
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action":[
"ssm:GetParameters",
"ssm:GetParameter",
"ssm:GetParametersByPath"
],
"Resource": "arn:aws:ssm:ca-central-1::parameter/*"
}
]
If you notice I've added the region ca-central-1 and you should change it to your current region.
For me, I was using --with-decryption for a SecureString. My Instance Profile also needed to have KMS rights to the alias/parameter-store-key
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter*"
],
"Resource": "arn:aws:ssm:us-west-2:111122223333:parameter/ITParameters/*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
]
}
Mine was in the other direction. I had ssm:GetParameter, and the error message was AccessDeniedException: User is not authorized to perform: ssm:GetParameter on resource because no identity-based policy allows the ssm:GetParameter action, but implicitly the missing ssm:GetParameters was causing the request to be denied with a misleading error message.
I think you might need to authorize the "ssm:GetParameter" action as well.
I had the same error message as #plantbeard
but mine was related to capitalisation
I was using Serverless and taking the param name from the stage enviroment eg dev
but my parameter was called /Dev/param
renaming to /dev/param fixed it for me
For anyone else who still has issues, I was receiving the same error for my Lambda function:
"AccessDeniedException: User: arn:aws:sts::xxxxxx:assumed-role/[role-name]-role-xxxxxx/[lambda-function-name] is not authorized to perform: ssm:GetParameter on resource: arn:aws:ssm:us-east-1:xxxxxx:parameter/[parameter_path1]/[parameter_pathx] because no identity-based policy allows the ssm:GetParameter action",
I found that on the policies page
https://us-east-1.console.aws.amazon.com/iamv2/home#/policies
I needed to add the rule to a "Customer managed" Type Policy Named
AWSLambdaBasicExecutionRole-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (I think someone else created this though and I just added on to it)
That looked like this
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:us-east-1:xxxxxxxxxx:parameter/[parameter_path1]/[parameter_pathx]"
}
]
}

AWS CloudWatch Cross-Account Logging with EC2 Instance Profile

When I originally setup CloudWatch, I created an EC2 Instance Profile to automatically grant access to write to the account's own CloudWatch service. Now, I would like to consolidate the logs from several accounts into a central account.
I'd like to implement a simplified architecture that is based on Centralized Logging on AWS. However, these logs will feed an on-premise ELK stack, so I'm only trying to implement the components outlined in red. I would like to solve this without the use of Kinesis.
Either the CloudWatch Agent (CWAgent) doesn't support assuming a role or I can't wrap my mind around how to craft the EC2 Instance Profile to allow the CWAgent to assume a role in a different account.
Logging Target (AWS Account 111111111111)
IAM LogStreamerRole:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::999999999999:role/EC2CloudWatchLoggerRole"
]
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
}
]
}
Logging Source (AWS Account 999999999999)
IAM Instance Profile Role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111111111111:role/LogStreamerRole"
}
]
}
The CWAgent is producing the following error:
/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log:
2018-02-12T23:27:43Z E! CreateLogStream / CreateLogGroup with log group name Linux/var/log/messages stream name i-123456789abcdef has errors. Will retry the request: AccessDeniedException: User: arn:aws:sts::999999999999:assumed-role/EC2CloudWatchLoggerRole/i-123456789abcdef is not authorized to perform: logs:CreateLogStream on resource: arn:aws:logs:us-west-2:999999999999:log-group:Linux/var/log/messages:log-stream:i-123456789abcdef
status code: 400, request id: 53271811-1234-11e8-afe1-a3c56071215e
It is still trying to write to its own CloudWatch service, instead of to the central CloudWatch service.
From the logs, I see that the instance profile is used.
arn:aws:sts::999999999999:assumed-role/EC2CloudWatchLoggerRole/i-123456789abcdef
Just add the following to the /etc/awslogs/awscli.conf to assume the LogStreamerRole role.
role_arn = arn:aws:iam::111111111111:role/LogStreamerRole
credential_source=Ec2InstanceMetadata

AWS policy for creating only the snapshots

I have attached the following policy with an IAM user that should allow the user to create a snapshot of the EC2 instance (EBS backed).
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1473146965806",
"Action": [
"ec2:CreateSnapshot"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:*:MY_ACCOUNT_ID:*/*"
}
]
}
But when the user tries to execute the command to create a snapshot, the following error occurs:
An error occurred (UnauthorizedOperation) when calling the CreateSnapshot
operation: You are not authorized to perform this operation.
What is incorrect in the policy?
CreateSnapshot doesn't support resource-level permissions, you can use a wildcard for the "Resource":"*":
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1473146965806",
"Action": [
"ec2:CreateSnapshot"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ec2-api-permissions.html#ec2-api-unsupported-resource-permissions

Giving an IAM User full access

Should an IAM User say called User1 be given full access like so:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Could it also be used to create Amazon API calls? Is this a security risk or should I create another user just to access the Amazpn API Gateway?
You should never give an IAM user full privileges. So many things could go wrong, and yes it may very well be a security risk.
If you need to manage (create, configure, or deploy) your API in API Gateway with this IAM user, you can give the user this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": "arn:aws:apigateway:*::/*"
}
]
}
Or, if you only need to invoke the API, you can use this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Resource": "arn:aws:execute-api:*:*:*"
}
]
}