Maximize resource usage and minimize risk with Nomad-based Workload Security Rings

Organizations must balance trade-offs when designing robust architectures, deciding which compromises best serve the system’s goals. A classic example of this challenge involves balancing security and compute resource utilization across a portfolio of applications with diverse compute and security requirements. Isolating security-sensitive workloads to dedicated compute infrastructure is a common means of handling such a diverse portfolio of applications. However, this approach may lead to inefficient CPU usage, as it prevents workloads from being optimally distributed (or “Bin packed”) across the compute resource pool.

You can also read this article on our Substack!

This blog post explores how HashiCorp Nomad, Vault, and Consul can serve as the foundational components of a platform that uses the Workload Security Ring (WSR) method. You’ll learn why these tools are a strong architectural fit for building secure, multi-tenant environments and how to integrate them effectively to deliver isolation, identity, and governance across diverse workloads.

By the end of this article, you will understand:

• The key design principles behind the Workload Security Ring (WSR) method
• How Nomad, Vault, and Consul complement each other to enforce these principles
• Practical strategies for incorporating these tools into a platform that supports the WSR method
• The benefits this approach brings to scalability, security, and operational simplicity

What are Workload Security Rings?

Financial institutions and other highly regulated organizations manage thousands of applications. Dedicating machines to specific jobs and/or application types is therefore impractical. This is where the concept of “Workload Security Rings” (WSR) comes into play — a concept that originated at Google. Organizations split workloads into security equivalence classes (rings), with each class maintaining isolation and enforcement at the machine boundary.. The ‘Ring’ concept addresses typical isolation threats. The potential loss of compute utilization is mitigated by the introduction of a class of hardened jobs that do not need to be segregated from other workloads.

Why use the WSR method?

The Workload Security Ring method solves the workload isolation challenge by driving up utilization across the available compute resources whilst mitigating against some key security risks:

• Attacks from lateral movement A bad actor facilitates this attack by leveraging the weak security posture of a workload with a low level of security sensitivity to attack and break workloads that are more security sensitive running on the same infrastructure.
• Denial of service through resource saturation “Noisy neighbors” can degrade an application’s quality of service, and bad actors instigating denial-of-service attacks can completely halt applications.

Some organizations often need to allow developers and engineers to debug and experiment with security-sensitive applications. This may require some of the normal security policies put into place to be relaxed.

How do WSR method-based platforms work?

The following diagram illustrates three major components of a WSR method-based platform:

1. Workload scoring criteria The “binary authorization” concept underpins the basic Workload Security Ring method. Simply put, if a container image or executable is not signed by a trusted Certificate Authority (CA) to guarantee its provenance, the container or executable cannot run on the WSR method-based platform. You may also want to consider the additional scoring criteria:

• Data security sensitivit Does the workload involve the handling of any data that is security sensitive, such as data that enables specific individuals to be identified?
• Regulations and compliance Is any processing carried out that relates to SOC2, GDPR, PCI DSS, and consumer protection laws?
• Financial transactions Does the workload handle or instigate financial transactions?
• Artifact provenance Do the workload artifacts originate from known, trusted repositories and are signed by a trusted certificate authority?
• Hygiene Have the executable artifacts associated with the workload undergone a vulnerability scan that has come back clean or falls within a CVE score that is deemed as being secure?
• Endpoint exposure Does the workload expose any endpoints to the public?

2. Workload Security Ring assignment You need a mechanism that aggregates the scores for each workload to determine what security ring to assign each workload to.

3. Workload Security Rings

• Ring 0 Includes financial transaction systems, regulated critical infrastructure, and workloads where breaches cause fines or reputational loss.
• Ring 1 Sensitive workloads, such as PII processing and internal dashboards.
• Ring 2 Less critical workloads, such as batch processing and non-sensitive API endpoints.
• Ring 3 Minimal-security workloads, such as public-facing apps without sensitive data and stateless applications.

Implementing a WSR method-based platform with HashiCorp

HashiCorp’s products provide a set of capabilities that make them uniquely suited for building the foundations of a WSR method-based platform.

Nomad: Workload orchestration

Nomad’s lightweight architecture, flexibility, and support for multiple workload types (containers, virtual machines (VMs), binaries) make it ideally suited for environments with diverse application portfolios, and it provides some unique capabilities for supporting WSM-based platforms.

