We are planning to use AWS codecommit in our organisation.
Our scenario is,we have a IAM user named "codeAdmin", who can create repositories.
My question is how to handle the developers in the AWS codecommit. We have the following scenarios in consideration
for every developer create a new IAM account (added under the required group) and then provide access to the required codecommit repositories.
This way,if we have 30 developers,we need to create 30 IAM users.
or to give each developer the acccessKey and accessId of a single IAM developer account.
In this way,if we have 30 developers, we need to create only 1 IAM user and share the accessKeys/Ids to all.
Which approach from the above is best suited? Or is there any other best practices to be followed?.
Create separate iam user for each user is better.
First, different users may have different permissions based on their experience and position. For example, maybe you only want admin user have the ability to delete the repository.
Second, using different users can help your team distinguish which developers create a pull request, which developers comments on the pull request. If 30 developers share the same iam user, you won't know who make the comments, create pull request, merge the pull request because they are always the same user.
Amazon's best practice is to create separate account for each user. There are many benefits to this starting from permissions based on user's experience/position to (most probably the most important) traceability. If you only have 1 account and somebody messes things up (hopefully won't happen) you have no idea who it was and what was the mistaken driven by.
You can read up a bit on this :https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
Best regards!
Related
I need a best practice how to automate listing of all users at once under AWS organization multi accounts using AWS-CLI with any script?
I have tried all possible AWS CLI commands but they are all for manual steps and for individually listing users. Also, I tried to get credentilas report for all accounts, it didnt work for all, I again had to go with manually for individual account to get credential report. We have more then 300 accnts under AWS-organization so I want to automate this task, not manually
I’m not aware of a tool that can accomplish this (but that doesn’t mean that it doesn’t exist).
That being said, I would recommend a different approach to user management across a multi-account organisation:
Create exactly one account where all user accounts are managed and into which users log in.
Allow usage of other accounts only through assuming roles.
Disallow creating users in other accounts via SCP.
I understand that you already have an existing organisation with lots of accounts and probably even more users. Setting this up would probably be a very painful activity; especially if users are used for technical purposes (e.g. deployments) as well. But it might be worth the effort as you will have a much easier user management in the future.
I am new to the AWS ecosystem, coming over from Firebase. I needed a step up in configuration, and especially permissions. This might be an obvious question, but I'm not sure how to reason about it...
My Problem
I am trying to build an app that will have dozens, perhaps around 100 different permissions to perform different actions. I plan on implementing these with IAM policies on AWS Cognito Identity pools, since a maximum of 25 attributes and 25 groups won't be enough for the number of distinct permissions that I will be dealing with. How could I go about letting the front-end UI know what permissions any given user has?
If, for example, I had all of the permissions listed in the attributes, then that would be easy; I would just check the user's JWT and read out the attributes and update the UI to hide the actions user's don't have access to. Same thing goes for groups. But I am not sure on how this could be done for IAM policies?
I am aware that an option would be to just query a backend endpoint when the user tries to perform an action, and if permission is denied, then warn the user...but that is, in my opinion, a terrible UX.
I can also imagine that you could have some kind of endpoint, let's call it getUserPermissions, where when you call, a lambda function retrieves the IAM policies, parses them, and returns some permissions' describing object back to the front end. But doing this feels awkward, and might lead to outdated permissions if one forgets to query the endpoint. Is this the best/only option?
Any tips would be much appreciated.
Please note I also purposefully didn't mention what front-end (web, native, etc.) or backend I am using, because I would like to know in the general case how this works
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
We are in the process of transferring what we currently have in our on-premises infrastructure to the cloud and taking advantage of what AWS has to offer. We are in the process of planning how we can make this process as smooth as possible, so one of the first things that came to mind was, What are the best possible solutions to implement what we currently have in our premises with users registered in AD and how we will be able to manage them, e.g. we create a new user in AD and automatically we can see that new user in our AWS environment so we don't have to manage them on premises as well as AWS and so they can sync?
The next question which I think the answer is Control Tower (and that's why I'm sending my question on this topic), but I would like to confirm and see if there are any other options out there that we might me missing.
As I said earlier, we are in the process of transferring our current on-site infrastructure to the cloud, so at this time we have three environments where we manage development: Development, Staging and Production. We thought of having each of them separated in their own AWS account so we can manage them individually but also we want a way to easy switch accounts between them and possibly get one consolidated bill for all of those three accounts but with the details in each account, and be able to easily make them communicate resources in one account to resources in another account. What would be the best solution for these challenges in AWS if someone can suggest best practices on these?
Thank you so much for your help!
For the AD connection, you can use the AWS AD Connector service. The official AWS blog has a tutorial: https://aws.amazon.com/blogs/security/how-to-connect-your-on-premises-active-directory-to-aws-using-ad-connector/
Billing for a multi-account organization is pretty straightforward, all sub-accounts pay through the root account so you won't have to worry about separation of billing.
Communicating between the environments (accounts), however, requires a bit more legwork. You can use a hub and spoke model and reach out to all environments from an individual environment, or, you can create trust relationships between roles and resources via IAM policy in different accounts and map them to one another.
I am trying to give temporary access to AWS console for a few users (for a limited time), and they should not be able to view any resources created by the other users. These are the possible methods I could find:
Creating an IAM user for each user and assigning IAM policies: This is a straightforward process, but would it be possible to define the policy in such a way that every user is completely isolated from each other? The user should be able to create any resource, but view and manage only his resource. After use, the IAM user can be deleted to revoke access for the user to the AWS console.
Creating an AWS account under the root account Organization: This would guarantee isolation, but deleting a managed AWS account is not straightforward and hence this method does not seem viable.
Can anyone help me with a possible solution?
Edit: I am trying to dynamically create accounts/users on demand. (Thanks for pointing it out #JamesKn)
I would get them each to sign up for AWS and then run consolidated billing http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html
That way they would be completely isolated but you would get one bill.