Security Model

Nomad is a flexible workload orchestrator to deploy and manage any containerized or legacy application using a single, unified workflow. It can run diverse workloads including Docker, non-containerized, microservice, and batch applications.

Nomad utilizes a lightweight gossip and RPC system, similar to Consul, which provides various essential features. Both of these systems provide security mechanisms which should be utilized to help provide confidentiality, integrity and authentication.

Using defense in depth is crucial for cluster security, and deployment requirements may differ drastically depending on your use case. Further security features for multi-tenant deployments are offered exclusively in the enterprise version. This documentation may need to be adapted to your deployment situation, but the general mechanisms for a secure Nomad deployment revolve around:

• mTLS - Mutual authentication of both the TLS server and client x509 certificates prevents internal abuse by preventing unauthenticated access to network components within the cluster.

• ACLs - Enables authorization for authenticated connections by granting capabilities to ACL tokens.

• Namespaces - Access to read and write to a namespace can be controlled to allow for granular access to job information managed within a multi-tenant cluster.

• Sentinel Policies (Enterprise Only) - Sentinel policies allow for granular control over components such as task drivers within a cluster.

Personas

When thinking about Nomad, it helps to consider the following types of base personas when managing the security requirements for the cluster deployment. The granularity may change depending on your team's use case where rigorous roles can be accurately defined and managed using the Nomad backend secret engine for Vault. This is described further with getting started steps using a development server here.

It's important to note that there's no traditional concept of a user within Nomad itself.

• System Administrator - This is someone who has access to the underlying infrastructure to a Nomad cluster. Often she has access to SSH or RDP directly into a server within a cluster through a bastion host. Ultimately they have read, write and execute permissions for the actual Nomad binary. This binary is the same for server and client nodes using different configuration files. These users potentially have something like sudo, administrative, or some other super-user access to the underlying compute resource. Users like these are essentially totally trusted by Nomad as they have administrative rights to the system and can start or stop the agent.

• Nomad Administrator - This is someone (probably the same System Administrator) who has access to define the Nomad agent configurations for servers and clients, and/or have a Nomad management ACL token. They also have total rights to all of the parts in the Nomad system including the ability to start and stop all jobs within a cluster.

• Nomad Operator - This is someone who likely has selective access with restricted capabilities to manage jobs applicable to their namespace within a cluster.

• User - This is someone who is a user of an application being run on the system. In some cases applications may be public facing and exposed to the internet such as a web server. This is someone who shouldn't have any network access to the Nomad server API.

Secure Configuration

Nomad's security model is applicable only if all parts of the system are running with a secure configuration; Nomad is not secure-by-default. Without the following mechanisms enabled in Nomad's configuration, it may be possible to abuse access to a cluster. Like all security considerations, one must appropriately determine what concerns they have for their environment and adapt to these security recommendations accordingly.

Requirements

• mTLS enabled - Mutual TLS (mTLS) enables mutual authentication with security properties to prevent the following problems:

  • Unauthorized access because both server and clients must provide valid TLS X.509 certificates signed by the same valid CA in order to communicate within the cluster.

  • Observing or tampering communication between nodes is thwarted due to the traffic being encrypted using the well known network security protocol TLS version 1.2, with a configurable minimal version. Both server and client agents must be configured to validate each other's certificates to ensure mTLS is actually enabled. This requires appropriate certificates to be distributed to servers, clients, machines, or operators for things like CLI usage. It is recommended to use Vault to securely manage the certificate creation and rotation for nodes.

  • Agent role misconfiguration is prevented using the X.509 SAN extension. This is essentially a domain name that is used to identify and verify a node's region and role name are configured as expected (e.g. client.us-east.nomad).

  • Using the previously mentioned role name prevents maliciously masquerading as a server or client node, and allows other services to be signed easily by the same CA. This also avoids any potential pitfalls with certificates using the IP or Hostname of nodes within a cluster.

  • Using tls.verify_https_client=false downgrades the Nomad agent HTTP server to use TLS instead of mTLS. This is safe if ACLs are enabled and is recommended if you are using the Nomad web UI to avoid the difficulty of distributing client certificates to browsers.

    Some API endpoints, such as /v1/metrics and /v1/status/peers, can be accessed without an ACL token and may be exposed to anyone with access to the Nomad HTTP address when using tls.verify_https_client=false. You can use a reverse proxy or other external means to restrict access to them.

• ACLs enabled - The access control list (ACL) system provides a capability-based control mechanism for Nomad administrators allowing for custom roles (typically within Vault) to be tied to an individual human or machine operator identity. This allows for access to capabilities within the cluster to be restricted to specific users.

• Namespaces

  • This feature allows for a cluster to be shared by multiple teams within a company. Using this logical separation is important for multi-tenant clusters to prevent users without access to that namespace from conflicting with each other. This requires ACLs to be enabled in order to be enforced.

• Sentinel Policies (Enterprise Only) - Sentinel is a feature which enables policy-as-code to enforce further restrictions on operators. This is used to augment the built-in ACL system for fine-grained control over jobs.

• Resource Quotas (Enterprise Only) - Can limit a namespace's access to the underlying compute resources in the cluster by setting upper-limits for operators. Access to these resource quotas can be managed via ACLs to ensure read-only access for operators so they can't just change their quotas.

Recommendations

The following are security recommendations that can help significantly improve the security of your cluster depending on your use case. We recommend always practicing defense in depth when architecting the security mechanisms for your environment.

