Skip to content

Git workflow for rules creation

Jump to bottom
Vitalii Kanivets edited this page Jun 23, 2023 · 5 revisions

Table of Contents

  1. ⚠️ Git branching strategy
  2. ⚠️ Git workflow for rules creation
  3. Repository layout for static rules

Git branching strategy

image

  1. The main development is done in the feature branches.
    1. One feature branch should contain one new rule.
    2. Or you can use one feature branch, if you update a bunch of files at once, based on the same common characteristic
  2. Features are merged into the main branch (after all tests in Github CI/CD pipeline have successfully passed).

Git workflow for rules creation

When you have a ⚠️ (Issue template) ticket assigned for you to create a new rule, you should follow the next steps:

  1. Fork and clone the repository of the cloud stream and navigate to its folder.

    git clone https://github.com/epam/ecc-azure-rulepack.git
cd ecc-azure-rulepack

  2. Checkout to a main branch, and from this branch create a new one for a new rule.
    The new branch should have the following name format: feature/<rule_name>.
    For instance, a new branch should be created like this:

    git switch main
git switch -c "feature/ecc-azure-010-policy_name"

  3. Now you can start working on a rule.
    a. Create a file <policy_name>.yml for future rule in policies/ folder. How to name a file you can find here - Rule file name convention
    b. Create in terraform/<policy_name>/  green, red, and iam folders.
    c. Create placebo-green and placebo-red folders in tests/<policy_name>/.
    d. Create <policy_number>-policy.json file in terraform/<policy_name>/iam/ with minimum required permissions for a user to run Custodian policy.
    e. Create red_policy_test.py in tests/<policy_name>/.
    f. (Optional) Create green_policy_test.py in tests/<policy_name>/ in case rule requires it.

    policy_name=<policy_name>
policy_number=<policy_index_number>

touch policies/$policy_name.yml
mkdir -p terraform/$policy_name/{green,red,iam}
mkdir -p tests/$policy_name/{placebo-green,placebo-red}
touch terraform/$policy_name/iam/$policy_number-policy.json
touch tests/$policy_name/red_policy_test.py
    Click here to expand for example... 
    touch policies/ecc-azure-002-cis_iam_owner_roles.yml
mkdir -p terraform/ecc-azure-002-cis_iam_owner_roles/{green,red,iam}
mkdir -p tests/ecc-azure-002-cis_iam_owner_roles/{placebo-green,lacebo-red}
touch terraform/ecc-azure-002-cis_iam_owner_roles/iam/383-policy.json
touch tests/ecc-azure-002-cis_iam_owner_roles/red_policy_test.py

  4. When you've finished with a rule, execute git status to check that all necessary files are ready, and you accidentally didn't edit unnecessary files.

  5. Now, you can stage, commit and push your changes.
    The commit message should consist of the full ticket name enclosed in square brackets and phrase: "Added static policy, terraform and test for <rule_name>", eg. feature<rule_name>. This phrase can vary based on changes you've made.

    git add .
git commit -m"feature <rule_name>"
git push -u origin feature/<rule_name>

    ℹ️ Note: To avoid merge conflicts, it's highly recommended before pushing changes to a remote branch, switch to a develop branch, pull changes, switch back to your working branch and merge develop into your branch.

    git switch main
git pull
git switch feature/<rule_name>
git merge main

  6. Open Git repository in a Web-browser and create a pull request into main branch.

    • For title enter your branch name: feature/<rule_name>.
    • Select an Assignee. It must be someone from your cloud stream or if it isn't possible, assign a pull request (PR) to someone with a sufficient level of competence in your cloud.
    • In "Pull options", check both box "Delete source branch when the pull request is accepted." and "Squash commits when the pull request is accepted.".
    • Navigate to the "Changes" tab, to check your changes again that everything is correct.
    • Click "Create pull request".

  7. ⚠️ After you have created PR, you should move your ticket to "In review" state.

ℹ️ Note: If you pushed a branch to a remote repository, but after sometime you do not need it anymore, delete it from there. Do not keep unnecessary branches in a remote repository, keep it only if you need it in the future.

⚠️ warning: Under no circumstances should you commit and push secret keys, credentials, or any kind of secret information to a remote repository.

Repository layout for static rules

The layout represents a base folder and file structure for repositories with static rules. This structure may vary slightly from cloud to cloud, but in most cases, you need to adhere to it.

  • ⚠️ iam - contains JSON files (for ARM and Azure CLI) to create a custom role with minimal permissions (read-only) in Azure Subscription that is able to run all Cloud Custodian rules in the repository. For more information: https://docs.microsoft.com/en-us/azure/role-based-access-control/overview.
  • policies - contains rules in .yml format. Check our naming convention - Rules name convention.
  • terraform - contains terraform scripts for each rule in the repository. Check how to write terraform scripts - Terraform - Guide.
  • terraform//iam - contains JSON file with permissions for creating a custom role with minimal permissions that is able to run a specific Cloud Custodian rule in the repository.
  • tests - (only AWS and GCP) contains the python test file red_policy_test.py and folders with records of green and red infrastructure in json files. In some rare cases, it may contain the green_policy_test.py test file.
  • CHANGELOG.md and version - contains information about recent updates in the repository. It is updated once a week at the end of the sprint.

image

Custodian info

Documentation

Clone this wiki locally