Using Yor for ownership mapping using YAML tag groups

YAML tag group overview

Cloud service providers allow developers to assign metadata to their cloud resources in the form of tags. Each tag is a simple label consisting of a customer-defined key and a value that can make it easier to manage, search for, and filter resources. 

There are no default tags, they can be used for anything, including categorizing resources by purpose, owner, team, environment, or other criteria. In addition, tags can be managed both proactively in infrastructure as code and in a runtime cloud environment. 

Yor is an open source tool that supports auto-tagging of infrastructure from code to cloud by adding metadata such as repository, commit and path, and the last modifier of the code based on git log data. You can expand those out-of-the-box (OOTB) tags into additional common tags such as Operation team, cost center, and environment.

This is how we use Yor to automate auto-configuration of those tags on our Terraform code:

YAML tag group overview

Each time you commit your IaC to a repository, Yor loads custom tag groups defined in `tag_groups.yaml` and applies those on your IaC.

Internally Yor will query git for metadata to include as tags and, as a next step, it will load tags from the YAML file and Go files (if provided) and will run the tailored tagging logic. 

Yor custom tag chart

Custom tags YAML schema explained

The Yor configuration file consists of a list of tag groups, where each tag group can contain tags with default values, conditional values, or values that rely on environment variables. In the following example, we’ve created two tag groups, grouping key-value pairs for the use cases of ownership and cost mapping.

  - name: ownership # map infrastructure to owner or owning team
      - name: env
          default: ${env:GIT_BRANCH} # environment name would be the name of the feature_branch
      - name: team_ownership
          default: sre # SRE are the default owning team of cloud resources
            - security_engineering:
                  git_modifiers: # security engineering team member's github handles
                    - rotemavni
                    - tronxd
                    - nimrodkor
            - platform_engineering:
                  git_modifiers: # platform engineering team member's github handles
                    - milkana
                    - nofar
            - application:
                    - schosterbarak
  - name: cost # map infrastructure cost center
      - name: cost_center
          default: third_parties # default cost center
            - bridgecrew:
                  git_org: # map cost centers by github orgs
                    - bridgecrewio

At Bridgecrew, we manage ownership over cloud infrastructure by teams that own those sets of microservices. Each team has a set of GitHub handles that can be mapped to it from the OOTB  tags of `git_modifiers` that Yor is adding. For example, you can see that the default team is “sre” and “rotemavni,” “tronxd,” and “nimrodkor” are on the “security_engineering” team. 

In addition, part of ownership is owning a feature branch or an environment allocated to feature branches used for demoing and collecting early feedback. On each pull request from a new feature branch, an environment gets provisioned. With this tag group YAML, the `environment` tag associated with those provisioned resources is set to the CI environment variable `GIT_BRANCH` which has the feature branch name. 

With this tag automatically added, any time someone views an environment, even with 100s of microservices, they will know exactly if it’s a feature branch environment or production. This saves DevOps teams time when understanding the severity of an issue. 

Another tag that we use is `cost_center`. Another use case might be mapping third-party-related infrastructure to different cost centers, such as Bridgecrew versus third-party cost centers. For example, suppose you manage the code stored in git in a similar structure, with Bridgecrew owned IaC and third party owned IaC. In that case, this mapping can easily be achieved by mapping the cost center by GitHub organization, where all resources modified by the ‘bridgecrew’ organization are mapped to the ‘bridgecrewio’ cost center and all other resources are allocated to ‘third_parties’. 

Explore misconfigured resources by owners using Bridgecrew

Now, let’s apply those tags in our CI pipeline. Yor will automatically add the ownership and cost_center tags auto-assigned in our org.

Screenshot of tags applied in CI pipeline

Now we can save time triaging and investigating issues by using tags like owning team on the Projects page:

projects page screenshot Now we can #tag_everything with the operational context required to run production software at scale. We’d love to get your feedback and questions in the #yor channel in the CodifiedSecurity Slack. If you enjoy Yor, give it a ⭐️ on GitHub!