IAM policy with ec2 full access not allowing to create EC2 instances - amazon-web-services

An IAM user created with policy EC2fullaccess is not allowed to create ec2 instances in any other region except N.virginia . What could be the reason ?
Policy attached to the user :
"Version": "2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "elasticloadbalancing:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "cloudwatch:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "autoscaling:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"autoscaling.amazonaws.com",
"ec2scheduled.amazonaws.com",
"elasticloadbalancing.amazonaws.com",
"spot.amazonaws.com",
"spotfleet.amazonaws.com",
"transitgateway.amazonaws.com"
]
}
}
}
]

Do you know what privileges your superuser/root account has? While I don't know of any accounts being limited to us-east-1 by default, I can see someone setting that up for security reasons - in fact, if it's possible I might do so myself.
The other possibility, while I don't see it in that JSON snippet, is that your entire account is limited to us-east-1, and that that rule trumps the EC2 permission outside of N. Virginia.

Related

I have a Query about AWS S3 bucket policy

I have a AWS S3 bucket in account A, This bucket was created by AWS Control Tower.
And used for collecting logs from all other account in my org,
I was trying to understand the bucket policy which is something like this
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::aws-controltower-logs-12345656-us-east-1",
"arn:aws:s3:::aws-controltower-logs-12345656-us-east-1/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "AWSBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": [
"config.amazonaws.com",
"cloudtrail.amazonaws.com"
]
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::aws-controltower-logs-12345656-us-east-1"
},
{
"Sid": "AWSConfigBucketExistenceCheck",
"Effect": "Allow",
"Principal": {
"Service": [
"config.amazonaws.com",
"cloudtrail.amazonaws.com"
]
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::aws-controltower-logs-12345656-us-east-1"
},
{
"Sid": "AWSBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": [
"config.amazonaws.com",
"cloudtrail.amazonaws.com"
]
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::aws-controltower-logs-12345656-us-east-1/o-1234/AWSLogs/*/*"
}
]
}
Now all other account in my org are able to dump there cloudtrail logs within this S3.
But i dont get one thing, i did not specified any particular or individual account number, but still other accounts are able to write content in this bucket,
Although i do see the principal which mentions relevant service name that can dump, but should,nt it only for this account itself ?
Let's analyze the rules one by one:
The first rule only says that no access without SSL is possible, it does nothing if SSL layer is present:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::aws-controltower-logs-12345656-us-east-1",
"arn:aws:s3:::aws-controltower-logs-12345656-us-east-1/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
The next two actions allow only read:
{
"Sid": "AWSBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": [
"config.amazonaws.com",
"cloudtrail.amazonaws.com"
]
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::aws-controltower-logs-12345656-us-east-1"
},
{
"Sid": "AWSConfigBucketExistenceCheck",
"Effect": "Allow",
"Principal": {
"Service": [
"config.amazonaws.com",
"cloudtrail.amazonaws.com"
]
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::aws-controltower-logs-12345656-us-east-1"
},
So the only action which allows any writing is this one:
{
"Sid": "AWSBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": [
"config.amazonaws.com",
"cloudtrail.amazonaws.com"
]
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::aws-controltower-logs-12345656-us-east-1/o-1234/AWSLogs/*/*"
}
]
}
And it says the following: You can put object under /o-1234/AWSLogs as long as you are one of the following two AWS services: Config or Cloudtrail.
Clearly, if knowing the bucket name and the org ID allows me to persuade Config or Cloudtrail to use that bucket I cannot see anything what would stop me from doing that except from some internal protection inside those services.
Based on this document:
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-set-bucket-policy-for-multiple-accounts.html
It seems that for allowing an account 111111111111 to write to that bucket you should use the following ARN pattern: "arn:aws:s3:::myBucketName/optionalLogFilePrefix/AWSLogs/111111111111/*",
So while the answer provided by #izayoi does not provide any explanation, it is still correct. Cloudtrail service should guarantee you that it will always use that account id in the log, so you can narrow down the access by listing all your account numbers. Of course, it must be updated with every each new account.
Conclusion: Yes, knowing the bucket name and your organization ID should allow every AWS account in the world to use your bucket for Cloudtrail logging with the current policy...interesting. I would probably go with listing your account numbers.
"Resource": "arn:aws:s3:::aws-controltower-logs-12345656-us-east-1/o-1234/AWSLogs/*/*"
The 1st "*" enables all account numbers.

AWS S3 Bucket Policy: How to grant access to EC2 instance?

