DevOps Best Practice : Limit access to Main branch in CodeCommit

2022.11.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

In SDLC, usually main or prod branches are the working version of the code and we really want to protect them from accidental merges or merge changes to those branches.

As a DevOps engineer limiting access to the working version of the code is an important best practice as without this we won't be able to have code reviews, or the worst code will break.

This article talks about the best practice to use branches and enforcing this best practice using IAM with CodeCommit.

Do check out the DevOps perspective for this Best Practice

Why do we need to reinforce the use of branches?

  • In the usual SDLC, main branches are the working version of the code which means the main branch code is the version which can be deployed in production. The code which is pushed in the working version needs to be free of bugs, thoroughly reviewed and tested as we don't want bugs to be pushed into the production code even by mistake. Having said that, mistakes happen, and it is natural to make them.
  • Here comes the concept of branches, where a particular feature or bug is fixed into its separate branch and once it is finalised, a Pull Request, sometimes called Merge Request ( in GITLAB world ) is created and other members in the project will review and upon review if its looks good senior developers tend to merge them in the production version which is the main branch ( can be prod branch depending on the project)
  • As a best practice, we want to ensure that nobody except the senior developers is able to merge feature branches into production code.

Create an IAM user

  • In this step will create an IAM user and add to a group with admin permissions.

As junior dev try to push a commit to the main branch

  • Since there is enforcement of best practice I am able to push to the main branch directly. ( This is a serious problem)

Enforcing Best Practice

Create a group for junior devs

  • As mentioned earlier, to enforce the use of branches we use IAM.
  • First, we will create a group for junior-devs ( for easier management) and then attach a policy to limit access.

  • Create IAM policy and attach to the junior-devs group

  • This policy applies to all regions, all accounts and all repositories ( the user of wildcard "*")

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "codecommit:GitPush",
                "codecommit:DeleteBranch",
                "codecommit:PutFile",
                "codecommit:MergeBranchesByFastForward",
                "codecommit:MergeBranchesBySquash",
                "codecommit:MergeBranchesByThreeWay",
                "codecommit:MergePullRequestByFastForward",
                "codecommit:MergePullRequestBySquash",
                "codecommit:MergePullRequestByThreeWay"
            ],
            "Resource": "arn:aws:codecommit:*:*:*",
            "Condition": {
                "StringEqualsIfExists": {
                    "codecommit:References": [
                        "refs/heads/main"
                    ]
                },
                "Null": {
                    "codecommit:References": "false"
                }
            }
        }
    ]
}

Note:- Our IAM user is attached to 2 groups one which gives admin access and another group i.e junior-devs which explicitly denies the access. This is how IAM policy works if there is an explicit Deny, deny will be taken into effect.

Try to push a commit to the main branch

Try to push a commit to the feature branch

DevOps Perspective

  • We want to separate junior developers from senior developers and definitely want to review code commits from junior developers and avoid accident commits from them.
  • Sometimes we want that senior developers or product managers should have the right to merge into main or production, this not improves security but also code quality too.

In this blog, we saw how a simple DevOps best practice can improve code quality and avoid bugs in the production code.

Till then, Happy Learning!