Introduction
Some Couchbase deployments require secure communications between nodes across the network, this could be due to reasons like data governance policies or regulatory compliance. Internet Protocol Security (IPsec) is a protocol suite for secure Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. IPsec can be used in protecting data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host). The goal of this article is to give Couchbase Administrators a quick start on how to configure IPsec across nodes in a Couchbase cluster.
IPsec Modes
IPSec has two modes: tunnel mode and transport mode. The most widely used is tunnel mode, which is usually used for VPN setups (creating tunnel network device in process). Tunnel mode is not practical for a Couchbase cluster, as it would require creating and maintaining tunnels between all pairs of nodes.
Transport mode is needed when securing communication across nodes in the same network. It allows use of IPsec on a per-packet basis. Completely transparently for applications.
IPSec can provide authentication of packets (i.e. ensure that packets that are received are packets from trusted nodes) and encryption of packets. Transport mode and associated Security Policy Database entries allow setting up behavior required for a Couchbase cluster:
-
specific kinds of incoming packets are only accepted if encapsulated in ipsec and valid (dropped otherwise)
-
specific kinds of outgoing packets are required to be encapsulated in ipsec
Usually “specific kind” is going to be something like: all packets from/to couchbase cluster network segment. Or it can be something like all: all packets to/from couchbase service ports.
Requirements
-
Linux Distribution (Debian is used for this blog). Windows does support IPsec, this was not tested.
- Linux Openswan U2.6.32/K2.6.32-573.el6.x86_64 (netkey) or higher
- Couchbase 4.1 or higher
- Sudo/root user access to the system
Installation and Configuration of OpenSwan
From the command line using sudo, the following command was run on each node. For other linux distro use your appropriate package manager.
# sudo apt-get update
# sudo apt-get install openswan
The installer may prompt the user to create a x.509 certificate, do not create a x.509 certificate. IPsec needs to configured for transport mode. In the demonstration environment created for this blog, we have two nodes: 10.0.2.4 and 10.0.2.5.
Steps
1 – On each node – add a line in the /etc/ipsec.secrets file: ipaddress_node1 ipaddress_node2: PSK “some_key”
2 – Modify the /etc/ipsec.conf file to use *.conf files located in the ipsec.d subdirectory. This allows for easy automation if you need to add nodes to the cluster. Each pair of nodes needs its own entry.
3 – Create a configuration file in the /etc/ipsec.d/ directory with the following information:
conn couchbase
type=transport
authby=secret
left=
right=
pfs=yes
auto=start
- conn couchbase -connection: arbitrary label for your connection. This can be anything you’d like
- type=transport: we want to use transport mode for this connectionauthby=secret: we’ll be using a pre-shared key (PSK) for this connection.
- left=10.0.2.4: this and the next line are just denoting the IP addresses involved in this IPsec association. It does not matter which IP is “left” and which is “right”.
- right=10.0.2.5: see above bullet.
- pfs=yes: we want to enable Perfect Forward Secrecy for this connection. In short, this drastically improves security. Iauto=start: We want to pro-actively initiate the IPsec association immediately. This can also be set to auto=start, in which case it waits for the other end of the connection to initiate traffic.
4 – Enable IPSec to use the new configuration on both nodes: #sudo service ipsec restart
Testing the setup
From a command line on one node, type the following command:
#ping
From the other node, use the command line and type : (desired result) If you get no messages, you will need to debug your setup (please refer to IPsec Guides listed below)
#sudo tcpdump esp
Note: ESP = Encapsulating Security Payload
Couchbase Configuration
Install Couchbase on each node, a simple two node configuration. Set up the cluster. All communication between the two nodes can be traced using the tcpdump esp command, the sample above documents communication between two Couchbase nodes.
Couchbase Test Cluster:
Screenshot – #sudo tcpdump esp
References
IPsec Overview – https://en.wikipedia.org/wiki/IPsec
Implementating IPsec Transport Mode – http://andersonfam.org/2014/04/02/ipsec-transport-mode/
Using StrongSwan (3 node example) – http://blog.sprinternet.at/2016/03/ipsec-transport-mode-with-strongswan-on-debian-jessie/
Sample Configuration Files used for this Test
/etc/ipsec.conf
# /etc/ipsec.conf – Openswan IPsec configuration file
#
# Manual: ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# Debug-logging controls: “none” for (almost) none, “all” for lots.
# klipsdebug=none
# plutodebug=”control parsing”
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
nat_traversal=yes
virtual_private=
oe=off
# Enable this if you see “failed to find any available worker”
# nhelpers=0
#You may put your configuration (.conf) file in the “/etc/ipsec.d/” and uncomment this.
include /etc/ipsec.d/*.conf
/etc/ipsecrets
include /etc/ipsec.d/*.secrets
# use IP addresses from your own environment
10.0.2.4 10.0.2.5: PSK “sharedkey”
/etc/ipsec.d/couchbase.conf
conn couchbase
type=transport
authby=secret
left=10.0.2.4
right=10.0.2.4
pfs=y
auto=start