I am really struggling with this and the AWS Official Docs simply does not help!
I have an S3 bucket set up and it is allowing public access from a few specified ip addresses. This is the custom policy that is working:
{
"Version": "2012-10-17",
"Id": "Policy1111111111",
"Statement": [
{
"Sid": "Stmt111111111",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::myapp-local-test/*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"12.122.123.111",
"121.217.73.153"
]
}
}
},
{
"Sid": "Stmt1111111111",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::myapp-local-test/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"12.122.123.111",
"121.217.73.153"
]
}
}
},
]
}
Now, instead of only allowing the above 2 ip addresses to access resources in the bucket, I also want my EC2 instance to access it.
I followed this doc: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-access-s3-bucket/
I followed the exact steps.
I have created a new IAM role, (arn: "arn:aws:iam::1223123156:role/EC2-to-S3")
I have also attached the role to my EC2 instance.
But in step 6:
6. In your bucket policy, edit or remove any Effect: Deny
statements that are denying the IAM instance profile access to
your bucket. For instructions on editing policies,
see Editing IAM policies.
How exactly do I do it? It directs me to another doc about Editing IAM policies, BUT IT DOES NOT HELP !!!
How do I remove any "Effect: Deny" statements that are denying the IAM instance profile access to my bucket?
What keyword should I use?
Here is what I tried:
{
"Version": "2012-10-17",
"Id": "Policy1111111111",
"Statement": [
{
"Sid": "Stmt111111111",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::myapp-local-test/*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"12.122.123.111",
"121.217.73.153"
]
},
"StringNotEquals": {
"aws:SourceArn": "arn:aws:iam::1223123156:role/EC2-to-S3"
}
},
{
"Sid": "Stmt1111112222",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::myapp-local-test/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"12.122.123.111",
"121.217.73.153"
]
}
}
},
{
"Sid": "Stmt1639460338435",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::myapp-local-test/*",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:iam::1223123156:role/EC2-to-S3"
}
}
}
]
}
which does not work. I still had an "Access Denied" error.
Can the docs be a little bit more specific?
Why is it so hard to get such a basic task done with aws docs??
This finally worked:
{
"Version": "2012-10-17",
"Id": "Policy1111111",
"Statement": [
{
"Sid": "Stmt11111",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::myapp-local-test/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"12.122.123.111",
"121.217.73.153"
]
}
}
},
{
"Sid": "Stmt1222222222",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::1234556:role/EC2-to-S3"
},
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::myapp-local-test/*"
}
]
}
So the trick is to drop the deny statement completely since by default everything is denied access.
And my edits earlier:
"Statement": [
{
"Sid": "Stmt111111111",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::myapp-local-test/*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"12.122.123.111",
"121.217.73.153"
]
},
"StringNotEquals": {
"aws:SourceArn": "arn:aws:iam::1223123156:role/EC2-to-S3"
}
},
the StringNotEquals part does not drop the default deny for the iam role.
If possible, you should avoid using Deny statements, since they override any Allow statements.
Your first bucket policy is saying:
Deny access to the bucket if requests are not coming from the given IP addresses
Allow access to the bucket if requests are coming from the given IP addresses
Unfortunately, the Deny will prohibit access from the EC2 instance, since it is not one of the listed IP addresses.
Instead of using Deny, just grant Allow access when needed. Access to S3 is denied by default, so users can only gain access if there is an Allow policy that grants them access.
To grant access to instance create iam instance profile and attach it your EC2 instance.
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-access-s3-bucket/

AWS IAM PowerUser Scoped to Specific Region

I'm trying to create an AWS IAM Policy that gives access to everything that a Power User has (arn:aws:iam::aws:policy/PowerUserAccess) but only in a specific region.
I started with the existing Power User policy and found this article: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_region.html
So I added the "condition" to the Power User Policy and the result is:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": "*",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Condition": {
"StringEquals": {
"ec2:Region": "us-east-2"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
This does not seem to be working as I can create EC2 instances only in the specified region... but other services are not available:
When you use the ec2:Region in the Condition key, that's EC2 specific
You'll want to try the aws:RequestedRegion for the condition key.
Beware though,
Some global services, such as IAM, have a single endpoint. Because this endpoint is physically located in the US East (N. Virginia) Region, IAM calls are always made to the us-east-1 Region
Give it a try with
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": "*",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-2"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}

S3 Bucket Policy to Allow access to specific roles and restrict all

I want to restrict access to a S3 bucket to all roles except select few roles using S3 Bucket policy.but here while i am switching into my writer and reader role its access denied.
Bucket Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::581262627839:role/Rk-S3-Reader-I-Role"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::rkimpdocs"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::581262627839:role/Rk-S3-Writer-I-Role"
},
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::rkimpdocs/*"
},
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::rkimpdocs",
"arn:aws:s3:::rkimpdocs/*"
],
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"JD",
"devops"
]
}
}
}
]
}
IAM Role Permission for writer role (Rk-S3-Writer-I-Role)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::rkimpdocs"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::rkimpdocs",
"arn:aws:s3:::rkimpdocs/*"
]
}
]
}
Output :
Access denied on both bucket policy and switching into mention role. Any help / suggestion would be helpful.
An explicit Deny will override any Allow. In your policies, the Deny in the bucket policy is causing the access denied. To give access to specific IAM roles and denying others, you should use "NotPrincipal" element. Please refer this blog which explains your exact use case.
Also, "aws:Tagkeys" condition is not supported in S3, so you have to omit that as well.

IAM policy to restrict users to instances in a specific VPC

I am trying to make a IAM policy to restrict user access to all the instances in a specific VPC. Following policy I made but not working.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1450441260778",
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "arn:aws:ec2:region:Account_num:vpc/vpc-id"
}
]
}
I have filled the corresponding account_num and vpc-id in the policy.
You want to restrict the user access and you have used the allow attribute which will give permission to access the instance . Is that the desired behavior ?
If you really want to restrict try "Effect": "Deny" in same policy .
However if you want to give access to certain users here's how you can do it .
The following below policy works for me well in that case. I use it for the developers to restrict the access to start stop the instances . You can add as many permissions as you want in the second block .
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances*",
"ec2:StopInstances*"
],
"Resource": "arn:aws:ec2:ap-southeast-1:ACCOUNT_ID:instance/i-32ds2a29"
}
]
}
ap-southeast-1 is the region for my case .
To control an instance in a specific vpc you can simply use its id .There is no separate arn for vpc+instance_id instead you can use arn:aws:ec2:region:account-id:instance/instance-id as arn refer this .
Similarly you can use the same policy to restrict the users in specific vpc by using arn:aws:ec2:region:account-id:vpc/vpc-id as arn, adding Action ec2:* and deny in effect .
There are certain permissions that cant be applied to a specific resource. These permissions will show an error when you check the policy in IAM.
In order to restrict a user to a specific VPC and allow all EC2 actions, the following policy can help you in achieving that:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "NonResourceBasedReadOnlyPermissions",
"Action": [
"ec2:Describe*",
"ec2:CreateKeyPair",
"ec2:CreateSecurityGroup",
"iam:GetInstanceProfiles",
"iam:ListInstanceProfiles"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "IAMPassroleToInstance",
"Action": [
"iam:PassRole"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::123456789012:role/VPCLockDown"
},
{
"Sid": "AllowInstanceActions",
"Effect": "Allow",
"Action": [
"ec2:RebootInstances",
"ec2:StopInstances",
"ec2:TerminateInstances",
"ec2:StartInstances",
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
"Condition": {
"StringEquals": {
"ec2:InstanceProfile": "arn:aws:iam::123456789012:instance-profile/VPCLockDown"
}
}
},
{
"Sid": "EC2RunInstances",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
"Condition": {
"StringEquals": {
"ec2:InstanceProfile": "arn:aws:iam::123456789012:instance-profile/VPCLockDown"
}
}
},
{
"Sid": "EC2RunInstancesSubnet",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:123456789012:subnet/*",
"Condition": {
"StringEquals": {
"ec2:vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-7bcd371e"
}
}
},
{
"Sid": "RemainingRunInstancePermissions",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:volume/*",
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1::snapshot/*",
"arn:aws:ec2:us-east-1:123456789012:network-interface/*",
"arn:aws:ec2:us-east-1:123456789012:key-pair/*",
"arn:aws:ec2:us-east-1:123456789012:security-group/*"
]
},
{
"Sid": "EC2VpcNonresourceSpecificActions",
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkAcl",
"ec2:DeleteNetworkAclEntry",
"ec2:DeleteRoute",
"ec2:DeleteRouteTable",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:DeleteSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-7bcd371e"
}
}
}
]
}
In order to understand in detail what each statements are doing, I would recommend reading this blog from AWS. This policy, allows the user to:
Sign in to the AWS Management Console and go to the Amazon EC2 console.
Launch an EC2 instance as long as they:
Specify a subnet in the proper VPC.
Specify the allowed instance profiles.
Start/stop/reboot/terminate/attach volume/detach volume on an instance as long as they:
Specify an instance launched with the proper instance profiles.
Delete security groups, routes, route tables, network ACLs, and ACL entries as well as authorize and revoke security group ingress and egress rules, as long as they are in the proper VPC.