We use Multi Factor Authentication to protect our accounts. We login via https://My_AWS_Account_ID.signin.aws.amazon.com/console/
We want to try Amazon Mechanical Turk, however, nobody can log in at https://requestersandbox.mturk.com/ to create accounts. IAM permissions are set up but we still get AWS.MechanicalTurk.MustRegister when using the API to post hits.
Mechanical Turk supports IAM in the Requester API, but does not support it in the Requester User Interface found at http://requester.mturk.com. That's probably the root cause of the first issue you're experiencing.
In terms of the MustRegister error you're seeing in Sandbox when you post HITs, I'd suggest you start by calling GetAccountBalance. It's a read-only method that takes no parameters, and removes the risk that you're having an error in publish or somewhere else in the process. In other words, it's an API call that should always "just work."
If that's not the issue, I'd confirm that the GetAccountBalance does actually work in the MTurk production environment (the endpoint at mechanicalturk.amazonaws.com).
If GetAccountBalance works in neither, this would suggest the IAM credentials are not setup correctly. The most important things to verify are that (a) you're actually using the right IAM access key and secret key, and (b) that the IAM account you're using has the correct policies attached. On (b), make sure that on the AWS IAM Policies page, you choose AmazonMechanicalTurkFullAccess or AmazonMechanicalTurkReadOnly. At the top of that page, you must choose Attach to ensure they're attached to the right account.
I hope that helps.
Related
Help is required in the following problem we're facing 😔
Any tip would be much appreciated!
Details and environment:
A multi-tenant application that aims to provide a dedicated tenant per customer (organization), in order to achieve full separation.
AWS Cognito user pool as my users' datastore and authentication provider.
an "AWS Cognito user pool" per customer (org).
Role management - based on the built-in user pool groups. Group per role and the server-side verifies that a user's access token includes a group name in it's embedded group's list.
So far so good and everything is working as expected, using AWS Amplify's SDK, for the client side's implementation. Amplify performs well and allows me to do whatever I want. The server verifies group belonging etc.
The problem:
I want to restrict non-admin users (that doesn't belong to the "admin" group) from performing certain Cognito actions via Amplify.
2 Examples:
I want to disable non-admin users' ability to modify a specific attribute's value, via Amplify.
I want to disable non-admin users' ability to modify MFA settings for themselves, via Amplify.
The actual problem started when I wanted administrators to be able to set MFA (enable/disable) for other users, but in Cognito (as I understand it) only a user can set his own MFA settings.
What I saw and already tried:
Set read/write permissions for user attributes. So the specific attribute I want to protect is modifiable only via API calls with developer credentials. That way, admins can call my server to ask for attribute modification. The server verifies the role by a group belonging according to the access token and calls Cognito API. The problem with that solution is that it covers only the attribute modification scenario.
Create an AWS Cognito identity pool for each of the user pools. For every group in every user pool, create an AWS IAM role with a policy that would restrict or allow the wanted behavior. The could actually work. The problem with that solution is that it feels like a super-duper overkill, plus it requires me to create an extra identity pool and an IAM role for each user pool. It means that every new customer that joins the service, would require (1) user pool, (2) Cognito client application, (3) identity pool and (4) IAM Role (instead of just a user pool and Cognito client app). Essentially, implementing this solution.
The real question:
Can I restrict users in a certain group from performing actions on themselves, such as disabling the MFA (even that the user-pool's MFA is set to "Optional")?
Thank you all so much! any help would be appreciated!
Well... After long research, we have come to the understanding that there is no proper right way. Every possible solution has its own pros and cons. A consultant meeting with AWS's experts taught us that:
Options Overview:
[Server Side Only] - Solution #1 that I proposed is exactly as described. Drawbacks are the same. It could work, and access to user-attributes will be restricted. Any other action that another client would make will not be blocked.
[Identity Pools] - Solution #2 that I proposed is the most accurate one. Yet I described it with one big mistake: one identity-pool can serve multiple user-pools! So essentially, we could create only one IAM role and one identity-pool per app's role. Then we match every user-pool we want to that same identity-pool and when introducing a new role to the app - just create a new group in the user-pool and match it to the IAM role. This solution is not as complicated as thought, and it would definitely do the trick. As a bonus, you'll get the ability to control and allow access to different AWS services. That being said, it still requires management and effort.
[Post-Auth Lambda] - Solution #3 that was not mentioned here, and I started to work on a day after posting this post. I blocked the write permissions of a new boolean custom attribute called "MFA". It indicates the desired MFA configuration for the user. Only a server could edit its value (and users with the admin role will have access to the server's API endpoint that can modify it). We've deployed a lambda function that would be triggered after successful authentication (post auth trigger in Cognito user-pool). It would verify a match between the desired and current MFA configurations for the authenticated user. If there is a mismatch, throw the user out because he did something that is not allowed.
*To be exact, we created one more custom attribute called "mfa_status" and it is set to true after the user has set it's MFA configurations. The lambda checks if both MFA and mfa_status are true and the real current MFA Configurations are false. if this is the case - the user is thrown out.
The Chosen One:
The solution we picked eventually is #3 (Post-Auth lambda) as it is the most detached solution. It does not require any mix with our server or client's code, any special configurations that are specific to a user pool and it still allows us to keep working with the Cognito's Amplify SDK as a client.
Thank you all for your time, I hope this post would help someone in the future.
I'm currently creating an open source web interface for a very CPU intensive task that's making use of other open source projects. Because it is very simple and I want to keep it open source, I don't want to bother with a revenue scheme supporting it. My plan currently is to host the site in an S3 bucket and have some simple lambda functions managing the execution delegation to the client his AWS account.
My question is, is it possible to grant access to somebody his AWS account, similar to how it works with OAuth 2.0. In an ideal world, I'd like them to see a big "authorize" button redirecting them to AWS, listing the permissions and having a confirm or deny button. Trust issues aside, this is the only resource I could find and it looks quite cumbersome for somebody to authorize my app which in essence will only perform computations on their AWS EC2 account.
Actually, cross account access using IAM roles is absolutely the best way to do this. The docs have all the info you would need. It can be very simple for your user. The set up instructions for Spotinst, a third party AWS service provider, demonstrate how simple it can be. They have it in four steps:
Connect Spotinst to your Cloud Provider:
Click on the "Open template in Cloudformation" button and follow the instructions. Make sure to not refresh or leave this page until
you save your credentials.
Paste the Role ARN that was created.
Click on the "Connect account" button.
If you try it out I think you'll find it to be even easier than adding oauth to your service.
I am planning on a web page that creates an instance for an user using a specific AMI. Is there any AWS method to let the user approve my web application to do this using their credentials? (i. e. getting a secret token with certain privileges)
Similar to when you let a Facebook application have access to certain information of your profile. I am looking for a way to get a token from the user signed in so that I can create an instance for them.
I want to avoid the user the pain of doing all the manual steps of going to IAM, create a new user, get the token and then upload them to my site.
I looked into AWS Cognito but this doesn't seem to be what I am looking for.
Similar to when you let a Facebook application have access to certain information of your profile.
AWS and Facebook are not similar in any sense. Facebook is a web application. AWS something entirely different.
Facebook has users, but AWS has accounts, which in turn have users... but in AWS, don't need a user's permission to do things to resources -- what you actually need is an account's permission to do things to its resources, because resources are associated with the account, not the user.
I am looking for a way to get a token from the user signed in so that I can create an instance for them.
Users sign in to the AWS console. After this, there is no such concept as a user allowing an external application doing things under the "signed in" user's auspices.
The user has to have sufficient permissions to either create sufficiently-privileged temporary IAM credentials (such as with GetSessionToken or AssumeRole from the IAM API) and hand them over to you, or create an IAM user with sufficient privilege and hand the keys to that user over to you... or you provide them with the ARN of one of your IAM users, and your customer gives your user permission to perform the actions or assume a role in your customer's account, created for the purpose.
I want to avoid the user the pain of doing all the manual steps of going to IAM, create a new user, get the token and then upload them to my site.
That can't be avoided, by design... and, in any event, whatever exactly you are planning, your model seems flawed: it would only be a naïve user who would allow you to do this. I have accounts that are allowed to launch hundreds of instances concurrently. Does it make sense that I would allow a third party to have access to credentials that could run up a huge bill for me? (If AWS trusts a set of credentials to launch instances, then it trusts them to launch instances -- all the way up to the account's instance limits).
If you want a user to be able to launch an instance from your AMI, you can simply list it on the AWS Marketplace, or you can share the AMI with the user's account, or even just make the AMI public.
Ia m trying to enforce all users to setup MFA login when they sign up. Is this something that is possible in AWS and how or where are the instructions to do this?
Sort of. You can essentially block non-admin users from making API calls without using MFA. There's a section about setting this up in this AWS blog post. The blog post describes how to give someone access to setup MFA, and require MFA for every other interaction with the AWS API. I think this will require MFA to be used with calls from the SDK and CLI as well, so it might not be exactly what you want.
Also, I say this is only for non-admin users, because admin users would have the ability to go in and disable the MFA restriction on their account.
This is difficult to do because the MFA device needs to be setup and once you do that, you need to enter information from the device. Usually you have to enter two tokens in sequence to "synchronize" the device.
So you can't setup a virtual MFA for a user without the user. However, if you had a hardware MFA device (see https://aws.amazon.com/iam/details/mfa/) then you could setup the user and the device and then give the user the device.
It's not perfect by any means.
Yes, this can definitely be done! Of course, admin and root users are able to disable the policy, but if you so desire, you can also limit who can update or disable the policy. When the enforcement policy is in effect, when the user logs in the only thing they have access to do is to enable the MFA for their IAM user. Once they then re-login with MFA enabled, they have the access they've been issued with the IAM policies/group memberships, etc.
It is not possible to enforce MFA only in the AWS web console, because the web console is essentially a front-end to the APIs which the AWS CLI tool also accesses. Starting and managing MFA (and role) sessions on the command line is a rather convoluted process, so you may be interested in a utility whose 2.0 version I just released. It makes it very easy to start and manage MFA and role sessions. I have also included an example enforcement policy that has been carefully built to work with the utility. A companion script is also provided to make it easy to enable/assign an MFA device from the command line (e.g. for the users who don't have web console access).
You can find the utility, more information about it, and the example policies in my GitHub at https://github.com/vwal/awscli-mfa
Can AWS IAM be used to control access for custom applications? I heavily rely on IAM for controlling access to AWS resources. I have a custom Python app that I would like to extend to work with IAM, but I can't find any references to this being done by anyone.
I've considered the same thing, and I think it's theoretically possible. The main issue is that there's no call available in IAM that determines if a particular call is allowed (SimulateCustomPolicy may work, but that doesn't seem to be its purpose so I'm not sure it would have the throughput to handle high volumes).
As a result, you'd have to write your own IAM policy evaluator for those custom calls. I don't think that's inherently a bad thing, since it's also something you'd have to build for any other policy-based system. And the IAM policy format seems reasonable enough to be used.
I guess the short answer is, yes, it's possible, with some work. And if you do it, please open source the code so the rest of us can use it.
The only way you can manage users, create roles and groups is if you have admin access. Power users can do everything but that.
You can create a group with all the privileges you want to grant and create a user with policies attached from the group created. Create a user strictly with only programmatic access, so the app can connect with access key ID and secure key from AWS CLI.
Normally, IAM can be used to create and manage AWS users and groups, and permissions to allow and deny their access to AWS resources.
If your Python app is somehow consuming or interfacing to any AWS resource as S3, then probably you might want to look into this.
connect-on-premise-python-application-with-aws
The Python application can be upload to an S3 bucket. The application is running on a server inside the on-premise data center of a company. The focus of this tutorial is on the connection made to AWS.
Consider placing API Gateway in front of your Python app's routes.
Then you could control access using IAM.