DEV.co
Open-Source Security · konstruktoid

ansible-role-hardening

Ansible role that automatically hardens Linux servers (AlmaLinux, Debian, Ubuntu) by applying security baselines including SSH configuration, firewall rules, PAM authentication, and audit logging. Requires Ansible 2.18+ and should be tested in non-production before use.

Source: GitHub — github.com/konstruktoid/ansible-role-hardening
639
GitHub stars
125
Forks
Jinja
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorykonstruktoid/ansible-role-hardening
Ownerkonstruktoid
Primary languageJinja
LicenseApache-2.0 — OSI-approved
Stars639
Forks125
Open issues6
Latest releasev4.6.0 (2026-06-01)
Last updated2026-07-08
Sourcehttps://github.com/konstruktoid/ansible-role-hardening

What ansible-role-hardening is

systemd-focused Ansible role (Jinja templates) that configures security controls across kernel parameters, SSH hardening, auditd rules, UFW firewall, PAM, SELinux/AppArmor, and unattended upgrades. Supports AlmaLinux 9/10, Debian 12/13, Ubuntu 24.04/26.04 with extensive templating for customization.

Quickstart

Get the ansible-role-hardening source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/konstruktoid/ansible-role-hardening.gitcd ansible-role-hardening# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Enterprise Linux Hardening at Scale

Organizations managing multiple Ubuntu/Debian/AlmaLinux servers requiring consistent CIS/CMMC baseline compliance. Role automates kernel lockdown, SSH restrictions, firewall policies, and audit logging across fleets.

AWS/Azure Cloud Image Hardening

Hardening AMIs and Azure VM images during build pipelines (Packer) to ship pre-hardened OS images. Role is actively used in konstruktoid/hardened-images for this purpose with SLSA artifact verification.

DevOps Infrastructure-as-Code Security Baseline

Infrastructure teams using Ansible for provisioning who need to embed security controls into playbooks without writing custom hardening logic. Reduces time to production for secure servers.

Implementation considerations

  • Test extensively in non-production before rollout; role applies system-wide hardening that can impact application connectivity and behavior if defaults conflict with workload requirements.
  • Review and customize key variables: sshd_admin_net, sshd_allow_groups, firewall rules (UFW), and kernel parameters to avoid locking out legitimate traffic or breaking services.
  • Role deletes UFW rules not marked with 'ansible managed' comment; integrate carefully with existing firewall rules to prevent accidental rule loss.
  • Requires root/become privileges for tasks (PAM, kernel params, systemd configs, auditd); ensure Ansible execution model supports privilege escalation.
  • Defaults are opinionated (e.g., 60-day password expiry, faillock deny=5, kernel lockdown); audit defaults/main.yml and meta/argument_specs.yml before deployment.

When to avoid it — and what to weigh

  • Minimal Embedded or Specialized Systems — If deploying to non-standard or embedded Linux distributions outside the supported OS list (AlmaLinux 9/10, Debian 12/13, Ubuntu 24.04/26.04), role will lack proper testing and may fail.
  • Ansible < 2.18 Environments — Role requires Ansible 2.18 or higher. Legacy or older automation stacks cannot use this role without significant upgrades, creating deployment friction.
  • Systems Needing Gradual / Selective Hardening — Role applies a broad, opinionated baseline (kernel lockdown, strict SSH, PAM, auditd, UFW). If selective hardening is required, you'll need to override many defaults or maintain a fork.
  • Environments Without Change Testing Capability — README explicitly warns: 'Do not use this role without first testing in a non-operational environment.' If you cannot test in staging, deployment risk is high.

License & commercial use

Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license. Allows use, modification, and distribution for commercial purposes with proper attribution and license notice.

Apache 2.0 is a permissive, commercial-friendly license. You may use this role in commercial deployments and modify it as needed. Include Apache 2.0 license notice in distributions. No patent indemnification clauses; standard patent grant applies. Consult legal for enterprise-specific license terms.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityModerate
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

Role applies defense-in-depth hardening (SSH key-only auth, PAM account lockout, kernel lockdown, auditd logging, UFW firewall, sysctl kernel parameters). No security audit or CVE history provided. Verify that baseline defaults align with your threat model and compliance requirements (CMMC, CIS). Test thoroughly—strict settings may inadvertently break legitimate services. Role itself does not guarantee zero-day or exploit mitigation; it enforces known hardening practices.

Alternatives to consider

CIS-CAT Pro or OpenSCAP

Automated compliance scanning and remediation tools for CIS/DISA STIGs. More prescriptive and audit-focused; lower configuration overhead but less flexible than Ansible role.

Lynis

Lightweight hardening auditor and security scanning tool. Good for standalone servers or non-Ansible environments; does not manage infrastructure-as-code deployments at scale.

Chef Cookbook (e.g., dev-sec/hardening)

Dev-Sec community hardening cookbooks for Chef Infra. If your org standardizes on Chef instead of Ansible, offers comparable role-based hardening automation.

Software development agency

Build on ansible-role-hardening with DEV.co software developers

Test this Ansible role in your staging environment to apply consistent security baselines across your fleet. Review defaults, customize for your threat model, and deploy with confidence.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

ansible-role-hardening FAQ

Will this role break my running services?
Possibly, if your services depend on less-strict SSH auth, kernel parameters, or firewall rules. README explicitly recommends testing in non-production. Start with a staging server and validate application behavior.
Can I use this on CentOS 7 or older distributions?
No. Role explicitly supports AlmaLinux 9/10, Debian 12/13, Ubuntu 24.04/26.04 only. Older distributions lack tested compatibility and may fail or apply incorrect hardening.
How do I customize SSH hardening without rewriting the entire role?
Use role variables like sshd_allow_groups, sshd_admin_net, sshd_match_users, sshd_update_moduli, etc. documented in defaults/main.yml. Refer to examples in README for playbook-level variable overrides.
What compliance standards does this role cover?
Role tags include CMMC. README does not detail specific CIS benchmarks or DISA STIG mappings. Cross-reference defaults with your compliance framework to confirm coverage gaps or overlaps.

Software development & web development with DEV.co

From first prototype to production, DEV.co delivers software development services around tools like ansible-role-hardening. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source security and beyond.

Ready to Harden Your Infrastructure?

Test this Ansible role in your staging environment to apply consistent security baselines across your fleet. Review defaults, customize for your threat model, and deploy with confidence.