A large company uses AWS CodeCommit to manage its source code.
There are over a hundred of repositories and many teams are working on different projects.
As a DevOps engineer, you need to allocate suitable access to different users.
For example, development team should not access the repositories that contain sensitive data.
How should you manage this?
Click on the arrows to vote for the correct answer
A. B. C. D.Correct Answer - A.
In July 2019, CodeCommit has a new feature to support adding tags in its repositories.
For details refer to https://aws.amazon.com/about-aws/whats-new/2019/07/aws-codecommit-now-supports-resource-tagging/.
Option A is CORRECT: Because with tags, an IAM policy can be easily configured to control the access.
For example:
{
"Version": "2012-10-17",
"Statement" : [
{
"Effect" : "Deny",
"Action" : "codecommit:*"
"Resource" : "*",
"Condition" : {
"StringEquals" : "aws:ResourceTag/Department": "BigData"
}
}
]
}
Option B is incorrect: Because there is no CodeCommit policy.
In this case, IAM policy should be used.
Option C is incorrect: Although Git tag is supported in CodeCommit, in this scenario, tags of repositories should be used instead of Git tags.
Option D is incorrect: The company owns over a hundred of repositories.
It is inappropriate and inefficient to create an IAM policy per IAM user based on repository names.
When managing access to AWS CodeCommit repositories, it's essential to ensure that each team and user has appropriate access to perform their duties without being able to access sensitive data.
Option A: Tag repositories in AWS CodeCommit. Create policies in IAM that allow or deny actions on repositories based on the tags associated with repositories.
This option is suitable for managing access to repositories based on the repository's tags. You can create a policy in IAM that allows or denies actions on repositories based on the tags associated with the repositories. For example, you can create a tag for repositories that contain sensitive data and create a policy that denies access to users or groups that don't need to access these repositories.
Option B: In AWS CodeCommit console, create CodeCommit policies to IAM groups that allow or deny actions on repositories.
This option is suitable for managing access to repositories based on IAM groups. You can create a policy in CodeCommit console that allows or denies actions on repositories based on the IAM group to which the user belongs. For example, you can create an IAM group for the development team and a policy that allows them to access only the repositories they need to work on.
Option C: Configure Git tags in AWS CodeCommit repositories. Create policies in IAM that allow or deny actions on repositories based on the Git tags.
This option is similar to option A, but it uses Git tags instead of repository tags. You can create a Git tag for repositories that contain sensitive data and create a policy in IAM that denies access to users or groups that don't need to access these repositories.
Option D: In IAM, for each IAM user, add an IAM policy that allows or denies actions on repositories based on repository names.
This option is suitable for managing access to repositories based on the user's IAM policy. You can create a policy in IAM that allows or denies actions on repositories based on the repository names. For example, you can create a policy that allows a user to access only specific repositories based on their role or project.
In conclusion, option A or B would be the most suitable options for managing access to repositories in a large company, with many repositories and teams. These options allow you to create policies based on tags or groups, which provide a more scalable and flexible approach to managing access control. Option C and D are also valid, but they are less flexible and harder to maintain as the number of repositories and users grows.