I basically want them to have access to create/modify anything that they create, but not really able to modify/delete existing resources.
Or in some other way put them in their own bubble.
I actually got AWS certified associate in architecture, so should have some idea of whatever you say. I forgot most of what I learned for the test.
For now I made them a PowerUser.
Thanks!
Currently, there is no elegant solution for this in a shared AWS account. If you need this level of separation, creating a sub-account is the way to achieve this.
but not really able to modify/delete existing resources.
You can use resource and/or identity tags and then allow or deny actions based on tags. E. g. you can deny any action for tags env=production. See https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html
You can create simple or more complex Tag Policies to enforce consistent resource tagging.
And there is a way to enforce the owner identity in a tag, so you can allocate costs. (just search the inet for it if you want)
Or in some other way put them in their own bubble.
To keep it simple the development is usually done on a separate (organizational) account and the developers shoup deliver a deployment script/procedure to deploy the resources to other stages (cloudformation, terraform,..) .
. i started by granting PowerUser. then SystemAdministrator
This is something... the developers should not need. If so, you could implement an SCP (Service control policies) to limit even the admin users (deny disabling the cloudtrail, access to sensitive kms, modify roles with certain tags,.. .)
Related
I want to create a role for a Lambda function that allows it to create/update/delete any resource, as long as that resource was also created by it. For example, it should be able to create an SQS queue and do anything with it, but it should not have access to any other SQS queues from that AWS account.
Can this be achieved using IAM policies?
I've tried to use resourceTag and requestTag conditions for this, allowing the role to create or modify a resource only if is tagged with a specific value. Unfortunately, a lot of AWS services do not support authorization based on tags.
Are there other options for achieving this?
You could create IAM policies that only allow a user to create, update, delete resources that have a particular naming scheme. For example, you could set the policy's resource arn to have "/username*". The user would only be able to create resources that start with their username and effect those resources. They wouldn't be able to effect resources created that started with another users name and vice-versa.
It is very hard to do in practice. You would have to combine the tags that you already mentioned, along with permission boundaries.
I think the best way to achieve this is to give you application its own dedicated AWS account, so that you can scope its permissions to that account, and it doesn't have the ability to impact other applications.
Are there any ready templates for IAM policies for typical applications using CLI ?
I mean templates that give basic permissions to use tools that are reasonably safe so that they do not give permissions to too many things.
For example - it wants to have access to create resources with CloudFormation/Integrate Visual Studio Code, create/use Lambda/ApiGateway , run and disable instances ?
There are some managed policies provided in IAM for some common job roles.
However, security is hard. It's a matter of giving required permissions without giving into temptation to just give all (*) permissions for a service.
Netflix created tools to monitor what permissions are being by particular IAM Roles, and then automatically reduce permissions to only what is necessary.
See: Introducing Aardvark and Repokid - Netflix TechBlog
That would probably be overkill for your particular situation. All I can suggest is to start by only assigning permissions for services that are used. Then, for each service, think about the bad things that could happen by granting too much permission and then try to avoid that situation.
A common technique is to separate dev/test from production by putting them in different accounts. This way, production can be locked-down more than dev/test.
I'm looking for way to restrict deployment to production assuming I'm not using multiple accounts for dev and prod.
My use case would go as follow (I still not sure if this is possible, pls help me on that). I want to create multiple users into a same account but allow only one user/group to exec commands like sls deploy -s prod and maybe, allow only that user/group to be the only able to create sources name prod_{name}, for example, dynamo tables name prod_users.
Is this possible? or the only way to separate concern is thought the consolidate billing and multiple accounts?
Thanks!
By default, users don't have any privileges, so you have to explicitly allow them to do something on AWS.
Simplest way to do that is to go to IAM console and create group for users that are allowed to do what you require. After naming group, next step in IAM console is to attach policy to the group. In that step, you would choose CloudFormation, EC2, RDS, ElasticBeanstalk, and whatever services you want them to access. For each service, you can choose more granulary (read, access, admin, ...). You can either choose from AWS predesigned policies, or create one of your own, if it's so specific that it isn't covered by already existing policies.
I'd like to help you further (ie. tell you what policies to include), but for that I'd need to know specific types of users and services that you want covered.
Regards,
I have users that have been added by other admins in my AWS account. I am afraid that these users might get deleted by other people.
Is there a way to add a description to an IAM user?
I don't see any way to add description/tag when you create an IAM user. One suggestion is to create a IAM group for each admin and add the user to the admin's group when a user is created/added. You can have group(s) with no policy attached.
There is currently no way to add a description to a user. There are a number of better ways to solve your core issue however. Some of the IAM Best Practices specific to your use case include:
Use AWS Defined Policies to Assign Permissions Whenever Possible - AWS-managed policies are designed to support common tasks, such as deleting and creating users. Assign these policies to the users that need them.
Grant Least Privilege - Granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks. This is probably the most important factor in preventing users from being deleted accidentally.
Monitor Activity in Your AWS Account - You can use logging features in AWS to determine the actions users have taken in your account, including deletion of users either accidentally or on purpose. Two very useful tools you should be using in this regard include:
AWS CloudTrail - CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, including user deletions.
AWS Config – Provides detailed historical information about the configuration of your AWS resources, including your IAM users, groups, roles, and policies.
As you can see, utilising the built-in tools that AWS provides can assist you in preventing administrators from deleting users unnecessarily.
As a workaround, you can add a TAG to your user with its key named "DESCRIPTION" and put in the description as a value. Note that for the value, you are very limited to the characters you can use. For instance, you cannot use the apostrophe ('). But it is better than nothing.
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.