**[Consul](https://www.consul.io/)** can be extremely useful for limiting
and efficiently load balancing network connectivity within a cluster.
### 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.
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](/docs/drivers/raw_exec.html).
* **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
* **Operator** - Someone with a valid mTLS cert 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
jobspec to harm a cluster which can help be protected against using
Namespaces 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 information may contain 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
| **Port / Protocol** | Agents | Description |
|----------------------|---------|-------------|
| **4646** / TCP | All | [HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) to provide [UI](/guides/web-ui/access.html) and [API](/api/index.html) access to agents. |
| **4647** / TCP | Servers | [RPC](https://en.wikipedia.org/wiki/Remote_procedure_call) protocol used by agents. |
| **4648** / TCP + UDP | Servers | [gossip](/docs/internals/gossip.html) protocol to manage server membership using [Serf](https://www.serf.io/). |
