I work on the project that is entirely stored and run on AWS. I need to add a few software consultants to my AWS CodeCommit. All I want them to do is to be able to work on a few repositories at that's it. I don't even want to give them power to create/delete repositories.
What is the best strategy to create such users, only for CodeCommit, so I don't give them too much power?
Should I create a group for them?
Thanks for help
EDIT: When creating the user It looks like I have to pick between "Programmatic access" and "AWS Management Console access" - both sounds powerful
Granting programatic and/or console access isn't really saying a whole lot. Neither of those things give a user the ability to do much of anything. The key is in the permissions you grant them. In your case you should set up a group for these people and grant permissions to the group. If the users will only be using CodeCommit via git then you can make their permissions pretty limited. You may want to grant them console access to manage their own keys, but that would be about it. Here are some resources that will help you understand the permissions to grant.
CodeCommit Permissions
Using IAM with CodeCommit: Git Credentials, SSH Keys, and AWS Access Keys
Related
My developer has created an EC2 instance on AWS and I want to be able to access it via my own dashboard.
What I did is:
As a root user, I created an IAM account for me and him and assigned us both to a group named PowerUsers
I created an Organizational Unit and added his account to it
When he goes to his EC2 dashboard, he sees his created instances. But when I go to my EC2 dashboard, I see nothing. We both selected the correct region.
I hope someone can help us out here, I can't seem to get any wiser from the AWS documentation.
tl;dr there is a difference between visual access and technical access. Technical is possible, via IAM roles and permissions, etc. Visual access is not possible, not in the AWS console from a different account.
Generally you do not see resources from other accounts that you have access to. That is simply not how AWS / IAM or basically any complex permission system works.
Same thing for S3 buckets, you cannot see S3 buckets you have access to in your S3 console, not those that are public to everyone and not those that you have explicitly been granted permission to. You only ever see the buckets that you / your account actually own(s).
The reason for that from a technical perspective is really simple: AWS simply does not know which buckets / EC2 instance you can access. It knows your permissions and if you want to access a specific resource AWS can check if the permissions let you access it but not the other way around.
IAM has permission that can grant permissions based on IP, time of day, VPC, etc. That makes it impossible and not really meaningful to display what you can access now because in 10 second or from a different network it might be that you cannot see it at all.
Let me tell you from personal experience and currently building one myself: If you build a permission system it is built to answer "can I do X" but listing all X is a VERY different story, IAM cannot answer it and I have not come across a permission system that can answer it while at the same time having a complex permission structure AND being efficient. Seems like you cannot have efficiency, complexity and reverse lookup / list at the same time.
Note that you still have access to the resource. E.g. when manipulating the browser URL to directly access the resource you can view it even though you are not logged into the owning account but at that point you are asking "can I do X" (X = "view resource") and that can be easily answered. You only cannot list the resources.
Second note: some of the listed resources you see and that your account owns you still cannot access because there might be an explicit IAM Deny policy for your current role in place that only takes effect when interacting with the resource.
Following are some options;
Better way is to use, Cross-Account Access using switch roles and also refer this
Bit tricky way using Python sign-in script.
I am trying to understand why you need IAM "roles" to access a resource in a different IAM account, and why AWS can't just do the same thing with IAM groups.
Whenever I ask people this question the conversation just seems to go in circles:
Them: "To grant access to a resource to users in another IAM account, you have to give them permission to assume an IAM role, and then grant that IAM role access to your resource."
Me: "I understand that, but why can't you just create an IAM group that can access that resource, and then add those users from the other account to your IAM group?"
Them: "You can't add users from another AWS account to an IAM group in your account."
Me: "I understand that too, but why does AWS only let you do cross-account permissions like that by using roles? Why wouldn't it make just as much sense for AWS to let you create an IAM group and then let you add IAM users from other accounts into that group?"
There's probably some simple one-sentence piece of information that explains why it has to be this way, and once someone tells you, it all makes sense, but it's not in the documentation and I don't know what it is. What is it?
I would say security is main reason. IAM roles provide only temporary credentials. Using such credentials whenever possible is good practice for security reasons.
Off course you can also create IAM user in your account, and give the associated access keys to people form the other account. And sometimes this is preferred, e.g. to enable read access only to some resources. But the issue is that IAM user credentials are permanent, unless manually disabled or deleted. For security reasons giving away permanent credentials to your account is not a recommended practice.
From docs:
We recommend using this approach to enforce the principle of least privilege. That means restricting the use of elevated permissions to only those times when they are needed for specific tasks. With roles you can help prevent accidental changes to sensitive environments, especially if you combine them with auditing to help ensure that roles are only used when needed.
The one-sentence answer is that Amazon chose to do it that way.
From an operational perspective, it simplifies life considerably if you associate an access key with an account. The alternative is to specify an account separately with every request.
From an organization management perspective, trees are easier to understand than forests. What I mean by that is that everything branches off the account's IAM root. If you allow arbitrary users across the AWS universe to have access to arbitrary resources within arbitrary accounts, you end up with a management nightmare.
As a sidebar to that last comment, the early AWS services had resource-based policies. These are now discouraged in favor of identity-based policies, and newer services don't have resource policies.
Lastly, from a security perspective, a multi-tenant environment is a lot easier to control if you establish a hard wall around each tenant.
I work as a contractor for a large enterprise company and I was assigned to a new project recently for which we need to request resources on AWS. For our project we will need access to EC2 and RDS.
I am not very familiar with AWS, so my question is: will it be possible to get access to AWS Web Console for our team with limited services (access only to EC2 and RDS in our case)? How much work is needed to provide such access (to set up IAM etc)?
I am a bit concerned that I will not get access to AWS Web Console, because I was asked if I needed a sudo user for a VM. It was frustrating for me to hear such question, because I will need several VMs rather than one.
By default, IAM Users have no access to services. In such a situation, they can access the AWS management console, but there will be many error messages about not having access to information, nor the ability to perform actions.
Once an IAM User is granted the necessary permissions, the console will start working better for them. However, it an be difficult to determine exactly which permissions they require to fully use the console. For example, to use the EC2 console, the user would require ec2:DescribeInstances, which allows them to view details about all EC2 instances. This might not be desirable in your situation, since they might not want these users to see such a list.
Then comes the ability to perform actions on services, such as launching an EC2 instance. This requires the ec2:RunInstances permission, but also other related permissions to gain access to security groups, roles and networking configuration.
Bottom line: Yes, you will be able to access the AWS management console. However, your ability to view or do things will be limited by the permissions you are provided.
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,
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.