I've been tinkering with the most recent version of etcd namely 3.5.0 recently, having built it from their GitHub project.
My initial and main requirement was to test etcd with SSL/TLS, specifically both server-side X509 certificate-based encryption ( to validate endpoint integrity and on-the-wire data encryption ) AND client-side certificate-based authentication ( to ensure that only authenticated clients could access the etcd service ).
Having got this done and dusted, albeit with a self-signed certificate process, with a locally-created Certificate Authority (CA) being used to create the keys and certificates being presented: -
(a) by the etcd server to its clients
(b) the client consuming etcd, both via its REST APIs, being consumed by curl and also the native etcdctl utility.
Now I'm looking at the REST API in more depth, having previously only tested the /version endpoint: -
curl --silent --cacert /root/ssl/ca-cert.pem --cert /root/ssl/client-cert.pem --key /root/ssl/client-key.pem https://localhost:2379/version | jq
I then wanted to try sending data to, and receiving data from, etcd again using its REST APIs, recognising that the purpose of etcd is: -
etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines.
Thankfully, the etcd documentation does cover this nicely: -
Interestingly, this uses the POST HTTP method for almost all of the operations, both PUT and GET, which was new to me ...
The documentation does cover this: -
Interestingly, we have this: -
The gateway accepts a JSON mapping for etcd’s protocol buffer message definitions. Note that key and value fields are defined as byte arrays and therefore must be base64 encoded in JSON. The following examples use curl, but any HTTP/JSON client should work all the same.
Source: Using gRPC gateway
Using a test JSON document: -