Skip to main content

​
Introduction

Poolside’s on-premises platform is designed to operate in high-security environments, including those requiring Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) compliance. Use these guidelines when you deploy Poolside 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 DISA STIG compliance. 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 Poolside supports for on-premises deployments, along with the STIG baselines Poolside has validated and any baselines still under evaluation.
OSVersionSTIG baselineStatus
Ubuntu22.04 LTSDISA STIG Ubuntu 22.04 v2r7Supported with documented exceptions
Red Hat Enterprise Linux (RHEL)9.xDISA STIG RHEL 9 v2r5Supported with documented exceptions
Ubuntu24.04DISA STIG Ubuntu 24.04 v1r4Currently being evaluated
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
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’s Kubernetes-based architecture 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 (BPF) controls

Two specific STIG controls affect how the NVIDIA container runtime manages GPU device access:
STIG IDControlDefault STIG valuePoolside requirement
V-257810kernel.unprivileged_bpf_disabled1 (enabled)0 (disabled)
V-257942net.core.bpf_jit_harden1 or 2 (enabled)0 (disabled)
Why this matters The NVIDIA container runtime uses 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 only STIG control exceptions required for GPU workload compatibility.

​
Additional considerations

When applying STIG hardening to Poolside deployments, consider the following:
Control areaConsideration
Federal Information Processing Standards (FIPS)-validated cryptographyConfigure this during OS installation. Contact Poolside if you deploy in a FIPS-required environment.
Repeated privilege escalation authenticationTerraform-based installation requires a temporary sudoers configuration during deployment.
Uncomplicated Firewall (UFW) rate limitingDefault rate limits are compatible. High-concurrency deployments may require tuned thresholds.
Sticky bit on public directoriesCompatible with Poolside’s single-tenant architecture

​
Pre-deployment checklist

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

​
Additional resources