I'm looking for something that can programmatically spin up instances for other AWS users after oauth. Is there something like this that Amazon provides? So they can just login with AWS account and then I can make AWS calls on their behalf.
Is there anything like this out there?
There's no logging in here. You need a cross-account role, supplied by the owner of the other account.
There is nothing like this.
It would have massive security implications.
Note that the primary entity in AWS is not the user, it is the "account." Accounts have users, and those users can only do what the account has authorized them to do.
For one AWS account ("mine") to allow another AWS account ("yours") to perform actions on behalf of my account (technically, not on behalf of "me"), I have to explicitly give you permission to do so, via IAM. One solution is to create a role with the necessary permissions and delegate access to you.
But this is unlikely to be something a well-informed user would permit, since you could easily run up substantial expenses for the user. Allowing such external access would not be a good practice.
There is, however, a way for users to launch your software on EC2 and optionally pay you a license fee billed on your behalf by AWS, through the AWS Marketplace, which is oriented towards a one-click experience for the user.
Related
I would like to run a batch job on-prem and access AWS resources in our account.
I think the recommendation is to create an IAM user, which will be a machine user. Since I don't have a way to assign a role to the on-prem machine, or federate with AWS identity, I'll create an access key and install it on the on-prem machine. What's the best way to link my machine user to a policy?
I can create an IAM policy which allows the required actions (reading AWS SSM Parameters).
But, how should I link the machine user to the policy? I'm setting up these users/policies with Pulumi. Some options I'm aware of:
I can create a role, but then I think the machine user would have to assume the role. (My understanding is that roles do not have immediate "membership", it's just that users have the ability to assume roles. Or, AWS infrastructure can be set up with a role, like an EC2 or an EKS cluster can act as a role. In the future I do plan to move this job's execution to AWS infrastructure, but for now that's not an option.) Is assuming a role easy, for example a aws sts CLI call that I could put in my batch job's startup script before calling the main binary?
Or I could just attach the policy directly to the machine user. Generally that's not recommended from what I've read: you should have a layer between users and policies so when users change what they're doing you have indirection. But in this case maybe that's fine.
Or finally I could create a user group, attach the policy to the group, and add the machine user as a member of the group. Is that layer of indirection useful / an appropriate use of groups, especially if I'm already managing these policies with IaC? Most documentation recommends roles for the user-to-policy indirection, so I'm hesitant to use groups that way. However, that seems to be the expected approach for human users (glad for feedback on that too).
"Is it better to use AWS IAM User Group, or IAM Role for users to assume?" says a group would help manage permissions for multiple users (but so does Pulumi and I only have 1 or 2 machine users); and a role would help separate access rights from long-lived credentials but it seems like rotating the machine user's access key would have that benefit too without the extra assume-role step.
Let's assume we have a nice, little cloud account running simple workloads. We have two user types accessing this account:
System accounts to access specific resources (CI/CD, DB access, etc.) with very fine-grained permissions
Two or three user accounts to manage the cloud account and everything on it (a.k.a. admins) - with pretty much full access
To secure the user accounts I want to enforce multi-factor-authentication on a global level. On MS Azure the AAD admin can enforce MFA on a per-user-level (on https://admin.microsoft.com). That feels straight-forward to me.
On AWS this seems much more cumbersome:
The IAM user management view only provides MFA configuration options for the current user.
AWS suggests to enforce MFA on a per-policy basis (see AWS docs).
This Stackoverflow thread extends AWS' approach to create a BlockMostAccessUnlessSignedInWithMFA policy. But still: per-user MFA is managed in policies and the custom BlockMostAccessUnlessSignedInWithMFA policy feels like a workaround.
Is there a more straight-forward way to do this on AWS IAM User management?
If not, am I missing something why the Azure AD's approach cannot work on AWS?
Any idea is welcome
I'm totally new to AWS and learning about IAM. I was wondering if there is a way around for an IAM user to check what all permission he/she have? Like as a root user, I created a group of IAM users where they were only allowed to use S3 service but once I logged in as an IAM user, it was showing that I have access to other AWS services as well like running EC2 instances, etc which I reckon shouldn't be the case. Thanks!
No, it isn't possible to "show" which services you have access to use, because the policies can be quite complex (eg permission to access an S3 bucket, but only a particular sub-folder if coming from a given range of IP addresses).
You would need to look the the IAM Policies attached to the IAM User, plus the policies on any IAM Groups they are in. Then, some services like Amazon S3 have additional permissions such as Bucket Policies.
In addition, AWS Organizations can limit the permissions of all users within an AWS Account, so even if a user appears to be granted certain permissions, they might not actually be available for use.
In many situations, you'll only know if you can do something by actually trying it. For example, you might have Read Only permissions, which means you can see resources in the AWS Console, but you would receive an error when you try to change things.
All services are available in the AWS Console, but various parts of the console will only work if you have adequate permission.
Note that there's IAM Policy Simulator from AWS. You can select a service and check if a given user has access to any given action (or all actions relevant to a service)
I would like to write a policy for a new IAM user so that he can have a full access to AWS Services such as EC2, RDS, Cloud Front, S3, etc. However he should be only able to view (describe) and manage the instances/services that he launches. He can't see other existing/future instances/services created by other users.
This case happens in a company that wants to outsource some projects to an outsourced company. So the new IAM user is for giving access to the outsourced company to setup the staging & production environments in AWS that belongs to the company. How can I achieve this?
Thanks.
Best Regards,
Mark
AFAICT there are no conditions on creator.
One obvious alternative is having a separated dependent and linked account with consolidated billing. You can find some detail in the third scenario of this paper
https://media.amazonwebservices.com/AWS_Setting_Up_Multiuser_Environments_Education.pdf
[...] an administrator creates separate AWS accounts for each user who
needs a new AWS account. These accounts can optionally be linked
together and a single AWS account can be designated as the paying
account using consolidated billing, which provides a single bill for
multiple AWS accounts. The administrator then creates an IAM user in
each AWS account and applies an access control policy to each user.
Users are given access to the IAM user within their AWS account, but
do not have access to the root credentials of the AWS account.
Users can log into the AWS Management Console with their IAM
credentials and then they can launch and access different AWS
services, subject to the access control policies applied to their
account. Users have direct control over the access credentials for
their resources and they can also share these resources with other
users as necessary.
I have an Amazon Web Services account which will be used to host the backed of an app. The backend uses PHP/MySQL and will most likely use an EC2 instance and RDS. I have my own account which has access to everything. I need to create an account for a developer to put the backend on AWS but I don't want them to have access to anything except what they need. I know how to create IAM users and Groups but I don't know which permissions to grant the developer. Under Select Policy Template there is a Power User template, is that good for a developer? Has anyone done this before?
The Power User Access template in AWS Identity and Access Management (IAM) grants permission to do ANYTHING except using IAM. A user with this permission can view, create or remove any resources in your AWS account, but they could not create new users or modify any user permissions.
It is recommended that you only give people the least amount of privilege required to use AWS, so that they do not intentional nor accidentally do something unwanted. However, if you do not have enough knowledge of AWS to know what functionality is required, you will most likely need to trust the developer to configure the system for your needs.
A few tips:
Only give them access via an IAM User -- never give them your root credentials
If you don't know what permissions are required, then "Power User" is at least safer than "Administrator" since they cannot edit IAM settings
When they have completed their work, revoke their access so they cannot create any more AWS resources
Determine whether you also wish to revoke access to the EC2 instances (you'll have to do this on the instances themselves)
You may need to define some roles that will be used with Amazon EC2 -- these are defined in IAM, so the developer will not have permission to create the roles himself
Ask the developer for documentation of what he has deployed
Turn on Detailed Billing to identify what AWS charges you are receiving and check them against the documentation
Turn on CloudTrail to activate auditing of your account (it is activated per-region)
Alternatively, you could do all the AWS configuration (launching an EC2 instance, creating the database) and only let the developer login to the EC2 instance itself. That way, they would not need access to your AWS account.