Nomad 1.10 adds dynamic host volumes, extended OIDC support, and more

HashiCorp Nomad is a simple and flexible orchestrator used to deploy and manage containers and non-containerized applications across multiple cloud, on-premises, and edge environments. It is widely adopted and used in production by organizations such as BT Group and Epic Games. Today, we are excited to announce that Nomad 1.10 is now generally available.

Here’s what’s new in Nomad:

• Dynamic host volumes Dynamic host volume governance (Nomad Enterprise)
• Extended OIDC support — Signed client assertions and Proof Key Code Exchange (PKCE)
• Improved CLI to UI transition
• Expanded upgrade testing

»Dynamic host volumes

The new dynamic host volume capability introduced in Nomad 1.10 brings an improved storage option to your Nomad workloads that expands on the previously available host volume capability. This provides a more flexible way to provision storage across your Nomad client infrastructure when compared to traditional host volumes or CSI plugins.

Instead of relying on traditional configuration management approaches for storage provisioning with traditional host volumes, leveraging dynamic host volumes now allows you to create new volumes via the CLI or API on demand. Host volumes no longer need to be defined as part of the Nomad client configuration, removing the need to restart the client agent as new volumes are added. Volumes can be provisioned using a flexible plugin specification that allows you to customize the provisioning workflow and target different storage options based on parameters defined during volume creation.

Host volumes can now optionally be created with more detailed characteristics like their minimum and maximum capacities, capabilities, and custom provisioning parameters that can be used during volume creation or update processes in order to define sizing or tiering functionality within the host volume plugin.

Whether targeting host local NVMe storage managed with LVM, ZFS, or remote SAN/NAS storage, the host volume plugin specification provides the flexibility needed to prepare the volume mount path on the client node ahead of consumption by any jobs mounting the volume.

Dynamic host volumes are a great fit for when you want to control the provisioning process on specific client nodes and then allow jobs to be reliably scheduled next to the provisioned volumes. When using remote storage where you are attempting to allow more portability across client hosts, deploying CSI plugins with Nomad may still be an appropriate choice in comparison to dynamic host volumes that are more closely tied to specific clients once created. For a detailed comparison of different persistent storage options within Nomad, visit our storage comparison section.

»Stateful deployments

When using host local storage, enabling sticky volumes in your job specification will allow the same volume on the same client to be claimed when a task group is rescheduled. This allows for persistence across the life of the task group and tightly couples the task group to the client node where the volume is claimed. Sticky volumes can optionally be enabled when mounting volumes in your job specification.

An alternative workflow can be used with dynamic host volumes across shared storage that is accessible from many different client nodes. You can allow more flexible workload portability by creating volumes with the same name across clients while using a simple host volume plugin that prepares local paths and mounts the shared storage. Leaving sticky volumes disabled allows a volume on another client with the same name to be claimed when the task group is rescheduled to a new client. This pattern may be an appropriate consideration when using dynamic host volumes with NFS, EFS, or CephFS filesystems.

»Dynamic host volume governance (Nomad Enterprise)

Providing guardrails to platform consumers is an important aspect of the storage provisioning workflow when leveraging host volumes across a shared Nomad cluster. Nomad Enterprise supports several new capabilities to provide governance when provisioning host volumes.

»Sentinel integration

During volume creation, all of the details within the dynamic host volume specification can be evaluated against Sentinel policies defining and enforcing specific patterns. An example policy might enforce the storage tier based on the environment or namespace specified. This would allow reserving more expensive NVMe storage only for specific workloads. Being able to apply policy to the volume specification gives storage operators many ways to enforce specific patterns while providing platform consumers with more flexibility around self-service volume provisioning.

»Quota support

Nomad’s resource quota system now includes coverage for host volume capacity limits that can be applied to provisioned storage within a specific namespace. This will help operators control storage consumption within a namespace based on the maximum capacities they’ve defined.

»Namespace and node pool validation

Dynamic host volumes live within the context of a specific namespace when created. When provisioning volumes in a namespace targeting a specific node pool, the namespace node pool configuration is evaluated to ensure that volume creation aligns with job placement rules for node pools.

»Dynamic host volume examples

