2014-02-08 00:41:03 +00:00
---
layout: "docs"
page_title: "Security Model"
sidebar_current: "docs-internals-security"
2014-10-19 23:40:10 +00:00
description: |-
Consul relies on both a lightweight gossip mechanism and an RPC system to provide various features. Both of the systems have different security mechanisms that stem from their designs. However, the goals of Consuls security are to provide confidentiality, integrity and authentication.
2014-02-08 00:41:03 +00:00
---
# Security Model
2014-02-20 20:26:50 +00:00
Consul relies on both a lightweight gossip mechanism and an RPC system
to provide various features. Both of the systems have different security
2014-04-09 18:06:27 +00:00
mechanisms that stem from their designs. However, the goals
2014-02-20 20:26:50 +00:00
of Consuls security are to provide [confidentiality, integrity and authentication ](http://en.wikipedia.org/wiki/Information_security ).
2014-02-08 00:41:03 +00:00
2014-04-09 18:06:27 +00:00
The [gossip protocol ](/docs/internals/gossip.html ) is powered by [Serf ](http://www.serfdom.io/ ),
2014-02-20 20:26:50 +00:00
which uses a symmetric key, or shared secret, cryptosystem. There are more
details on the security of [Serf here ](http://www.serfdom.io/docs/internals/security.html ).
The RPC system supports using end-to-end TLS, with optional client authentication.
[TLS ](http://en.wikipedia.org/wiki/Transport_Layer_Security ) is a widely deployed asymmetric
cryptosystem, and is the foundation of security on the Internet.
This means Consul communication is protected against eavesdropping, tampering,
or spoofing. This makes it possible to run Consul over untrusted networks such
as EC2 and other shared hosting providers.
2014-02-08 00:41:03 +00:00
2014-10-19 23:40:10 +00:00
~> **Advanced Topic!** This page covers the technical details of
2014-02-20 20:26:50 +00:00
the security model of Consul. You don't need to know these details to
operate and use Consul. These details are documented here for those who wish
2014-02-08 00:41:03 +00:00
to learn about them without having to go spelunking through the source code.
## Threat Model
The following are the various parts of our threat model:
2014-02-20 20:26:50 +00:00
* Non-members getting access to data
2014-02-08 00:41:03 +00:00
* Cluster state manipulation due to malicious messages
2014-02-20 20:26:50 +00:00
* Fake data generation due to malicious messages
* Tampering causing state corruption
2014-02-08 00:41:03 +00:00
* Denial of Service against a node
Additionally, we recognize that an attacker that can observe network
traffic for an extended period of time may infer the cluster members.
2014-02-20 20:26:50 +00:00
The gossip mechanism used by Consul relies on sending messages to random
2014-02-08 00:41:03 +00:00
members, so an attacker can record all destinations and determine all
members of the cluster.
When designing security into a system you design it to fit the threat model.
Our goal is not to protect top secret data but to provide a "reasonable"
level of security that would require an attacker to commit a considerable
amount of resources to defeat.