• Unified Orchestration for Diverse Workloads Nomad’s lightweight and flexible architecture supports multiple workload types — including containers, virtual machines, and raw binaries — making it well-suited for environments with mixed application portfolios. It provides a consistent orchestration layer for both containerized and non-containerized workloads (e.g., Java, .NET), enabling organizations in security-sensitive sectors like finance to modernize without full container adoption.
• Strong Process and Workload Isolation Nomad can enforce process isolation for containerized workloads using gVisor and Kata Containers, while non-containerized tasks are isolated at the OS level using cgroups and Landlock Linux Security Modules (LSM). Workloads are assigned to Node Pools, which can be mapped to different security rings. For example, a ring-0 pool for high-security workloads might combine Landlock LSM for binaries and gVisor for containers. Task drivers can also define explicit cgroup usage to further strengthen isolation.
• Security Ring Governance and Policy Enforcement Nomad uses Access Control Lists (ACLs) for authorization, which are scoped at the namespace level. Through Node Pool Governance, namespaces can be bound to specific node pools, effectively creating ACL boundaries aligned with security rings. Sentinel policy-as-code prevents privilege escalation or cross-ring placement (e.g., preventing non-hardened workloads from running on ring-0 nodes).
• Performance and Workload Integrity For performance-sensitive environments such as low-latency trading, Nomad enables direct workload execution without VM or container overhead and supports NUMA-aware scheduling at the node pool level. Resource quotas and limits can be applied to any workload type (containers, binaries, JARs, scripts) to prevent “noisy neighbor” interference. Additionally, Nomad supports workload identity federation (OIDC-based) to securely generate ephemeral identities for workloads — eliminating the “secret zero” problem and enhancing credential security in ring-0 deployments.

***** are features only available in Nomad Enterprise

Consul: Service discovery and service mesh

Consul is a platform in its own right, providing service discovery and enabling secure service-to-service communication through a TLS-encrypted service mesh. Nomad integrates with Consul using auto-join and service registration features, allowing jobs to be registered as services. You can make these services participate in the mesh by including a service block in the Nomad job specification.

Consul provides two mechanisms for service segregation and ACL scoping: Namespaces and Admin partitions. Hardening and network isolation can be further enhanced by the use of Consul’s transparent proxy, which prevents direct inbound connections that bypass the mesh and allows applications to communicate through the service mesh without modifying their configurations.

Admin partitions exist at a level above namespaces in the identity hierarchy. They contain one or more namespaces and allow multiple independent tenants to share a Consul server cluster. As a result, admin partitions enable administrative and communication boundaries between services to be defined that can be managed by separate teams.

In the context of a WSR method-based platform, Nomad node pools that embody security rings can be bound to specific Consul admin partitions, thus extending the notion of workload and process isolation to service isolation.

Vault: Secrets/credentials management and provisioning

Vault is a platform for managing secrets and credentials in a secure manner. Nomad integrates with Vault using workload identity, such that secrets and credentials can be directly injected into a Nomad job.

A HashiCorp-based WSR method solution

Building on the conceptual overview of a WSR method-based platform, this is what a WSR workflow looks like using HashiCorp products:

Let’s elaborate on the specific elements in this workflow.

• Scoring criteria and job initiation Assuming data sources for the scoring criteria are REST APIs. Terraform’s http data source can be used to obtain the data from these endpoints. In the interest of structure and modularity, the code to interrogate these API endpoints and come up with an aggregate score for the security sensitivity of a job can be encapsulated within a Terraform module. As an example, the Terraform code below shows how this might be done for container image scan results obtained from Palo Alto Prisma Cloud:

variables.tf:

variable “path_to_console” {
 type = string
}

variable “api_version” {
 type = string
 default = “v40.00”
}

variable “image_name” {
 type = string
}

variable “prisma_username” {
 type = string
}

variable “prisma_password” {
 type = string
 sensitive = true
}

prisma.tf:

provider “http” {}

data “http” “image_scan” {
  url = “${var.path_to_console}/api/${var.api_version}/images?name=${var.image_name}”
  request_headers = {
    Authorization = “Basic ${base64encode(“${var.prisma_username}:${var.prisma_password}”)}”
  }
}

Finally, the vulnerability score information can be parsed out of the JSON payload returned by the HTTP datasource:

locals.tf:

locals {
  vulnerability_tags = join(
    “,”,
    [
      for v in
        jsondecode(data.http.image_scan.response_body)[0].vulnerabilities : “${v.cve}:${v.severity}”
    ]
  )

  vulnerability_distribution = jsondecode(data.http.image_scan.response_body)[0].vulnerabilityDistribution
  vulnerability_risk_score   = jsondecode(data.http.image_scan.response_body)[0].vulnerabilityRiskS
  cocompliance_distribution  = jsondecode(data.http.image_scan.response_body)[0].complianceDistribution
  compliance_risk_score      = jsondecode(data.http.image_scan.response_body)[0].complianceRiskScore
}

Note that vulnerability information can also be sourced from other popular vulnerability scanning and detection platforms.

• Workload Security Ring assignment You assign jobs to Workload Security Rings by specifying the relevant node_pool in the job specification:

job “critical-task” {
  node_pool = “ring-0”
  # . . .
}

• Workload Security Rings A node pool represents each workload security ring.. Taking ring-0 for example, this can be created using the following HashiCorp Configuration Language (HCL) excerpt:

