--- title: "Guardian concepts" description: "The parts of Guardian, how they fit together, and the words the rest of these docs use." product: "Guardian" edition: "Classic" type: "overview" url: "https://docs.cloudhouse.com/guardian/classic/getting-started/concepts/" --- # Guardian concepts Guardian is built from a few parts: an appliance that does the processing, scanning services that reach your nodes, and the groups you organise those nodes into. This page explains each, in the order you'll meet them. To set Guardian up step by step, see [Get started with Guardian Classic](https://docs.cloudhouse.com/guardian/classic/getting-started/index.md). Applies to: `Guardian Classic` ## Architecture These are the parts you set up first. ### Appliance Your **Guardian instance** is the software that runs Guardian for you; the appliance is the machine it runs on. The appliance is where Guardian does its processing. Agents and Connection Managers collect jobs from it and send scan results back, and it stores those results in its database. It's either Cloudhouse-hosted or on your premises. On-premises, the appliance is a virtual machine in your VMware environment, called the [virtual Guardian appliance](https://docs.cloudhouse.com/guardian/classic/getting-started/appliance/virtual-guardian-appliance/index.md). It's a black box: only Guardian Support can sign in, which keeps the platform stable and keeps the work off your teams. A hosted appliance is run by Cloudhouse. ### Agent A service that runs on a node, runs that node's scan jobs locally, and sends the results to the appliance. See [Guardian Agent](https://docs.cloudhouse.com/guardian/classic/getting-started/agents/index.md). ### Connection Manager A stateless server that collects jobs from the appliance, scans nodes agentlessly and sends the results back. Every instance includes a default Linux Connection Manager, with nothing to set up, which scans any node that needs SSH. !!! tip With a small number of non-Windows nodes, the default Connection Manager can stand in for a Linux Connection Manager. For more than a hundred SSH nodes, install several Linux Connection Managers and put them in a group. You can also deploy two other types: - [Windows Connection Manager](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/windows/windows-connection-manager/index.md): WinRM and database (ODBC) scans, and Azure nodes. - [Linux Connection Manager](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/linux/linux-connection-manager/index.md): SSH scans of Linux servers and network devices, and every other cloud service. ### Node Anything Guardian scans: anything with an IP address, or a single cloud entity. A node is either **detected** or **monitored**, and you can attach node groups, policies and benchmarks to monitored nodes. See [Nodes](https://docs.cloudhouse.com/guardian/classic/getting-started/nodes/index.md). ## Organising nodes Once the architecture is in place, organise your nodes. They live under **Inventory** > **Monitored**: see [Monitored Nodes](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/monitored/index.md). ### Node groups Group nodes by device type, operating system, application or anything else that suits you: Windows, Linux, databases, IIS. Ignore lists, scan options and policies set on a group apply to every node in it, so a new node only needs to go into the right groups. A node can be in any number of groups. See [Node Groups](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/node-groups/node-groups/index.md). #### Static and dynamic node groups A static group holds exactly the nodes you put in it until you change it, which suits nodes that rarely change. A dynamic group has a [dynamic group query](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/node-groups/settings/dynamic-group-queries/index.md). Nodes that match the query join the group and nodes that stop matching leave it, so the group follows your estate as it changes. Static and dynamic groups can both use [node rules](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/node-groups/settings/node-rules/index.md), regular expressions that add matching nodes automatically. ### Environments The top level for organising nodes, usually matching your release stages (development, staging, production), though region, operating system or any other split works too. See [Environments](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/environments/environments/index.md). ### Connection Manager groups Groups of Connection Managers of the same type (Windows or Linux), organised by network topology, time zone or anything else. Each node is assigned to a group, and the group handles that node's scans and integration syncs. See [Connection Manager Groups](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/connection-manager-group/connection-manager-groups/index.md). ## Scans Regular scans let you track configuration over time and compare nodes. When something goes wrong, a node's scan history shows when its configuration changed. Scans run from the web application, the API or the job schedule: see [Scan Nodes](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/scan-options/scan-nodes/index.md). ### Scanning services Before you scan, choose how each node is reached: by an Agent, or agentlessly by a Connection Manager. See [Agent-based or agentless?](https://docs.cloudhouse.com/guardian/classic/getting-started/agent-based-or-agentless/index.md) ### Scheduled scans Schedule scans of a node, node group or environment with the [Scan job type](https://docs.cloudhouse.com/guardian/classic/control/job-schedule/job-types/scan-job-type/index.md). ### Scan results A scan is a snapshot of a node at a point in time, shown on [Node Scan Results](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/nodes/node-scan-results/index.md) with policy results, scheduled jobs and other scans alongside. Section : A built-in group of configuration items, such as **Users**, **EnvVars** or **ServiceKeys**. Sections vary by node type and can't be changed. Configuration item : One piece of configuration on a node: a file, a registry setting, a package version. Which items a scan collects depends on the node type and the [scan options](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/scan-options/scan-options/index.md) of the node's groups. Attribute : A property of a configuration item. A file has attributes such as permissions, checksum, contents, last modified time and owner. A policy can check attributes across a node group: see [Attribute Checks](https://docs.cloudhouse.com/guardian/classic/control/policies/build-custom-policy/index.md#attribute-checks). ### Configuration differencing Compare the scans of several nodes or node groups, filtered by scan date, differences or what they have in common, to find inconsistencies. See [Configuration Differencing](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/configuration-differencing/configuration-differencing/index.md). ### Scan options Add what matters to you beyond the standard scan, such as particular files or directories, for a node group. See [Scan Options](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/scan-options/scan-options/index.md). ## Benchmarks and policies A policy describes the configuration a system should have, and each scan is checked against it. Guardian has two kinds: **custom** policies, which you write for your own needs, and **public** policies from the Center for Internet Security (CIS), which Guardian calls benchmarks. ### Benchmarks **Control** > **Benchmarks** lists the CIS best-practice policies. Apply one to a node or node group to check it against the CIS recommendations. ### Policies **Control** > **Policies** lists every policy in your instance, custom and public. A policy might check that a set of roles and features is installed, or that certain environment variables are set; the checks run on every scan and pass or fail. A node group can carry several policies. !!! note Policies in the web application work slightly differently from the Policy API. See [Guardian API (V2) Policies](https://core-api.cloudhouse.com/#tag/Policies/operation/policiesNewV2). ## Optional features You don't need these to start, but they're worth knowing about. - [*Feature* **Variables** Placeholders for values you reuse.](https://docs.cloudhouse.com/guardian/classic/control/variables/variables/index.md) - [*Feature* **Real-time forwarder** Watch chosen file paths between scans.](https://docs.cloudhouse.com/guardian/classic/getting-started/real-time-forwarder/index.md) - [*Feature* **Tagging** Label a scan or policy version so it's easy to find.](https://docs.cloudhouse.com/guardian/classic/getting-started/tagging/index.md)