mirror of https://github.com/status-im/consul.git
Jeff Boruszak
GitHub
parent
c1a7221406
commit
5f129ad5b2
|
|
@ -5,7 +5,7 @@ description: >-
|
|||
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
|
||||
|
|
|
|||
|
|
@ -5,20 +5,20 @@ description: >-
|
|||
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
|
||||
[here](/consul/docs/security/security-models/core).
|
||||
|
||||
### NIA
|
||||
## NIA
|
||||
|
||||
[Network Infrastructure Automation](/consul/docs/nia) (NIA) enables dynamic updates to network infrastructure devices triggered
|
||||
by service changes. Both the core Consul product's configuration and the configuration for the `consul-terraform-sync`
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: >-
|
|||
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.
|
||||
---
|
||||
|
||||
## Overview
|
||||
# Network Infrastructure Automation (NIA) overview
|
||||
|
||||
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue