A consistent cloud tagging strategy is crucial for understanding the purpose and provenance of any given cloud resource. If you know what a resource is supposed to do, you’re in a much better position to assess its security, cost, ownership, and more. But when you maintain a large-scale environment, it becomes nearly impossible to manually manage tags via “ClickOps.” A better alternative is to transition to maintaining tags programmatically with infrastructure as code (IaC).

That’s why we created Yor, an open-source automated IaC tag and trace tool. Yor’s out-of-the-box tags make it easier to answer questions such as:

• What file and repository is a misconfigured cloud resource sourced from?
• What other misconfigs were introduced in a specific commit?
• Who is the last modifier for a specific file?
• Is there a drift between my code and cloud?

Also, by creating custom tag rules based on recent committers or environments and their corresponding teams or cost centers,  you can answer important questions such as:

• Who is paying for a specific resource? 
• What team maintains a specific resource? 

Even with automated tagging and custom tag rules, however, maintaining consistency in code can be challenging when you have an ever-changing infra across multiple teams hosted in various code repositories and with different coding standards.

Using Yor is the first step to adding and automating persistent tags across your IaC resources as Yor only enables defining tag rules using a YAML configuration that is specific to that repository. Maintaining separate rules files in each repository is doable for tracing a small number of repositories in a small number of cloud providers, but when you scale to multi-team, multi-repo, multi-cloud, multi-EVERYTHING, 😉  the need for centralized management will become obvious.

Introducing centralized tagging management

Bridgecrew’s new centralized IaC Tag Rule Manager enables you to enforce out-of-the-box and custom tag rules for Terraform and CloudFormation across multiple repositories and organizations. It also enables you to manage tag rules over time to meet your environment’s changing needs.

To quickly reproduce and maintain tagging rules, you can enable, disable, edit, clone, and delete a tag rule.

• Enabling a rule will trigger the creation of an automatic pull request whenever a rule is matched.
• Disabling a rule will turn off automatic pull request creation for resources that answer the tag rule. Disabled rules are saved and can be enabled in the future.
• Editing a rule lets you make changes to existing tag rules across resources quickly.
• Cloning a rule will enable the creation of a copy that can be modified to a new purpose.
• Deleting a rule is removing it from the rules table. Deleting or disabling a rule will not undo code changes made by automated pull requests.

Learn more about centralized tagging management in the video below and keep reading for all the different ways you can surface and leverage tags in the Bridgecrew platform.

Cloud tagging use cases in Bridgecrew

Having persistent tag rules is crucial for addressing misconfigurations and maintaining GitOps. Here are six questions that tags can help you answer, made easier by Bridgecrew’s centralized tag management.

What file and repository is a misconfiguration sourced from?

When a misconfiguration has been identified in your runtime environment, you need to track down the code that caused the issue in the first place. You can drastically improve your response time if you have a mechanism to trace runtime resources to the specific lines of code that configured them.

It will also help keep your production environment in sync with development declarations. The image below shows Bridgecrew tracing a runtime AWS resource ARN to its source repository, file path, and IaC resource:

Is there a corresponding runtime misconfiguration?

In addition to understanding the origin of a misconfiguration, it’s also important to understand its impact on your runtime environment. That’s why being able to trace resources from code to cloud is crucial to knowing where misconfigurations appear downstream.

In Bridgecrew, the tracing of resources from code to cloud is done by adding unique identifying tags called yor_trace that are persisted from code to cloud. When misconfigurations in code correspond with misconfigurations in runtime, the Bridgecrew platform highlights them (as seen below), helping to prioritize fixes, understand risk, and take the best course of action:

 

What other misconfigs were introduced in a specific commit?

Git commits index the set of changes an update to code will make. And one commit—no matter how small—may cause several new policy violations.

Seeing grouped violations introduced by a commit makes it easier to review and fix misconfigurations in small, consumable chunks. In this way, focusing remediation efforts based on specific commits (filtered by tags) is more efficient than looking at all misconfigurations across an entire repo. As shown below, you can filter issues in the Incidents screen by specific git commits:

Who is the last modifier for that file?

When things break or a security incident occurs, responses need to be quick. Sometimes, that leads to infra changes that aren’t well-documented or acknowledged by all stakeholders. But product engineering isn’t a one-person job; it requires teamwork. There might be a justified reason to configure a resource in a chosen state.

Being able to easily view who modified the relevant code enables better collaboration and communication when questions arise. It also helps with sharing and documenting institutional knowledge on the reason for the configured attribute. That way, future changes to the resource will encourage a conversation, and team members will not step on each other toes overriding each other’s configuration changes. When inspecting a resource in the Bridgecrew platform as shown below, you can see the git_last_modified_by tag:

Is there a drift between my code and cloud?

Changes made outside of IaC can be accidental or intentional. Those changes, known as cloud drift, can happen in response to time-sensitive production incidents or hasty remediations. If drift isn’t addressed by aligning cloud resources with original templates, it can complicate future deployment attempts, leading to reappearing misconfigurations or even outages.

Bridgecrew highlights such drift, powered by the yor_trace tag. Below, you can see in an S3 resource block in Terraform has drifted from its corresponding AWS instance:

You can take corrective action by detecting unmanaged configuration changes and syncing the code to reflect your production state by triggering a drift detection pull request.

What team maintains a resource and who pays for it?

To go beyond Yor’s out-of-the-box tags and answer questions dependent on your team’s unique structure and definitions, you will need to define new tagging rules that will map other data points. Bridgecrew’s IaC Tag Rule Manager makes that easier than ever.

For example, to answer “Who is paying for a specific resource?” you can create the following tag rule straight from the Bridgecrew platform:

The tag rule above will tag “PaloAltoNetoworks” as the default cost_center, but if my colleague Mike, who is on the Bridgecrew team is the git modifier, bridgecrew will be tagged as the cost_center and if Nimrod is the git modifier, acme will be tagged as the cost_center. Once enabled, this tagging rule will then apply to all resources within the selected repositories as a pull request:

···

With Bridgecrew’s tag automation and management capabilities, you get a consistent tagging framework in both code and cloud across multiple repositories and cloud providers. That consistency allows for greater collaboration and efficiency when investigating and fixing security issues and drift. Now, in addition to enabling continuous code to cloud security scanning, Bridgecrew is your centralized source of truth for tagging rules. Get started with our free 14-day trial.