4 Configuration Management
Learn how configuration management establishes approved system states, controls and records changes, applies settings consistently, detects drift, and supports safe recovery.
Purpose and scope
Configuration management (CM) controls how system settings are defined, changed, recorded, and monitored. Its purpose is to keep systems consistent with approved requirements while preserving a traceable history of changes.
Configuration items may include servers, operating systems, applications, network devices, software, and their documentation.
Establishing configuration baselines
A is a documented, formally approved description of a system or component at a particular point in time. It provides a reference for building, updating, and checking the system. Baselines may describe approved software versions, settings, network connections, components, and operating procedures.
For example, a web-server baseline might specify its operating-system image, installed packages, listening ports, firewall rules, and logging settings. A baseline should identify what is controlled, the approved values, its version or date, and who approved it.
Update the baseline when approved changes alter the system, and retain prior versions for reference and audit. Store configuration records in an access-controlled location. Protect credentials and other secrets separately rather than embedding them in plain-text configuration files.
and
provides a repeatable path for managing changes:
Propose and record the change, its purpose, affected systems, and implementation plan.
Assess impact and risk, including security, availability, compatibility, and dependencies.
Review and approve the change according to organizational policy. Urgent changes may use an expedited process, but should still be documented and reviewed afterward.
Test the change in a suitable environment and prepare verification and steps.
Implement and verify the approved change, record the result, and update the baseline.
The process covers configuration changes such as firewall rules and software settings, not just equipment replacement. Changes should be reviewed, approved or rejected, implemented, documented, and monitored, with explicit consideration of security impact.
provides a history of configuration files and automation code. Each change should be attributable and explain what changed and why. Branches or reviews can help isolate and inspect proposed changes before they are merged into the approved version. For example, a network engineer can submit a firewall-rule change for review before applying the updated configuration to production.
When a change already shared with others needs to be undone, create a new change that reverses it rather than silently rewriting shared history. In Git, git revert creates a new commit that reverses an earlier commit, preserving the history of both the original change and its reversal.
Automation and drift detection
Configuration-management automation applies approved settings consistently across systems. Prefer repeatable, : running them again should leave a system in the same desired state rather than repeatedly introducing changes. Before deployment, validate automation and review its expected effects.
Ansible check mode simulates changes where supported, and diff mode can show before-and-after differences. These modes are useful checks, but they do not replace testing or approval. Diff output may expose sensitive values and should be handled accordingly.
occurs when a live system differs from its approved baseline, such as when someone changes a firewall rule directly on a device. Detect drift by comparing observed configurations with approved versions or policies on a defined schedule and after significant changes.
Investigate differences before correcting them: a difference may be unauthorized, an approved change not yet recorded, or an operational exception. Document the decision, restore the approved state or formally approve a new one, and update the baseline as appropriate. Maintaining and reviewing current baselines and monitoring change-control activities are part of this work.
Planning safe
A returns a system to a known-good configuration when a change causes unacceptable effects. A useful procedure identifies the previous approved version, who may authorize , the steps to restore it, how to verify recovery, and how to record the outcome. Keep tested copies of prior configurations and ensure they can be accessed during an incident.
is not always as simple as restoring a file. A change may alter data, depend on another system, or affect later changes; blindly restoring an old state could cause data loss or additional disruption. Test plans where practical, consider dependencies, and define when recovery requires a forward fix instead.
After , investigate the cause and update the change record and baseline. Safe recovery depends on retaining known-good configurations, having tested procedures, and accounting for dependencies and data effects.