Skip to content

Guardian Classic

Overview 5 min read View Markdown

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.

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. 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.

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:

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.

Organising nodes#

Once the architecture is in place, organise your nodes. They live under Inventory > Monitored: see Monitored Nodes.

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.

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. 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, 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.

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.

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.

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?

Scheduled scans#

Schedule scans of a node, node group or environment with the Scan job type.

Scan results#

A scan is a snapshot of a node at a point in time, shown on Node Scan Results 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 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.

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.

Scan options#

Add what matters to you beyond the standard scan, such as particular files or directories, for a node group. See Scan Options.

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.

Optional features#

You don't need these to start, but they're worth knowing about.