• Rotate credentials - Using short-lived credentials or rotating them frequently is highly recommended to reduce damage of accidentally leaked credentials.

  • Use Vault to create and manage dynamic, rotated credentials prevent secrets from being easily exposed within the job specification itself which may be leaked into version control or otherwise be accidentally stored on disk on an operator's local machine.

  • Rotate credentials used by the Nomad agent; e.g. integrate with Vault's PKI secret engine to automatically generate and renew dynamic, unique X.509 certificates for each Nomad node with a short TTL.

• Running without Root - Nomad servers can be run as unprivileged users that only require access to the data directory.

• Containers with Sandbox Runtimes - In some situations, such as running untrusted code as a service, it may be worth considering using different container runtimes such as gVisor or Kata Containers. These types of runtimes provide sandboxing features which help prevent raw access to the underlying shared kernel for other containers and the Nomad client agent itself. Docker driver allows customizing runtimes.

• Disable Unused Drivers - Each driver provides different degrees of isolation, and bugs may allow unintended privilege escalation. If a task driver is not needed, you can disable it to reduce risk.

• Linux Security Modules - Use of security modules that can be directly integrated into operating systems such as AppArmor, SElinux, and Seccomp on both the Nomad hosts and applied to containers for an extra layer of security. Seccomp profiles are able to be passed directly to containers using the security_opt parameter available in the default Docker driver.

• Service Mesh - Integrating service mesh technologies such as Consul can be extremely useful for limiting and efficiently load balancing network connectivity within a cluster.

• TLS Settings - TLS settings, such as the available cipher suites, should be tuned to fit the needs of your environment.

• HTTP Headers - Additional security headers, such as X-XSS-Protection, can be configured for HTTP API responses.

Threat Model

The following are parts of the Nomad threat model:

• Nomad agent-to-agent communication - Transport encryption for agent-to-agent communication is required to prevent eavesdropping. TCP and UDP based protocols within Nomad provide different mechanisms for enabling encryption including symmetric (shared gossip encryption keys) and asymmetric keys (TLS).

• Tampering of data in transit - Any tampering should be detectable via mTLS and cause Nomad to avoid processing the request.

• Access to data without authentication or authorization - Requests to the server should be authenticated and authorized using mTLS and ACLs respectively.

• State modification or corruption due to malicious messages - Improperly formatted messages are discarded while properly formatted messages require authentication and authorization.

• Non-server members accessing raw data - All servers that join the cluster require proper authentication and authorization in order to begin participating in Raft. All data in Raft should be encrypted with TLS.

• Denial of Service against a node - DoS attacks against a single node should not compromise the security posture of Nomad.

The following are not part of the threat model for server agents:

• Access (read or write) to the Nomad data directory - Information about the jobs managed by Nomad is persisted to a server's data directory.

• Access (read or write) to the Nomad configuration directory - Access to Nomad's configuration file(s) directory can enable and disable features for a cluster.

• Memory access to a running Nomad server agent - Direct access to the memory of the Nomad server agent process (usually requiring a shell on the system through various means) results in almost all aspects of the agent being compromised including access to certificates and other secrets.

• Existence of Variables metadata - Access to Variables List APIs is controlled by ACL policies, but the existence of specific paths or metadata is not considered sensitive.

The following are not part of the threat model for client agents:

• Access (read or write) to the Nomad data directory - Information about the allocations scheduled to a Nomad client is persisted to its data directory. This would include any secrets in any of the allocation's file systems.

• Access (read or write) to the Nomad configuration directory - Access to a client's configuration file can enable and disable features for a client including insecure drivers such as raw_exec.

• Memory access to a running Nomad client agent - Direct access to the memory of the Nomad client agent process allows an attack to extract secrets from clients such as Vault tokens.

• Lax Client Driver Sandbox - Drivers may allow some privileged operations, e.g. filesystem access to configuration directories, or raw accesses to host devices. Such privileges can be used to facilitate compromise other workloads, or cause denial-of-service attacks.

Internal Threats

• Job Operator - Someone with a valid mTLS certificate and ACL token may still be a threat to your cluster in certain situations, especially in multi-team cluster deployments. They may accidentally or intentionally use a malicious job to harm a cluster which can help be protected against using Quotas, Namespace, and Sentinel policies.

• Workload - Workloads may have host network access within a cluster which can lead to SSRF due to application security issues outside of the scope of Nomad which may lead to internal access within the cluster. Using mTLS, ACLs and Sentinel policies together can add layers of protection against malicious workloads.

• RPC / API Access - RPC and HTTP API endpoints without mTLS can expose clusters to abuse within the cluster from malicious workloads.

• Client driver - Drivers implement various workload types for a cluster, and the backend configuration of these drivers should be considered to implement defense in depth. For example, a custom Docker driver that limits the ability to mount the host file system may be subverted by network access to an exposed Docker daemon API through other means such as the raw_exec driver.

External Threats

There are two main components to consider to for external threats in a Nomad cluster:

• Server agent - Internal cluster leader elections and replication is managed via Raft between server agents encrypted in transit. However, information about the server is stored unencrypted at rest in the agent's data directory. This may contain sensitive information such as ACL tokens and TLS certificates.

• Client agent - Client-to-server communication within a cluster is encrypted and authenticated using mTLS. Information about the allocations on a client node is unencrypted in the agent's data and configuration directory.

Network Ports