Security

While certain parallelization and high performance library capabilities still require lowering the security threshold within a cluster, Warewulf strives to support good security practices within the cluster wherever possible.

Provisioning Security

Provisioning is, by default, a relatively “insecure” process: there is generally nothing preventing a user on a cluster node from spoofing a provision request and downloading the node image and overlays for inspection. If any of these include secrets (e.g., private keys) they are at risk of exposure.

There are multiple ways to secure the Warewulf provisioning process:

  • The best way to secure the provisioning process is to dedicate a vLAN specifically for provisioning, and then not make that vLAN available in the provisioned environment. Warewulf can be used in such an environment (without wwclient) but you must consult your switch documentation and features to implement a default vLAN for provisioning and to ensure that the runtime operating system is configured for a different tagged vLAN once booted.

  • Warewulf can leverage hardware “asset tags” which almost all vendors support. This is a configurable firmware string that is accessible only via root or physical access. During provisioning (as well as post provisioning via wwclient) Warewulf sends the detected asset tag to the Warewulf server as a “shared secret” token. If the node is also configured with an asset key on the Warewulf server (e.g., via wwctl node set --assetkey "..."), the Warewulf server will only respond to requests with a matching asset tag.

  • If the Warewulf server is configured with warewulf:secure: true, then it will only provide the runtime overlay to a wwclient communicating from a privileged (< 1024) TCP port. This prevents unprivileged cluster users from being able to retrieve the runtime overlay.

  • When the nodes are booted via shim and grub Secure Boot can be enabled. This means that the nodes only boot the kernel which is provided by the distributor and also custom complied modules can’t be loaded.

  • TLS (transport layer security) can be enabled for the Warewulf server. When enabled, HTTPS is used when transferring runtime overlays. The kernel and system image are always transferred unencrypted.

SELinux

The Warewulf server can be run with SELinux enabled in “targeted” and “enforcing” mode.

For more information about running SELinux-enabled cluster node images, see SELinux-Enabled Images.

firewalld

If the Warewulf server is running firewalld, the following services must be added for them to function:

firewall-cmd --permanent --add-service=warewulf
firewall-cmd --permanent --add-service=dhcp
firewall-cmd --permanent --add-service=nfs
firewall-cmd --permanent --add-service=tftp
firewall-cmd --reload

Note

The DHCP, TFTP, and NFS services may be managed manually, apart from the Warewulf server. In that case, they may be omitted from the firewalld configuration on the Warewulf server; but they must be accessible from where they are served.

nftables

If the Warewulf server is running nftables directly, without firewalld, ensure that TCP port 9873 must be permitted for cluster nodes to communicate with the Warewulf server.

nft add rule inet filter input tcp dport 9873 accept
nft list ruleset >/etc/nftables.conf
systemctl restart nftables

TLS / HTTPS

TLS can be enabled by setting tls: true in the Warewulf server configuration.

warewulf:
  tls: true
  tls port: 9874

This enables an HTTPS server on the TLS port (default: 9874). A key and self-signed certificate can be created with wwctl configure tls.

By default, the key and certificate are stored in /etc/warewulf/tls/.

You can also import your own keys with wwctl configure tls --import.

If HTTPS is enabled the delivery of the runtime overlay is disabled over HTTP, and the runtime overlay is only retrieved by wwclient.

To additionally require TLS for access to the REST API, set tls: true under the api: section:

api:
  enabled: true
  tls: true

When api: tls is set, the REST API rejects plain-HTTP requests.