Several host volume plugin reference examples are available on the Host volume plugins page to help you get started with implementing your own custom host volume plugins.

Check out the dynamic host volume tutorial for an in-depth walkthrough of the new host volume workflow.

»Extended OIDC support

Nomad 1.10 expands its existing OpenID Connect (OIDC) client SSO support with signed client assertions and Proof Key Code Exchange (PKCE). These enhancements are recommended as part of the Financial-grade API (FAPI) specifications and the OAuth 2.1 specification to enhance security for all OIDC clients. This enables customers in finance, government, and other industries with higher security requirements to authenticate Nomad users using their OIDC providers. Some customers in these industries are already enforcing these updated security recommendations in sensitive environments. Other Nomad users can optionally take advantage of these updated capabilities to improve security within their OIDC authentication workflows when supported by their identity providers.

»Client assertions

Nomad now supports using the private_key_jwt client assertion workflow with asymmetric key signatures. This workflow serves as an alternative to relying on a shared client_secret when authenticating Nomad users with their identity providers. This removes the requirement of storing a shared client_secret value on both the OIDC client (Nomad server) and the identity provider, reducing the risk of authentication secret exposure.

The client assertion capability can be enabled using the internal Nomad keyring with JSON Web Key Sets (JWKS) or externally provided certificates to provide flexibility to Nomad operators. This broadens the application of Nomad’s authentication support to include newly recommended standards while continuing to maintain compatibility with many commonly deployed identity providers.

Refer to the client assertion documentation for configuration examples.

»Proof Key Code Exchange(PKCE)

Nomad 1.10 also supports Proof Key for Code Exchange (PKCE) when configuring new OIDC authentication methods as an additional layer of security. While traditionally seen with native mobile applications or single-page web applications within OAuth 2.0 standards, PKCE has recently been recommended for all OIDC client workflows as part of the FAPI 2.0 and OAuth 2.1 specifications. This recommendation applies even when authenticating with confidential OIDC clients like Nomad. PKCE provides an additional layer of defense in order to prevent attackers from intercepting sensitive tokens during the authentication process. This can be enabled whether deploying traditional client_secret authentication or the newly introduced client assertion workflows with private_key_jwt authentication, and is broadly supported by identity providers.

Existing auth method configurations will not retroactively enable PKCE until your configuration is updated to explicitly enable it. Some OIDC providers require additional configuration in order to support or enforce PKCE within the identity provider itself. Evaluate your OIDC provider’s capabilities when enabling this feature within your auth method configurations. It is also important to test this capability with your specific identity provider prior to updating your auth method configuration in order to avoid inadvertently disabling your SSO access to Nomad.

»Improved CLI to UI transition

When navigating in the Nomad CLI there are often moments where you may have wished you had a richer visualization of the data you are currently viewing. Nomad 1.10 introduces a new UI URL hints capability within the CLI output that is enabled by default to allow a quick transition to the web UI view with the same information.

»Expanded upgrade testing

Nomad 1.10 marks the second LTS release for Nomad. During the 1.10 development cycle, we spent time refining our existing automated testing capabilities to provide a heightened focus on upgrade stability when moving between supported LTS releases. This commitment to a seamless upgrade experience allows organizations to confidently embrace new features and enhancements while upholding the stability expected with LTS releases. By prioritizing comprehensive testing, Nomad 1.10 LTS minimizes potential disruptions and ensures a smooth, reliable upgrade path for all users, whether moving from Nomad 1.9 or the previous Nomad 1.8 LTS releases.

»Getting started with Nomad 1.10

Nomad 1.10 adds a variety of new features and enhancements. We encourage you to try them out:

• Download Nomad 1.10 from the project website.
• Learn more about Nomad with tutorials on the HashiCorp Developer site.
• Contribute to Nomad by submitting a pull request for a GitHub issue with the “help wanted” or “good first issue” label.
• Participate in our community forums, office hours, and other events.
• To learn more about how Nomad can solve your business-critical workload orchestration needs, talk to our sales team and solutions engineers about test-driving Nomad Enterprise. Refer to the release notes for a comprehensive list of new capabilities as well as any breaking changes or deprecations included as part of the Nomad 1.10 release.