STIG hardening considerations

Introduction

Use these guidelines when you deploy Poolside on-premises model inference on STIG-hardened Red Hat Enterprise Linux (RHEL) or Ubuntu systems. This page outlines key considerations, known compatibility issues, and recommended configurations for high-security environments that require Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) compliance. For the full list of supported operating systems, see On-premises installation prerequisites. This page covers only the operating systems with Poolside STIG guidance. These recommendations draw from the DISA STIG library and related STIG references. Poolside does not provide STIG-specific implementation guidance or support for customer-defined STIG policies.

Supported operating systems and STIG baselines

The following table lists the operating systems with Poolside STIG guidance for on-premises model inference deployments, along with the STIG baselines Poolside has validated and any baselines still under evaluation.

OS	Version	STIG baseline	Status
Ubuntu	22.04 LTS	DISA STIG Ubuntu 22.04 v2r7	Supported with documented exceptions
Red Hat Enterprise Linux (RHEL)	9.x	DISA STIG RHEL 9 v2r5	Supported with documented exceptions
Ubuntu	24.04	DISA STIG Ubuntu 24.04 v1r4	Currently being evaluated

Recommended approach

Apply STIG hardening after you complete the on-premises installation. This sequence gives you a clean baseline and simplifies troubleshooting if issues arise. For Ubuntu and RHEL environments, use the OpenSCAP tooling with the DISA STIG profile. For example, on RHEL 9.x:

# Install prerequisites.
sudo dnf install openscap-scanner scap-security-guide

# Run baseline scan.
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_stig \
  --results stig-scan-results.xml \
  --report stig-scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

DISA also publishes Ansible playbooks for supported STIGs, but they often lag the latest STIG policies.

Known compatibility considerations

Poolside on-premises model inference relies on the NVIDIA GPU Operator and container runtime components that interact with kernel-level features. Certain STIG controls can conflict with these requirements.

Berkeley Packet Filter controls

Two specific STIG controls affect how the NVIDIA container runtime manages GPU device access:

STIG ID	Control	Default STIG value	Poolside requirement
V-257810	`kernel.unprivileged_bpf_disabled`	`1` (enabled)	`0` (disabled)
V-257942	`net.core.bpf_jit_harden`	`1` or `2` (enabled)	`0` (disabled)

Why this matters The NVIDIA container runtime uses Berkeley Packet Filter (BPF) filters to dynamically configure device access rules for GPU containers. When these controls are active, container initialization can fail with errors such as:

nvidia-container-cli.real: mount error: failed to add device rules: 
unable to generate new device filter program from existing programs

Remediation Set these two kernel parameters to 0 in /etc/sysctl.conf:

kernel.unprivileged_bpf_disabled = 0
net.core.bpf_jit_harden = 0

Reboot the system after you modify these settings. These are the documented STIG control exceptions for GPU workload compatibility.

Additional considerations

When applying STIG hardening to Poolside on-premises model inference deployments, consider the following:

Control area	Consideration
Federal Information Processing Standards (FIPS)-validated cryptography	Configure this during OS installation. Contact Poolside if you deploy in a FIPS-required environment.
Repeated privilege escalation authentication	Terraform-based installation requires a temporary `sudoers` configuration during deployment.
Uncomplicated Firewall (UFW) rate limiting	Default rate limits are compatible. High-concurrency deployments may require tuned thresholds.
Sticky bit on public directories	Compatible with Poolside’s single-node model inference architecture.
Filesystem partition scheme	See Storage requirements for more information.

Pre-deployment checklist

Before deploying Poolside on a STIG-hardened system:

Document your STIG baseline: Provide Poolside with the specific STIG profile version and any customer-specific policy modifications.
Apply OS hardening last: Complete STIG remediation after Poolside installation.
Configure BPF exceptions: Apply the kernel parameter changes documented in Berkeley Packet Filter controls. Reboot the system for the changes to take effect.
Validate GPU access: Confirm all pods in gpu-operator are Running or Completed after hardening.
Retain scan reports: Keep pre-remediation and post-remediation OpenSCAP reports for troubleshooting.

​Introduction

​Supported operating systems and STIG baselines

​Recommended approach

​Known compatibility considerations

​Berkeley Packet Filter controls

​Additional considerations

​Pre-deployment checklist

​Additional resources