I want to create a power-user who has all the permission on the existing instance, but he isn't able to create a new instance.
Which permission would manage that that problem.
I am assuming "PowerUser" means all permissions, then you might want to try this permission
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "*"
}
]
}
The first statement gives full permission to your user (please adapt to your definition of "PowerUser"). The second statement explicitly denies to call the EC2 API RunInstances (http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)
You can learn more about IAM Policies at http://docs.aws.amazon.com/IAM/latest/UserGuide/PoliciesOverview.html
I'm assuming you are discussing EC2 permissions. To prevent creation of new instances, the EC2 policy action associated with this is EC2:RunInstances.
To specify a single instance, I'd suggest using a condition block with a ec2:ResourceTag/. That gives more flexibility than hardcoding it in another manner. However, this will take some thought to prevent privilege escalation.
Related
I'm currently spinning in circles trying to restore from an AWS Backup and am running into permissions errors. I have administrator access to my AWS account. I've tried creating a new policy and attach it to my user account in IAM as follows:
The issue I can't seem to get around is that I need to add the permission iam:PassRole but I can't seem to find it anywhere within the AWS portal. How can I add this permission to my policy?!
EDIT: I've created a policy with all backup permissions allowed and including iam:PassRole however I am still receiving the error message You are not authorized to perform this operation. when trying to perform the backup. The policy I've created and attached to my user looks as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"backup:*",
"iam:PassRole",
"iam:GetRole"
],
"Resource": "*"
}
]
}
“To successfully do a restore with the original instance profile, you will need to make changes to the restore policy. If you apply instance profile during the restore, you must update the operator role and add PassRole permissions of the underlying instance profile role to EC2. Otherwise, Amazon EC2 won’t be able to authorize the instance launch and it will fail.”
Here is the policy you can attach to the AWS default Backup role “AWSBackupDefaultServiceRole” to work around this issue:
{
"Version": "2012–10–17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::<Account-ID>:role/*"
}]}
Source: https://medium.com/contino-engineering/new-aws-backup-features-for-quick-and-easy-ec2-instance-recovery-c8887365ca6a
We have a bucket we want to store backups in.
The bucket is set to private not public (because it's backups) but when I try and give an IAM user permission to read and write to it AWS says that the bucket is private.
There is another bucket which is set to public where we're storing images and things that the any user should be able to see, but AWS complains that this one is set to public and is a security risk.
So not quite sure which setting should apply to which. The main goal at the moment is allowing restricted write access to the bucket for the purposes of backing up databases.
Any help would be greatly welcome :) thanks
The best practice is to keep the bucket private and give the permissions as needed, always using the Least Privilege Principle. In your case, you will need to give the users read and write permission with an IAM policy, such as the example:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::examplebucket"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::examplebucket/*"]
}
]
}
For more information, you can check: https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/
I want my AWS IAM users that belong to a specific group to be able to manage their own credentials, including the creation of their first access key. It is a requirement that they don't get other permissions such as listing the account's users.
It seems that console access is not an option as it needs permissions I don't want to grant (such as ListUsers).
Thus I tried the AWS CLI option and added the following policy, as advised in AWS documentation.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:*LoginProfile",
"iam:*AccessKey*",
"iam:*SSHPublicKey*"
],
"Resource": "arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
}
}
This works well, except that it seems AWS CLI requires an access key to login (which my users don't have yet, I want them to create their access key themselves).
As a work around, I create the access key for them, and then ask them to change it, but it's quite cumbersome.
Is there a way to log into AWS CLI with the user name and password? Is there another way to achieve my use case?
I encountered a similar issue. I want my non root users to be able to change their password and change (create/make inactive/delete) their access key for CLI access. However, those users must not be able to list users or display/do anything with other users.
My attempt to achieve the minimal policy is this JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:DeleteAccessKey",
"iam:ChangePassword",
"iam:CreateAccessKey",
"iam:ListAccessKeys"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "iam:GetAccountPasswordPolicy",
"Resource": "*"
}
]
}
Some explanation for AWS noobs like myself:
I created a custom policy in IAM > Policies > Create policy. I picked up the relevant permission, add the resources scope and then assign this permission to my user group.
iam:ChangePassword is obviously the password change permission which is restricted to the current user only by the resource = "arn:aws:iam::*:user/${aws:username}". Replace * with the account Id (without hyphens) if you need to restrict to a specific account.
As mentioned in AWS doc, iam:GetAccountPasswordPolicy is required
Sources:
AWS doc
SO: Refer to logged user in policies
iam:*AccessKey manage access key for the current user as well:
create allows the creation of a new key so that admin do not know the key
update allows make inactive action
delete allows access key deletion as there is a quota of two keys per account
We want to store some data on S3 and only allow EC2 instances or a particular user with a particular IAM role to access them. Unfortunately we're having some trouble doing this.
We set a policy on the bucket like this
{
"Version": "2012-10-17",
"Id": "SamplePolicy",
"Statement": [
{
"Sid": "Stmt1331136294179",
"Effect": "Deny",
"NotPrincipal": {
"AWS": [
"arn:aws:iam::our-account-number:user/the-user",
"arn:aws:iam::our-account-number:role/the-role"
]
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::the-bucket/*"
},
{
"Sid": "Stmt1331136364169",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::our-account-number:user/the-user",
"arn:aws:iam::our-account-number:role/the-role"
]
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::the-bucket/*"
}
]}
When we access the Bucket (using boto) with users key it works fine, from a local machine or any EC2 instance.
But, when we access the bucket from Boto we get
ClientError: An error occurred (AccessDenied) when calling the GetObject operation: Access Denied
I've confirmed that the instance has the correct IAM role
curl http://169.254.169.254/latest/meta-data/iam/info/
{
"Code" : "Success",
"LastUpdated" : "2015-10-22T09:09:31Z",
"InstanceProfileArn" : "our-account-number:instance-profile/the-role",
"InstanceProfileId" : "instance-rpofile-id"
}
I've also tried to remove the policy from the bucket, which indeed makes it accessible again.
Any ideas how to handle this?
The sample I shared here is a simplified version I've been doing for debugging. In production, we want are forcing the object to be encrypted with KMS and have an access policy on the key as well. We like that solution alot, and prefer to keep it if we can.
Thanks
One mistake with this that I've made many times involves your ARN
For some permissions you need it on the bucket itself (no /*)... and some you need on it's contents.
I'd attempt to use what you currently have, only include both, so something like...
"Resource": ["arn:aws:s3:::the-bucket/*", "arn:aws:s3:::the-bucket"]
The issue here is that for NotPrincipal you have to provide the specific session role. Unfortunately, when using InstanceProfiles (or Lambda), this session role is dynamic. AWS does not support wildcards in the principal field so therefore it is basically impossible to use NotPrincipal with an InstanceProfile.
See AWS support response here that acknowledges it as a known limitation: https://forums.aws.amazon.com/message.jspa?messageID=740656#740656
I am working on Amazon web services. Designing the custom IAM policies.
I have a user which have restricted access on the instances like he can start,stop the instances. Similarly i want to restrict the user to attach,delete specific volumes.
I have created this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "TheseActionsDontSupportResourceLevelPermissions",
"Effect": "Allow",
"Action": ["ec2:DescribeInstances","ec2:DescribeInstanceStatus","ec2:DescribeVolumeAttribute","ec2:DescribeVolumeStatus","ec2:DescribeVolumes"], ,
"Resource": "*"
},
{
"Sid": "TheseActionsSupportResourceLevelPermissions",
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:TerminateInstances",
"ec2:StopInstances",
"ec2:StartInstances",
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:us-west-2:AccountID:instance/instanceID",
"Resource": "arn:aws:ec2:us-west-2:AccountID:instance/instanceID",
"Resource": "arn:aws:ec2:us-west-2:AccountID:instance/instanceID",
"Resource": "arn:aws:ec2:us-east-1:123456789012:volume/volID",
"Resource": "arn:aws:ec2:us-east-1:123456789012:volume/volID",
"Resource": "arn:aws:ec2:us-east-1:123456789012:volume/volID"
}
]
}
when I apply this policy it does not show me any volumes.
I get an error:
error fetching the volume details.
Any lead is appreciated
Thanks
Update
The best way to test/debug IAM policies is by means of the fantastic IAM Policy Simulator (see Using the IAM Policy Simulator for the actual link and instructions). With its help, the solution below can easily be verified to be working correctly.
I recommend to add a dedicated test user to your account with no policies attached (i.e. implicit Deny All) and then using the Mode: New Policy to assemble and simulate the policy in question, e.g. for the use case at hand:
use two volumes and allow one via the policy, then simulate the policy with both resources, one will yield denied and the other allowed for AttachVolume and DetachVolume
Once satisfied, you can apply the assembled policy to the entities in your account and recheck via Mode: Existing Policies.
Initial Answer
I wonder how you have been able to apply this IAM policy, insofar it is syntactically invalid JSON (the Action field within the first Statement lacks any value)?
The syntax error aside, that's also the source of your problem:
As indicated by TheseActionsDontSupportResourceLevelPermissions, a few EC2 API actions do not support the comparatively new Resource-Level Permissions for EC2 and RDS Resources yet, see this note from Amazon Resource Names for Amazon EC2:
Important Currently, not all API actions support individual ARNs; we'll add support for additional API actions and ARNs for additional
Amazon EC2 resources later. For information about which ARNs you can
use with which Amazon EC2 API actions, as well as supported condition
keys for each ARN, see Supported Resources and Conditions for Amazon
EC2 API Actions.
You will find that all ec2:Describe* actions are indeed absent still from Supported Resources and Conditions for Amazon EC2 API Actions at the time of this writing. This also includes the ec2:DescribeVolume* actions, which is why you receive the error.
Fixing the first statement as outlined below should remedy the issue:
{
"Statement": [
{
"Sid": "TheseActionsDontSupportResourceLevelPermissions",
"Action": [
"ec2:DescribeVolumeAttribute",
"ec2:DescribeVolumeStatus",
"ec2:DescribeVolumes"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "TheseActionsSupportResourceLevelPermissions",
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:<region>:<account number>:volume/<volume id>"
}
]
}