I want to give access to my developer to set up EC2 and MongoDB for my app. Basically, moving everything from his server to my on AWS.
I created a Group called "Developer" and set the Policy to "PowerUserAccess".
I have added a User to this group, meaning he now has "PowerUserAccess" access.
My question:
Should I specify more permission now for that specific user as it seems to me that he now has more access than he actually needs? If yes, how to do so?
Poweruseraccess Group basically have full access to all aws services except management of IAM settings.
This subject very well documented with user case scenarios and best practices on AWS
Provide access only to EC2 Instances using "AmazonEC2FullAccess".
Launch an EC2 instance and provide the Public IP and the key(or create a user) to Developer, So that he can configure the instance.
If the server is an EC2 Instance, you can ask him to create an AMI and share the AMI with your account.
Basically, moving everything from his server to my on AWS.
Try to limit the permissions to only what is necessary for the developer to perform thier function and meet your business requirements. You can do that by creating a Developer group with a customer managed policy that meets these conditions:
Restrict the group permissions to a region or regions you'd like your app to run in.
Create a VPC and restrict the group to only create EC2 instances in this VPC to limit a breach to not affect or communicate with other instances.
For cost considerations, decide what time of instances are necessary for your business requirements and restrict the permissions to that.
Here's how you can apply this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": [
"arn:aws:ec2:[region]:[account id]:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:InstanceType": "m1.small"
},
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:[region]:[account id]:vpc/[vpv id]"
}
}
}
]
}
It is possible that you don't need to specify both the VPC and EC2 instance resource to restrict this to a specific region. Specifying the VPC condition might be enough. You could simply replace the resource value with a * e.g "Resource": "*".
I suggest you create different groups with different granular permissions.
For instance,
You would want to give some developers read access only, some developer read and write and some read, write & delete access.
Thus, you can create three groups-
DeveloperWithReadAccess,
DeveloperWithReadAndWriteAccess
DeveloperWithReadWriteDeleteAccess
So that generic access can be given using aws managed policies and customer managed policies. If you have any specific case, then you can use inline policy for any specific user.
Official white also suggests the same.
IAM groups are a powerful tool for managing access to AWS resources. Even if you only have one user who requires access to a specific resource, as a best practice, you should identify or create a new AWS group for that access, and provision user access via group membership, as well as permissions and policies assigned at the group level.
You can read the same at
https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf
Related
Was wondering if anyone had luck limiting the type of instances a user could chose from the Sagemaker Studio-Jupyter. Did not want to enforce the limitation on the Domain role and was trying to create custom roles that could be attached to user profiles. Tried with the "createApp" and denying the larger instances, but found it becoming a road-block (Sagemaker.createApp not permitted) when a new user profile tries to launch the studio for the first time. Is there anyway to allow them to create the default APP, but limit the choice of the instances that he/she can select for the image using IAM ?
Sample Policy used :
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": "sagemaker:CreateApp",
"Resource": "*",
"Condition": {
"ForAllValues:StringLike": {
"sagemaker:InstanceTypes": [
"ml.c5.3xlarge",
"ml.c5.4large",
"ml.c5.9xlarge",
"ml.m5.4xlarge",
"ml.m5.12xlarge",
"ml.m5.16xlarge",
"ml.m5.24xlarge",
"ml.c5.4xlarge",
"ml.c5.9xlarge",
"ml.c5.12xlarge",
"ml.c5.18xlarge",
"ml.c5.24xlarge",
"ml.g4dn.*",
"ml.p3.*"
]
}
}
}
This works fine on a user profile that has logged/started the "default" App, but limits a new user with the same role/policy from launching issuing "Open Studio".
Saw this which was quite similar to the ask - https://github.com/aws/amazon-sagemaker-examples/issues/1499
Any thoughts, pointers ?
Thanks,
Mano
The IAM policy which you are using Denies the CreateApp permission for users with certain type of instances (large instances).
You should have another IAM Poicy attached with users/roles to grant the CreateApp for all other instance types including system and default.
Note: if you are have another IAM statement which grants the permission to all instance types, ensure the policy has the permission to use the system and default instance types.
See the IAM Policy discussed in the Github question
To troubleshoot this issue, check the CreatApp API request from AWS CloudTrail to see the errormessage and understand the issue.
I have created a policy for restricting access of a user to a single instance as:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1392113879000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"arn:aws:ec2:us-east-1:account:instance/instance_id"
]
}
]
}
But I am getting this error:
You are not authorized to describe Running Instances
You are not authorized to describe Elastic IPs
You are not authorized to describe Volumes
You are not authorized to describe Snapshots
You are not authorized to describe Key Pairs
You are not authorized to describe Load Balancers
You are not authorized to describe Placement Groups
You are not authorized to describe Security Groups
I cant see the instance in the console. If i cant implement this thing then what is the use of policies!!
Im stuck please help
from iam-policies-for-amazon-ec2
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.
So, wiritng ec2:* is not going to help you. Instead, you should provide exact API actions that you wish to grant to this user.
Also, quoting from the same link referred above:
To specify all resources, or if a specific API action does not support ARNs, use the * wildcard in the Resource element as follows:
Assigning restrictive EC2 IAM polices is a bit complicated. You may want to read above referred link in detail as well as this link.
Check your region. Your policy uses US-East-1, but where are your instances? US-West-2?
I have read the AWS documentation and it wasn't helpful... at least not for me. I have read about IAM and the user policy on the EC2.
I want to make users have full access/(or just some actions allowed) only on ONE ec2 instance.
The region I'm using is eu-west-1(Ireland). I made this policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/INSTANCE_ID"
}]
}
and when I login as the user, I see that I'm not authorized:
You are not authorized to describe Running Instances
You are not authorized to describe Elastic IPs
You are not authorized to describe Volumes
You are not authorized to describe Snapshots
You are not authorized to describe Key Pairs
You are not authorized to describe Load Balancers
You are not authorized to describe Placement Groups
You are not authorized to describe Security Groups
If I apply the following policy for the resource attribute:
"Resource": "arn:aws:ec2:*"
it's Ok but it's not what I need because users have access on all EC2 instances.
I want to know if this is a bug of AWS or there are problems with eu-west-1 region or this policy isn't supported already? Or maybe I'm wrong, if so, please help me how to do
The recently introduced Resource-Level Permissions for EC2 and RDS Resources are not yet available for all API actions, but AWS is gradually adding more, 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.
See also Granting IAM Users Required Permissions for Amazon EC2 Resources for a concise summary of the above and details on the ARNs and Amazon EC2 condition keys that you can use in an IAM policy statement to grant users permission to create or modify particular Amazon EC2 resources - this page also mentions that AWS will add support for additional actions, ARNs, and condition keys in 2014.
Possible Workaround/Alternative
Instead of or in addition to constraining access on the individual resource level, you might want to check into (also) using Conditions combined with Policy Variables, insofar ec2:Regionis one of the supported Condition Keys for Amazon EC2 - you might combine your policy with one that specifically handles Describe* actions, e.g. something like this (untested):
{
"Statement": [
{
"Action": [
"ec2:Describe*"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:Region": "eu-west-1"
}
}
}
]
}
Please note that this would still allow the user to see all instances in eu-west-1, even though your original policy fragment would prevent all API actions that already support resource level permissions (e.g instance creation/termination etc.).
I've outlined yet another possible approach in section Partial Workaround within my related answer to How to hide instances in EC2 based on tag - using IAM?.
Good Luck!
Is it possible to share an AMI using AWS SDK? I know I can share AMI images using AWS console or CLI as described in http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html .
I searched through the AWS documentation but I have not been able to find any documentation/examples that let you share AMIs using AWS SDK. Is it possible at all?
EDIT: Also, is it possible to share AMI images to other IAM users?
That's right to modify and attribute on an AMI (or Amazon Image) you want to follow the link that you provided. (http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-ModifyImageAttribute.html)
The AMI section of EC2 only allows you to create minimal permissions. One is the permissions given an AWS account Id which is usually something like: 123456789012. Keep in mind that an account Id is associated to the main or primary user of the AWS account (for example your email address). The other type of permission it allows you to do is group permissions but it looks like Amazon hasn't gotten around implementing it yet since the only value allow for Group is all.
AIM provides you more granular permission access for users that are below in hierarchy from main account id (or the main email address).
Now to use AIM to give permissions to Amazon Images (AMIs) you need to associate an AIM policy to a user or group that has AMI permissions. For example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1388772918000",
"Effect": "Allow",
"Action": [
"ec2:CreateImage",
"ec2:DeregisterImage"
],
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:instance/*",
"arn:aws:ec2:us-east-1:123456789012:image/*"
]
}
]
}
This policy gives permissions to create and deregister and image on all the instances and images under us-east-1 for account id 123456789012.
You can do all of the above programmatically too.
[Edit]
This is the list of possible EC2 ARN values from http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-ec2 :
arn:aws:ec2:region:account:instance/instance-id
arn:aws:iam::account:instance-profile/instance-profile-name
arn:aws:ec2:region:account:placement-group/placement-group-name
arn:aws:ec2:region::snapshot/snapshot-id
arn:aws:ec2:region:account:volume/volume-id
Absolutely. For example look at the boto.ec2.image class. (The python sdk)
http://boto.readthedocs.org/en/latest/ref/ec2.html#module-boto.ec2.image
I'm sure the ruby, js and java SDKs can do it too as they all use the AWS API.
As a matter of fact the cli also uses the API.
Also here's for example the EC2 API reference on how to create an image.
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-CreateImage.html
And yes you can share AMIs with other users depending on the AIM policies on the users.
I'm new to AWS. My client uses AWS to host his EC2 instances. Right now, we are trying to get me API access. Obviously, I need my authentication details to do this.
He set me up an IAM identity under his account, so I can login to the AWS web console and configure EC2 instances. I cannot, however, for the life of me, figure out where my API access keys are displayed. I don't have permissions to view 'My Account', which is where I imagine they'd be displayed.
So, what I'm asking, is how can he grant me API access through his account? How can I access the AWS API using my IAM identity?
Michael - sqlbot's answer is correct (+1), but not entirely complete given the comparatively recent but highly useful addition of Variables in AWS Access Control Policies:
Today we’re extending the AWS access policy language to include
support for variables. Policy variables make it easier to create
and manage general policies that include individualized access
control.
This enables implementation of an 'IAM Credentials Self Management' group policy, which would usually be assigned to the most basic IAM group like the common 'Users'.
Please note that the following solution still needs to be implemented by the AWS account owner (or an IAM user with permissions to manage IAM itself), but this needs to be done once only to enable credentials self management by other users going forward.
Official Solution
A respective example is included in the introductory blog post (and meanwhile has been available at Allow a user to manage his or her own security credentials in the IAM documentation too - Update: this example vanished again, presumably due to being applicable via custom solutions using the API only and thus confusing):
Variable substitution also simplifies allowing users to manage their
own credentials. If you have many users, you may find it impractical
to create individual policies that allow users to create and rotate
their own credentials. With variable substitution, this becomes
trivial to implement as a group policy. The following policy permits
any IAM user to perform any of the key and certificate related actions
on their own credentials. [emphasis mine]
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action":["iam:*AccessKey*","iam:*SigningCertificate*"],
"Resource":["arn:aws:iam::123456789012:user/${aws:username}"]
}
]
}
The resource scope arn:aws:iam::123456789012:user/${aws:username} ensures that every user is effectively only granted access to his own credentials.
Please note that this solution still has usability flaws depending on how AWS resources are accessed by your users, i.e. via API, CLI, or the AWS Management Console (the latter requires additional permissions for example).
Also, the various * characters are a wildcard, so iam:*AccessKey* addresses all IAM actions containing AccessKey (see IAM Policy Elements Reference for details).
Extended Variation
Disclaimer: The correct configuration of IAM policies affecting IAM access in particular is obviously delicate, so please make your own judgement concerning the security impact of the following solution!
Here's a more explicit and slightly extended variation, which includes AWS Multi-Factor Authentication (MFA) device self management and a few usability enhancements to ease using the AWS Management Console:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:CreateAccessKey",
"iam:DeactivateMFADevice",
"iam:DeleteAccessKey",
"iam:DeleteSigningCertificate",
"iam:EnableMFADevice",
"iam:GetLoginProfile",
"iam:GetUser",
"iam:ListAccessKeys",
"iam:ListGroupsForUser",
"iam:ListMFADevices",
"iam:ListSigningCertificates",
"iam:ListUsers",
"iam:ResyncMFADevice",
"iam:UpdateAccessKey",
"iam:UpdateLoginProfile",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate"
],
"Effect": "Allow",
"Resource": [
"arn:aws:iam::123456789012:user/${aws:username}"
]
},
{
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice",
"iam:ListVirtualMFADevices"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::123456789012:mfa/${aws:username}"
}
]
}
"You" can't, but:
In IAM, under Users, after he selects your user, he needs to click Security Credentials > Manage Access Keys, and then choose "Create Access Key" to create an API Key and its associated Secret, associated with your IAM user. On the next screen, there's a message:
Your access key has been created successfully.
This is the last time these User security credentials will be available for download.
You can manage and recreate these credentials any time.
Where "manage" means "deactivate or delete," and "recreate" means "start over with a new one." The IAM admin can subsequently see the keys, but not the associated secrets.
From that screen, and only from that screen, and only right then, is where the IAM admin can view the both key and the secret associated with the key or download them to a CSV file. Subsequently, one with appropriate privileges can see the keys for a user within IAM but you can never view the secret again after this one chance (and it would be pretty preposterous if you could).
So, your client needs to go into IAM, under the user he created for you, and create an API key/secret pair, save the key and secret, and forward that information to you via an appropriately-secure channel... if he created it but didn't save the associated secret, he should delete the key and create a new one associated with your username.
If you don't have your own AWS account, you should sign up for one so you can go into the console with full permissions as yourself and understand the flow... it might make more sense than my description.