The security model for Consul Core details requirements and recommendations for securing your deployment of Consul. Learn about potential threats and how to protect Consul from malicious actors.
---
## Overview
# Consul security model overview
Consul enables automation of network configurations, service discovery, and secure network connectivity across any
cloud or runtime.
@ -32,7 +32,7 @@ environment, but the general mechanisms for a secure Consul deployment revolve a
- **Sentinel Policies** <EnterpriseAlert inline /> - Sentinel policies enable policy-as-code for granular control over
the built-in key-value store.
### Personas
## Personas
It helps to consider the following types of personas when managing the security requirements of a Consul deployment.
The granularity may change depending on your team's requirements.
@ -60,14 +60,14 @@ The granularity may change depending on your team's requirements.
be public facing on the internet such as a web server, typically through a load-balancer, or ingress gateway. This is
someone who should not have any network access to the Consul agent APIs.
### Secure Configuration
## Secure Configuration
Consul's security model is applicable only if all parts of the system are running with a secure configuration; **Consul
is not secure-by-default.** Without the following mechanisms enabled in Consul's configuration, it may be possible to
abuse access to a cluster. Like all security considerations, administrators must determine what is appropriate for their
environment and adapt these configurations accordingly.
#### Requirements
## Requirements
- **mTLS** - Mutual authentication of both the TLS server and client x509 certificates prevents internal abuse through
unauthorized access to Consul agents within the cluster.
@ -212,7 +212,7 @@ environment and adapt these configurations accordingly.
commands across the cluster. This is disabled by default since 0.8.0. We recommend leaving it disabled. If enabled,
extreme care must be taken to ensure correct ACLs restrict access to execute arbitrary code on the cluster.
#### Recommendations
## Recommendations
- **Rotate Credentials** - Using short-lived credentials and rotating them frequently is highly recommended for
production environments to limit the blast radius from potentially compromised secrets, and enabling basic auditing.
@ -307,7 +307,7 @@ environment and adapt these configurations accordingly.
}
```
### Threat Model
## Threat Model
The following are parts of the core Consul threat model:
@ -381,7 +381,7 @@ The following are not part of the threat model for client agents:
endpoint. If any of this isn't performed correctly, the proxy or service may allow unauthenticated or unauthorized
connections.
#### Internal Threats
## Internal Threats
- **Operator** - A malicious internal Consul operator with a valid mTLS certificate and ACL token may still be a threat
to your cluster in certain situations, especially in multi-team deployments. They may accidentally or intentionally
@ -409,7 +409,7 @@ The following are not part of the threat model for client agents:
information. When ACLs and HTTPS are enabled, the gRPC endpoint serving up the xDS service requires (m)TLS and a
valid ACL token.
#### External Threats
## External Threats
- **Agents** - External access to the Consul agent's various network endpoints should be considered including the
gossip, HTTP, RPC, and gRPC ports. Furthermore, access through other services like SSH or `exec` functionality in
Security models are the set of requirements and recommendations for securely operating a Consul deployment. Learn about security models and how they differ between environments.
---
## Overview
# Security models overview
Requirements and recommendations for operating a secure Consul deployment may vary drastically depending on your
intended workloads, operating system, and environment. Consul is not secure by default, but can be configured to satisfy
the security requirements for a wide-range of use cases from local developer environments without any configuration to
container orchestrators in-production with ACL authorization, and mTLS authentication.
### Core
## Core
The core Consul product provides several options for enabling encryption, authentication, and authorization
controls for a cluster. You can read more about the various personas, recommendations, requirements, and threats
The NIA security model details requirements and recommendations for securing your Consul-Terraform-Sync (CTS) deployment. Learn about potential threats and how to protect CTS from malicious actors.
Network Infrastructure Automation (NIA) enables dynamic updates to network infrastructure devices triggered by service changes using the [Consul Terraform Sync](https://github.com/hashicorp/consul-terraform-sync) (`consul-terraform-sync`) daemon. This daemon uses Consul's catalog to monitor networking information about services along with [Terraform](https://www.terraform.io/)'s provider ecosystem to apply relevant changes to network infrastructure.
@ -13,7 +13,7 @@ The [Secure Consul-Terraform-Sync for Production](/consul/tutorials/network-infr
tutorial contains a checklist of best practices to secure your
Consul-Terraform-Sync installation for a production environment.
### Personas
## Personas
When considering Consul NIA's security model, it helps to think of the following personas.
@ -32,7 +32,7 @@ When considering Consul NIA's security model, it helps to think of the following
have no knowledge or access to the daemon's API endpoints, ACL tokens, certificates, or any other
piece of the system.
### Secure Configuration
## Secure Configuration
Consul NIA's security model is applicable only if all parts of the system are running with a secure
configuration; `consul-terraform-sync` is not secure-by-default. Without the following mechanisms enabled in the
@ -40,7 +40,7 @@ daemon's configuration, it may be possible to abuse access to the daemon. Like a
considerations, one must determine what concerns are appropriate for their environment, and adapt these
security concerns accordingly.
#### Requirements
## Requirements
- **Protect Configuration Files and Directories** - A dedicated NIA user and group with limited
permissions should be created for production, along with directory, and file permissions appropriately
@ -68,7 +68,7 @@ security concerns accordingly.
- **Read** permission for Consul Catalog for all of the selected services to be monitored, and their namespaces.
- **Read + Write** permission to update health checks, when using NIA health monitoring.
#### Recommendations
## Recommendations
- **Use Dedicated Host** - The NIA daemon will potentially have access to critical secrets for your environment's
network infrastructure. Using a hardened, dedicated host, for supporting these sensitive operations is highly recommended.
@ -85,7 +85,7 @@ security concerns accordingly.
are configured with the NIA daemon should be audited to ensure you're only using providers from sources that
you trust.
### Threat Model
## Threat Model
The following are the parts of the NIA threat model:
@ -131,7 +131,7 @@ a production deployment:
- **Access to the Consul-Terraform-Sync Binary** - Direct access to the system binary used to start the NIA daemon can allow
an attacker to extract sensitive information.
#### Internal Threats
## Internal Threats
- **NIA Operator** - Someone with access to the NIA Host, and it's related binaries or configuration files may be a
threat to your deployment, especially considering multi-team deployments. They may accidentally or intentionally use a
@ -150,7 +150,7 @@ a production deployment:
means. Extra steps to configuring OS, cluster, service, user, directory, and file permissions are essential steps for
implementing defense-in-depth within a production environment.
#### External Threats
## External Threats
- **Terraform Providers and Modules** - Potentially malicious providers or modules, or any malicious dependencies part
of the Terraform ecosystem could cause harm to the network, and may have access to secrets in order to make necessary
Jeff Boruszak
6 months ago
committed by