BSI User-Defined Security Module for Hashicorp Consul

Stephan Kaps
6 min readJul 2, 2021

1 Description

1.1 Introduction

Hashicorp Consul is a server application that supports the use cases service discovery, centralized configuration management and service mesh.
Service discovery is used to find services and their IP address and port in dynamic infrastructures. Services are applications, web services, microservices or infrastructure components. Dynamic means that services that are operated in containers, for example, can (re)start on any host with automatically assigned ports, after a failure or due to scaling requirements.

Services log on to a central registry when they are started. The communication between services is handled by a client agent that must be installed on every server involved in the communication. A service that wants to find another service asks its local client agent for that particular identity. The client agent now communicates with the central registry in order to find out the corresponding (also currently addressable) IP address. The client agent of the inquiring party can then communicate directly with the client agent of the target system of the requested service.
Central configuration management enables configuration values ​​that were previously located in different places to be bundled in a central location. This includes environment variables, values ​​in configuration files or configuration values ​​in the source code. A central administration of configurations by Consul enables all instances of a service direct access to the only true state (single point of truth) and saves or automates a restart of services if the configuration is changed.
Service meshes are an additional, dedicated infrastructure layer to a service and control the communication between services. This includes encryption and identity-based regulation of communication, also known as micro-segmentation. With the latter, so-called intentions are defined with the help of access control lists (ACLs) and assigned to the services registered via the service registry based on their identity (service name instead of IP address).

1.2 Objective

The aim of the module is to protect a Consul cluster and the information that is provided or processed by Consul.

1.3 Not in scope

In this module, the specific threats and requirements for service discovery, service configuration and service mesh are considered. The operation of Consul requires either a physical or virtual server or container, the general security recommendations of which must also be observed (see e.g. SYS.1.3 Server under Linux and Unix, SYS.1.2.2 Windows Server 2012 or SYS.1.6 Container). In addition, the measures from CON.3 data backup concept and OPS.1.1.3 patch and change management must be observed. Since Consul is about general software, the threats from APP.6 General Software also apply here.

2 Threat Landscape

The following specific threats and vulnerabilities are of particular importance for the user-defined module APP.bd.4 Hashicorp Consul:

Remote Code Execution

Malicious code can be executed. An attacker can use the Consul Exec function to execute any commands in the cluster if this functionality, which is deactivated by default, is activated and access is not secured with ACLs.

Unauthorized access to data

Vulnerable information can get into the hands of unauthorized persons if inquiries without authentication and authorization are possible.

Incorrect configuration

Incorrect configuration can allow an attacker with access rights to data or configuration directories to gain access to sensitive data or tokens.

Eavesdropping on communication

If the communication between the agents, the services or between the Consul server and the configured certification authority provider for Connect is not encrypted, the transmission can be eavesdropped.

3 Requirements

3.1 Basic Requirements

APP.bd.4.A1 Protection of confidential data
When using central configurations, NO sensitive data such as access data MUST be stored in plain text.

APP.bd.4.A2 High availability
Since this is a central component, the operation MUST be designed to be highly available (cluster). With virtualization, care SHOULD be taken to ensure that the virtual machines are operated on different hosts. When using container technologies, suitable restart-on-failure mechanisms SHOULD be configured.

APP.bd.4.A3 Secure configuration of the Consul agent
The Consul Agents MUST NOT run with root rights, but only requires access to a data directory.

3.2 Standard Requirements

APP.bd.4.A4 Use of TLS
Communication between agents and the server SHOULD be encrypted. A separate Certification Authority (CA) SHOULD be used.

APP.bd.4.A5 Access restriction through ACLs
Access Control Lists (ACLs) SHOULD be configured to prevent unauthorized use of the User Interface (UI) or the Application Interface (API).

APP.bd.4.A6 Monitoring of the cluster
The Consul-Cluster SHOULD be appropriately monitored, including the integration into central monitoring and log management services. Above all, the availability, resource utilization and error states SHOULD be monitored and recognized.

APP.bd.4.A7 Version management for configurations
Necessary configurations SHOULD not be made manually, but with the help of configuration files. These configuration files SHOULD be available in a central location and integrated into version management and data backup.

APP.bd.4.A8 Gossip Encryption
The standard encrypted Gossip communication SHOULD NOT be deactivated. The necessary keys SHOULD be rotated regularly.

APP.bd.4.A9 Deactivation of script checks
If the HTTP API of the Consul Agents is activated, script checks SHOULD be deactivated to prevent remote code execution.

APP.bd.4.A10 Deactivate remote execution
The ability to execute remote code via Consul exec SHOULD remain disabled.

APP.bd.4.A11 Rotating credentials
Short-lived and regularly rotating credentials SHOULD be used for ACL tokens, certificates and Gossip Keys.

APP.bd.4.A12 Cipher Suites
The currently recommended cipher suites SHOULD be configured. For TLS 1.3, all stored cipher suites are currently considered secure and therefore do not have to be explicitly configured. See also [TR1].

APP.bd.4.A13 HTTP Response Header
Additional security headers SHOULD be configured for HTTP API responses such as B. X-XSS protection.

APP.bd.4.A14 Configuration of suitable connection limits
Connection limits SHOULD be configured for the respective environment, such as simultaneous access by the same client, timeouts or maximum connections.

APP.bd.4.A15 Restriction of service-to-service communication
The communication between services SHOULD be restricted by intent to permitted communication relationships.

APP.bd.4.A16 Automated roll-out / recall of the configuration
The configuration of Consul SHOULD be transferred to the running cluster as automatically as possible.

APP.bd.4.A17 Use of dedicated access
Dedicated access should be used for infrastructure components (e.g. TLS proxies or application scheduler) and explicit access rights should be defined

3.3 Requirements in Case of Increased Protection Needs

APP.bd.4.A18 Use of Mutual TLS (mTLS)
Communication requests to the Consul Agent SHOULD be authenticated and authorized via mTLS.

APP.bd.4.A19 Use of fine-grained ACL policies
The configured ACL policies SHOULD be as fine-grained as possible in order to support the least privileged principle.

APP.bd.4.A20 Active revocation of access rights
The access rights for human users in Consul SHOULD be actively revoked as soon as the user is no longer authenticated or has been deactivated.

4 Additional Information

[DocConsul]: Documentation Consul Security Models, https://www.consul.io/docs/security/security-models/core
[DocConsul2]: Documentation Consul Encryption, https://www.consul.io/docs/security/encryption
[DocConsul3]: Documentation Consul ACL, https://www.consul.io/docs/security/acl
[TR1]: Technical guideline TR-02102–2 Use of Transport Layer Security (TLS), https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=10

5 Cross-reference Table for Elementary Threats

G 0.15 Wiretapping
G 0.18 Bad planning or lack of adaptation
G 0.19 Disclosure of information worthy of protection
G 0.20 Information or products from an unreliable source
G 0.21 Manipulation of hardware or software
G 0.22 Manipulation of information
G 0.23 Unauthorized entry into IT systems
G 0.25 Failure of devices or systems
G 0.27 Lack of resources
G 0.28 Software weaknesses or errors
G 0.29 Violation of laws or regulations
G 0.31 Incorrect use or administration of devices and systems
G 0.39 Malicious programs
G 0.40 Denial of service
G 0.45 Loss of data
G 0.46 Loss of integrity of information worthy of protection

Cross-reference Table for Elementary Threats

Picture from Joseph Mucira from Pixabay

--

--

Stephan Kaps

Leader Softwaredevelopment Bundesamt für Soziale Sicherung — www.kitenco.de — Software-Architect — @kitenco1