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.
Related
We have just built a new Things Enterprise server hosted at AWS on an EC2 instance and created an application to use AWS IOT. We are getting the following error
“message”: “User: arn:aws:sts::446971925991:assumed-role/Things-Enterprise-Stack-Srv-StackIAMRole-DBHBSMSY05AQ/i-095895d605fab3fa4 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::446971925991:role/Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93”
I have been told
What is the execution role of the TTES instance that is trying to assume the role? The role TTES needs to be able to assume that role. That will give the right permissions.
But I'm not sure what that means, i'm presuming i need to add / alter some permissions within an IAM role. Can someone point me in the right direction Pls.
From the error message it seems that your IAM role for Amazon EC2 has no permissions to assume a role Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93.
To add such permissions manually you can do the following:
Go to IAM Console->Roles.
In the Roles window, you can use Search bar to locate Things-Enterprise-Stack-Srv-StackIAMRole-DBHBSMSY05AQ role.
Once you find the role, you click on Add inline policy.
Once Create policy window shows, you can go to JSON tab and add the following JSON policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::446971925991:role/Bosh-Parking-IOT-Stack-TheThingsStackRoleCD9FBAD2-C44RRJJ53M93"
}
]
}
Then click Review Policy, name the policy (e.g. PolicyToAssumeRole) and Create policy
However, based on your policy names (e.g. Stack-Srv-StackIAMRole) it is possible that they have been create by CloudFormation. If this is the case, then manually changing the roles as described above is a bad practice and will lead to drift. Any changes to resources created by CloudFormation should be done using CloudFormation. Sadly, your question does not provide any details about CloudFormation templates used, therefore its difficult to comment on that more.
The policies attached to the IAM developers group I've set up are as follows:
However, launching new instances won't work. Just after a user in this group selects the key pair to associate with it, i.e. reaches the final step, they get the following message on the next page:
Launch Failed
You are not authorized to perform this operation. Encoded authorization failure message: WZzytnkJ4T3-nkMYslM...
What's preventing developers to launch new instances, given these policies?
It could be that the instance is being launched with an IAM Role, and the group does not have iam:PassRole permissions (which are outside of the ec2:* permissions space).
You should add a policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PassRoleToEC2",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*"
}
]
}
This saying "Allow this user to pass any (*) role to an EC2 instance".
Actually, you should limit such permissions only to specific roles, otherwise a normal user could select an Admin role. Then, if they logged into the instance, they would have access to credentials that have Admin permissions on the whole AWS Account.
Alternatively, do not select a Role when launching the instance. It should then launch okay (assuming that this is the issue causing the error).
The user needs a PassRole permission.
A Role must be associated with the "Launch" of the EC2 instance.
The PassRole permission helps you make sure that a user doesn’t pass a role to an EC2 instance where the role has more permissions than you want the user to have.
As in the following example, if the EC2 Launch requires access to S3 you User must be able to pass the S3 role required.
{
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::123456789012:role/S3Access"
}
Link to documentation:
https://aws.amazon.com/blogs/security/granting-permission-to-launch-ec2-instances-with-iam-roles-passrole-permission/
I've created a s3 server which contain a large number of images. I'm now trying to create a bucket policy, which fits my needs. First of all i want everybody to have read permission, so they can see the images. However i also want to give a specific website the permission to upload and delete images. this website is not stored on a amazon server? how can i achieve this? so far i've created an bucket policy which enables everybody to see the images
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AddPerm",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::examplebucket/*"
}
]
}
You can delegate access to your bucket. To do this, the other server will need AWS credentials.
If the other server were an EC2 instance that you owned then you could do this easily by launching it with an IAM role. If the other server were an EC2 instance that someone else owned, then you could delegate access to them by allowing them to assume an appropriate IAM role in your account. But for a non-EC2 server, as seems to be the case here, you will have to provide AWS credentials in some other fashion.
One way to do this is by adding an IAM user with a policy allowing s3:PutObject and s3:DeleteObject on resource "arn:aws:s3:::examplebucket/*", and then give the other server those credentials.
A better way would be to create an IAM role that has the same policy and then have the other server assume that role. The upside is that the credentials must be rotated periodically so if they are leaked then the window of exposure is smaller. To assume a role, however, the other server will still need to authenticate so will need some base IAM user credentials (unless you have some way to get credentials via identity federation). You could add a base IAM user who has permissions to assume the aforementioned role (but has no other permissions) and supply the base IAM user credentials to the other server. When using AssumeRole in this fashion you should require an external ID. You may also be able to restrict the entity assuming this role to the specific IP address(es) of the other server using a policy condition (not 100% sure if this is possible).
The Bucket Policy will work nicely to give everybody read-only access.
To give specific permissions to an application:
Create an IAM User for the application (this also creates access credentials)
Assign a policy to the IAM User that gives the desired permissions (very similar to a Bucket Policy)
The application then makes API calls to Amazon S3 using the supplied access credentials
See also: Amazon S3 Developer Guide
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.
I am relatively new to AWS, I own the primary AWS account, but need to create a "super-user" account that only has rights to create new users and can only add those users to a set predefined groups with their respective policies (eg. SES-Readonly and SES-FullAccess). I do not want that super-user to be able to create any other groups, nor should they be able to modify any policies applied to the groups. I also do not want this user to have access to the other AWS services (eg. EC2, S3 etc). Is this possible? If so, what would the policy look like?
I have read most of the IAM documentation, and looked at their examples, but I didn't find any examples that were similar to my use case :(
Thanks in advance!
Yes, you need to create an IAM user and then give it this iam policy.
{
"Statement": [
{
"Sid": "Stmt1375475989975",
"Action": [
"iam:AddUserToGroup",
"iam:CreateUser"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::152997954706:user/AMISTACK-02-WEB-User-WYEMFOJZ4BDP"
}
]
}
arn:aws:iam::152997954706:user/AMISTACK-02-WEB-User-WYEMFOJZ4BDP is an example user ARN. You'll need to add in yours specific user's arn.
An easy way to create policy files is to use: http://awspolicygen.s3.amazonaws.com/policygen.html