Posture
Posture pillar — Compliance Posture, Configuration Posture, Health Posture and the rationale for consolidation under one navigation label.
The Posture pillar is a unified navigation label that groups three distinct view families — Compliance Posture, Configuration Posture, and Health Posture — under one sidebar entry. It exists because the underlying data is correlated (a server with low compliance posture often has low configuration posture and degraded health posture), and grouping the views together makes that correlation legible. Posture is used by site reliability engineers tracking fleet health, security leads reviewing compliance posture, and platform owners watching configuration drift across environments.
Note: The LinuxGuard Console is the canonical reference for screen-by-screen layout. This page describes the conceptual scope and integration points.
The Posture pillar is best understood as a navigation choice rather than a new data layer. The compliance data inside Compliance Posture is the same compliance data exposed by the Compliance Expansion pillar. The configuration data inside Configuration Posture is the same data exposed by Baselines. The health data inside Health Posture is the same operational telemetry exposed by Infrastructure. What Posture adds is the cross-cutting axis — the ability to ask "show me servers that are low on all three posture dimensions, ranked by total risk" — without navigating between three separate pillars to assemble the picture.
Naming rationale
A reasonable question for operators new to LinuxGuard is "why is there a Posture pillar at all, given Compliance Expansion, Baselines, and Infrastructure already exist?" The answer is consolidation versus separation: any sufficiently rich console either provides separate per-domain views (separation) or provides a cross-cutting summary view (consolidation). LinuxGuard provides both, deliberately.
Separation is what the per-domain pillars give you. A compliance analyst working a specific framework wants the Compliance Expansion pillar, not a generic posture view — the analyst needs framework-specific control mapping, per-control evidence, and per-suppression rationale. A platform engineer triaging a server's configuration drift wants Baselines, not Posture — they need the per-component drift event, the attribution, and the diff. The per-domain pillars are optimized for these focused workflows.
Consolidation is what Posture provides. A site reliability lead doing a fleet-wide review wants one view that shows compliance score, configuration drift, and health metrics side-by-side per server, not three separate views. A risk officer presenting fleet posture to leadership wants a single dashboard summarizing posture across all three dimensions. The Posture pillar is optimized for these cross-cutting workflows.
The trade-off this design accepts: a small amount of data duplication between the per-domain pillars and the Posture pillar (each metric is visible from at least two sidebar paths). The benefit: workflows that need cross-cutting visibility don't have to assemble it manually from three places.
Compliance Posture
Compliance Posture provides the cross-framework, per-server view of compliance scores. Where Compliance Expansion's frameworks browser is "drill into framework X and see how every server scores against it," Compliance Posture is "pick a server (or server set) and see how it scores against every enabled framework."
The Compliance Posture view is per-server-centric. Each row is one server; columns are framework scores (current, with a trend indicator vs the prior period). Servers with consistently low compliance posture across multiple frameworks surface at the top — these are the servers where compliance remediation effort has the highest cross-framework leverage.
A server's compliance posture is not a single number. It is a vector of per-framework scores. Posture rolls them up to a server-level "low / medium / high" categorical for ranking purposes, but the underlying detail (which controls are failing on which frameworks) is always one click away.
This view is the bridge between Compliance Expansion (framework-first) and Infrastructure (server-first). The compliance analyst lives in Compliance Expansion; the SRE lives in Infrastructure; the risk officer reviewing fleet posture lives in Compliance Posture.
Configuration Posture
Configuration Posture provides the cross-baseline, per-server view of configuration drift. Where Baselines is per-component (accounts, groups, SSH, SUDO categories each as their own surface), Configuration Posture is per-server: how many configurations on this server diverge from baseline, in which categories, and how recent are the deviations?
A configuration posture row includes:
Server
Fleet inventory
Baseline deviation count
Sum across all baseline categories enabled for this server
Most recent deviation
Latest baseline-deviation drift event on this server
Deviation categories
Which Baselines surfaces (accounts / groups / SSH / SUDO) the deviations span
Trend
Week-over-week change in deviation count
Configuration posture is the surface where an SRE answers "which of my servers have the most outstanding configuration drift?" The answer drives the order of the SRE's remediation queue.
Configuration posture is also the surface where the cross-correlation with compliance becomes visible. A server with high configuration deviation count typically also shows degraded compliance posture — because compliance frameworks include controls that are tightly coupled to the baselined configuration. Watching them move together (or, more usefully, watching when one moves and the other does not) is what makes consolidation useful here.
Health Posture
Health Posture provides the cross-cutting operational health view: agent connectivity, agent version drift, probe health, log volume anomalies, and resource utilization at the alarm thresholds. It overlaps with Infrastructure's per-server views — the data is largely the same — but the framing is "is this server's posture degraded operationally?" rather than "what is this server's inventory?"
Per-row metrics:
Agent connectivity
Has the agent reported in the expected cadence?
Agent version
Is the agent at the tenant's approved version floor?
Probe status
Are the eBPF / fanotify / netlink / audit / caps probes all healthy? (per probe CLI output)
Resource alarms
CPU / memory / storage at or above the alarm threshold
Log volume
Is the agent producing log volume in the expected band, or anomalously high / low?
Health posture is the SRE's fleet-monitoring surface. A server with degraded health posture is one that needs operational attention before it has a security or compliance impact. Catching health degradation early reduces the surface area on which compliance and configuration posture eventually degrade.
Cross-correlation view
A consolidated row across all three dimensions is the headline of Posture. Each server is ranked across compliance, configuration, and health, with a composite "total posture" indicator. Sorting by composite score surfaces the servers where the three dimensions agree on degradation — the strongest signal that focused remediation will have outsized impact.
The cross-correlation view also surfaces interesting disagreements: a server with high compliance posture but degraded health posture (compliance still passing, but operationally drifting) is an early warning. A server with low compliance posture but healthy configuration posture and health posture suggests the compliance issue is framework-level (a control definition or scope issue) rather than a server-specific configuration issue. Disagreements between dimensions are diagnostic information that the per-domain pillars don't surface directly.
Data sources
Posture aggregates data already collected by other pillars:
Compliance Posture
Compliance Expansion (framework scoring engine)
Configuration Posture
Baselines (per-component drift detection)
Health Posture
Infrastructure (server inventory) + agent connectivity heartbeat
Cross-correlation
Server-keyed join across the three sub-views
There are no Posture-specific data sources. Every metric Posture displays is sourced from a per-domain pillar; Posture is the navigation and cross-axis surface, not a new collection layer.
Module gating
Posture availability depends on which modules are present:
Compliance Posture requires the Compliance module.
Configuration Posture requires the Identity Intelligence module (which gates Baselines).
Health Posture is available across tiers (it draws on Infrastructure, which is the base inventory layer).
Subscription gating documented in console — the cross-correlation view requires at least Health Posture and one of (Compliance Posture, Configuration Posture). Tenants with only Health Posture available see a simplified Posture view without the cross-correlation axis.
Cross-references
Related CLI commands:
probe(per-server probe health feeds Health Posture)Related Concepts: Compliance Expansion (framework-first view of the same compliance data), Baselines (per-component view of the same configuration data), Infrastructure (server-first view of the same health data), Dashboard (fleet-level summary that draws on Posture)
Related How-to: Configure (agent settings that affect health posture cadence)
Related: Console | Compliance Expansion | Baselines | Infrastructure | Glossary
Last updated
Was this helpful?