node_pool “ring-0” {
  description = “Critical workloads with the highest security requirements”

  scheduler_config {
    Scheduler_algorthm = “binpack”
  }

  meta {
    environment = “dev”
    owner = “sre”
  }
}

client {
  meta {
    pool = “ring-0”
  }
}

Note: The scheduler algorithm can be specified at the node pool level, and this applies to any workload that runs on the node pool, irrespective of the task driver used by a job that embodies that workload.

Next, with a Nomad feature known as Node pool governance that binds namespaces to node pools, create a namespace for each workload security ring node pool. The HCL excerpts below are to be used with the Nomad CLI:

namespace “ring-0” {
  description = “Critical workloads with the highest security requirements.”

  node_pool_config {
    default = “ring-0”
  }
}

Client nodes are then assigned to specific node pools in their configuration:

client {
  enabled = true
  node_pool = “ring-0”

  server_join {
    retry_join = [“127.0.0.1:4647”, “127.0.0.1:5647”, “127.0.0.1:6647”]
  }

  meta {
    tag = “ring-0-node-01”
  }
}

• Secrets and credentials injection You can configure Nomad to consume secrets and credentials from one or more Vault clusters. Nomad’s Vault integration leverages Nomad’s workload identity capability to avoid the secret zero issue. Once up and running, secrets and credentials can be consumed with a Nomad job specification with a template block, as per the example below taken from the Nomad Secrets Consumption Patterns: Vault Integration blog post:

job “example” {
  datacenters = [“dc1”]
  type = “service”

  group “example” {
    count = 1

    network {
      port “vs” {
        static = 14646
      }
    }

    task “demo” {
      driver = “docker”

      template {
        destination = “${NOMAD_SECRETS_DIR}/env.vars”
        env = true
        change_mode = “restart”
        data = <<EOF
SECRET_ONE = “{{with secret “secret/data/hashicups-api”}}{{index .Data.data “api-key”}}{{end}}”
SECRET_TWO = “{{with secret “secret/data/hashicups-api”}}{{index .Data.data “principal-id”}}{{end}}”
        EOF
      }

      config {
        image = “devopsrob/nomad-vault-integration:1.1.0”
        ports = [“vs”]
      }

      resources {
        cpu    = 500
        memory = 256
      }
    }
  }
}

• Service publishing Nomad comes with its own built-in service publishing capability. Alternatively, the services associated with jobs can be directly integrated into a Consul service mesh or other load-balancing technologies.

In summary

The Workload Security Ring pattern offers a powerful approach to balancing resource utilization with security requirements across workloads of varying sensitivity. Implementing a Workload Security Ring method-based platform using the HashiCorp suite of products results in the following outcomes:

• Optimized resource utilization: Nomad enhances compute efficiency through bin packing across both containerized and non-containerized workloads.
• Strong process isolation: Nomad ensures process-level isolation using gVisor for containers and Landlock LSM for non-containerized workloads.
• Scoping access control to security rings: Nomad namespaces can be bound to node pools and governed through ACLs aligned with each security ring.
• Securely deliver secrets and credentials to jobs: Nomad’s built-in workload identity capability simplifies Vault integration, allowing you to inject secrets and credentials into jobs while mitigating the “Secret zero” problem.
• Seamless integration with Consul service mesh: Jobs can easily be integrated into a service mesh with Nomad’s first-class integration with Consul.
• Dynamic configuration with Terraform: Terraform enhances this pattern by enabling scoring criteria to be sourced from API endpoints, templating Nomad job specifications, and integrating natively with the Nomad provider.

Next steps

You can begin exploring this architecture today using the community editions of HashiCorp Nomad, Vault, and Consul. This will allow you to gain familiarity with these products and follow the tutorials that HashiCorp freely provides. When you are ready for production and enterprise-grade usage, extend the solution with the Nomad, Vault, and Consul enterprise features that provide enhanced security, governance, and scalability.

1. Start with Nomad: Install Nomad to get familiar with workload scheduling, node pools, and workload isolation. When you are ready to scale, Nomad Enterprise adds advanced features, such as multi-region federation, namespace governance, and Sentinel policy enforcement for compliance and workload placement control.
2. Add Vault for Secrets and Identity Management: Integrate Vault to manage secrets, workload identities, and encryption policies. Vault Enterprise extends this with automated replication, disaster recovery, and sophisticated access control — ideal for environments running multiple workload security rings.
3. Introduce Consul for Secure Service Networking: Deploy Consul to provide service discovery, mesh capabilities, and workload-to-workload authorization. With Consul Enterprise, you gain features such as admin partitions, network segmentation, and advanced governance controls to manage traffic and policy boundaries across rings.
4. Follow the Official Learning Paths: HashiCorp provides extensive tutorials and integration guides to help you get started and evolve toward production-ready deployments:

• Nomad Tutorials
• Vault Tutorials
• Consul Tutorials
• Integrating Vault with Nomad
• Integrating Consul with Nomad