Configuring IPsec for a Couchbase Cluster
Want to get your Couchbase cluster in line with IPsec? This guide shows you how to do it.
Join the DZone community and get the full member experience.Join For Free
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 has two modes: tunnel mode and transport mode. the most widely used is tunnel mode, which is usually used for vpn setups (creating a tunnel network device in the 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 the use of ipsec on a per-packet basis — completely transparently for applications.
ipsec can provide authentication of packets (i.e. ensure that all packets received are 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 ipssec 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 a couchbase cluster network segment. or it can be something like all: all packets to/from cuchbase service ports.
- linux distribution (debian is used for this blog). windows does support ipsec, though 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, but do not create a x.509 certificate . ipsec needs to be 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.
on each node, add a line in the /etc/ipsec.secrets file: ipaddress_node1 ipaddress_node2: psk "some_key".
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.
create a configuration file in the /etc/ipsec.d/ directory with the following information:
left=<ip address of node 1>
right=<ipaddress of node 2>
- 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.
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 <other node>
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
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
sample configuration files used for this test
# /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
# debug-logging controls: "none" for (almost) none, "all" for lots.
# plutodebug="control parsing"
# for red hat enterprise linux and fedora, leave protostack=netkey
# enable this if you see "failed to find any available worker"
#you may put your configuration (.conf) file in the "/etc/ipsec.d/" and uncomment this.
# use ip addresses from your own environment
10.0.2.4 10.0.2.5: psk "sharedkey"
Published at DZone with permission of Tim Wong. See the original article here.
Opinions expressed by DZone contributors are their own.