Policies are an important part of how UpGuard works, but in large implementations, policy bloat can make managing different groups of devices unwieldy. To combat this, UpGuard has implemented policy variables and variable override options in version 2.29 to allow people to better use a single policy across multiple groups. Out-of-the-box policies don’t always offer the necessary flexibility to adjust to real environments, but with UpGuard’s policy variables and overrides, administrators can adjust their expected configurations to apply to multiple systems or environments, taking into account their differences, and allowing them to focus on maintaining the configurations they care about.
How does it work?
Policy variables, much like environment variables, create a single location for varying configurations, such as a hostname or target database. When these change, instead of combing the policy for every instance, the variable can simply be changed and take effect wherever it has been applied.
Variable overrides allow multiple options for a configuration item depending on where that item lives. For example, rather than having two separate policies for development and production environments, the same policy can be applied to both, with policy variables stating that within the development environment, servers should be pointing to DEV, while in production, they should be pointing to PROD.
Won’t this just replace policy bloat with variable bloat?
Policy variables and overrides are not meant to supplant good IT practices, or endlessly patch up incoherent systems. Once UpGuard has helped an organization reach a baseline level of IT integrity, this feature allows them to implement pinpoint policies for the most critical items in their systems, making it easy to spot changes that violate the expected configuration.
Why does this matter?
The point of policies is to ensure that nodes and environments meet the expected configuration settings. In the case where we want a development and production environment to be identical, we’re better off using the same policy. Then we only have one place to check and change our expected configurations, while the policy variables will ensure that the differences between the environments are registered as well, preventing a web server in production from accidentally pointing at DEV for its data. This helps prevent misconfigurations by ensuring that nodes, groups and whole environments are held to the same standards, even when they deviate slightly.
This creates a proactive failsafe for configuration drift and unplanned change, allowing organizations to quickly respond to potential vulnerabilities before they are exploited. Resiliency like this reduces the likelihood of costly outages and breaches and provides visibility into the inner workings of a complex IT environment, making configuration management a simple task at a large scale.
Our goal at UpGuard is to provide organizations with a mechanism by which they can trust their IT environment. Policy variables and variable override are further steps toward that goal, making it easier and more efficient to create policies that control important configurations and minimize noise.
It's hard to understate how valuable automated testing can be. Policies are now coupled more tightly with node scans, giving you one interface to see exactly how a node is configured, how it's changing, and how compliant it is with your operational or security standards.
Read Article >
In our previous piece, 10 Essential Steps for Configuring a New Server, we walked through some of the best practices to follow when setting up a new Linux server. But how can you tell if your server is setup correctly?
Read Article >
One of the best out-of-the-box features of UpGuard is the ability to build a policy from one configuration and apply that policy to other nodes that should match it. This gives you instant visibility of the differences in configuration between systems.
Read Article >