From d9f106b4d18b983e9e2cea93a27a9a8e664d5761 Mon Sep 17 00:00:00 2001 From: Xiang Li Date: Tue, 23 Jul 2013 11:37:39 -0700 Subject: [PATCH 1/8] Update README.md --- README.md | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/README.md b/README.md index e45bf45ef..49cec9525 100644 --- a/README.md +++ b/README.md @@ -223,6 +223,73 @@ We should see the response as an array of items which meas `foo=barbar` is a key-value pair under `/foo` and `foo_dir` is a directory. +#### Using Https between server and client +Kill the previous etcd server. + +```sh +./etcd -clientCert client.crt -clientKey client.key -i +``` +```-i``` is to ignore the previously created default configuration file. +```-clientCert``` and ```-clientKey``` are the key and cert for transport layer security between client and server + +```sh +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -k -v +``` + +You should be able to see the handshake succeed. +``` +... +SSLv3, TLS handshake, Finished (20): +... +``` +And also the response from the etcd server. +```json +{"action":"SET","key":"/foo","value":"bar","newKey":true,"index":3} +``` + +We also can do authentication using CA cert. The clients will also need to provide their cert to the server. The server will check whether the cert is signed by the CA and decide whether to serve the request. + +```sh +./etcd -clientCert client.crt -clientKey client.key -clientCAFile clientCA.crt -i +``` + +```-clientCAFile``` is the path to the CA cert. + +Try the same request to this server. +```sh +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -k -v +``` + +The request should be rejected by the server. +``` +... +routines:SSL3_READ_BYTES:sslv3 alert bad certificate +... +``` + +We need to give the CA signed cert to the server. +```sh +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -k -v --key myclient.key --cert myclient.crt +``` + +You should able to see +``` +... +SSLv3, TLS handshake, CERT verify (15): +... +TLS handshake, Finished (20) +``` + +And also the response from the server +```json +{"action":"SET","key":"/foo","value":"bar","newKey":true,"index":3} +``` + +Here is a good page to show you how to create a self-signed CA and generate cert and key. +```url +http://www.g-loaded.eu/2005/11/10/be-your-own-ca/ +``` + ### Setting up a cluster of three machines Next let's explore the use of etcd clustering. We use go-raft as the underlying distributed protocol which provides consistency and persistence of the data across all of the etcd instances. @@ -314,3 +381,9 @@ curl http://127.0.0.1:4002/v1/keys/foo ```json {"action":"GET","key":"/foo","value":"bar","index":5} ``` + +#### Using Https between server and client +We have gave an example to show how to use tls between client and server. +The way same here, except that you need to change ```-client*``` to ```-server*```. +We require all the server using http or https. There should not be a mix. + From f9157a25a5bac71efcc6c8bdf6fe2fa2f2320688 Mon Sep 17 00:00:00 2001 From: Xiang Li Date: Tue, 23 Jul 2013 11:42:36 -0700 Subject: [PATCH 2/8] update readme --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 2d2c0d90f..f1c55d556 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,8 @@ A highly-available key value store for shared configuration and service discover * Fast: benchmarked 1000s of writes/s per instance * Reliable: Properly distributed using Raft -Etcd is written in go and uses the [raft][raft] paxos implementation for high availability. +Etcd is written in go and uses the [raft][raft] consensus algorithm to manage replicated +log for high availability. See [go-etcd][go-etcd] for a native go client. Or feel free to just use curl, as in the examples below. From b1e53c4407fa92775c35506e7fded8fe05308b58 Mon Sep 17 00:00:00 2001 From: Xiang Li Date: Tue, 23 Jul 2013 12:02:36 -0700 Subject: [PATCH 3/8] Update README.md --- README.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index f1c55d556..77932865c 100644 --- a/README.md +++ b/README.md @@ -239,7 +239,7 @@ We should see the response as an array of items which meas `foo=barbar` is a key-value pair under `/foo` and `foo_dir` is a directory. #### Using Https between server and client -Kill the previous etcd server. +Etcd supports SSL/TLS and client cert authentication for clients to server, as well as server to server communication ```sh ./etcd -clientCert client.crt -clientKey client.key -i @@ -300,7 +300,7 @@ And also the response from the server {"action":"SET","key":"/foo","value":"bar","newKey":true,"index":3} ``` -Here is a good page to show you how to create a self-signed CA and generate cert and key. +This site has a good reference for how to generate self-signed key pairs ```url http://www.g-loaded.eu/2005/11/10/be-your-own-ca/ ``` @@ -398,7 +398,6 @@ curl http://127.0.0.1:4002/v1/keys/foo ``` #### Using Https between server and client -We have gave an example to show how to use tls between client and server. -The way same here, except that you need to change ```-client*``` to ```-server*```. +In the previous example we showed how to use SSL client certs for client to server communication. Etcd can also do internal server to server communication using SSL client certs. To do this just change the ```-client*``` flags to ```-server*```. We require all the server using http or https. There should not be a mix. From 6ce529d6558da428e9f5017258d6770bd84f1988 Mon Sep 17 00:00:00 2001 From: Xiang Li Date: Tue, 23 Jul 2013 12:20:25 -0700 Subject: [PATCH 4/8] Update README.md --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 77932865c..0bfd01528 100644 --- a/README.md +++ b/README.md @@ -248,7 +248,7 @@ Etcd supports SSL/TLS and client cert authentication for clients to server, as w ```-clientCert``` and ```-clientKey``` are the key and cert for transport layer security between client and server ```sh -curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -k -v +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v ``` You should be able to see the handshake succeed. @@ -272,7 +272,7 @@ We also can do authentication using CA cert. The clients will also need to provi Try the same request to this server. ```sh -curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -k -v +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v ``` The request should be rejected by the server. @@ -284,7 +284,7 @@ routines:SSL3_READ_BYTES:sslv3 alert bad certificate We need to give the CA signed cert to the server. ```sh -curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -k -v --key myclient.key --cert myclient.crt +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v --key myclient.key --cert myclient.crt ``` You should able to see From 2774c651c505c824bcacb9001b5eb2805dc07845 Mon Sep 17 00:00:00 2001 From: Xiang Li Date: Tue, 23 Jul 2013 12:59:18 -0700 Subject: [PATCH 5/8] Update README.md --- README.md | 38 +++++++++++++++++++++++++++++--------- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 0bfd01528..7266f0023 100644 --- a/README.md +++ b/README.md @@ -241,14 +241,28 @@ which meas `foo=barbar` is a key-value pair under `/foo` and `foo_dir` is a dire #### Using Https between server and client Etcd supports SSL/TLS and client cert authentication for clients to server, as well as server to server communication +Before that we need to have a CA cert```clientCA.crt``` and signed key pair ```client.crt, client.key``` . + +This site has a good reference for how to generate self-signed key pairs +```url +http://www.g-loaded.eu/2005/11/10/be-your-own-ca/ +``` + ```sh ./etcd -clientCert client.crt -clientKey client.key -i ``` + ```-i``` is to ignore the previously created default configuration file. ```-clientCert``` and ```-clientKey``` are the key and cert for transport layer security between client and server ```sh -curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v -k +``` + +or + +```sh +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v -cacert clientCA.crt ``` You should be able to see the handshake succeed. @@ -272,7 +286,12 @@ We also can do authentication using CA cert. The clients will also need to provi Try the same request to this server. ```sh -curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v -k +``` +or + +```sh +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v -cacert clientCA.crt ``` The request should be rejected by the server. @@ -284,7 +303,13 @@ routines:SSL3_READ_BYTES:sslv3 alert bad certificate We need to give the CA signed cert to the server. ```sh -curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v --key myclient.key --cert myclient.crt +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v --key myclient.key --cert myclient.crt -k +``` + +or + +```sh +curl https://127.0.0.1:4001/v1/keys/foo -d value=bar -v --key myclient.key --cert myclient.crt -cacert clientCA.crt ``` You should able to see @@ -300,11 +325,6 @@ And also the response from the server {"action":"SET","key":"/foo","value":"bar","newKey":true,"index":3} ``` -This site has a good reference for how to generate self-signed key pairs -```url -http://www.g-loaded.eu/2005/11/10/be-your-own-ca/ -``` - ### Setting up a cluster of three machines Next let's explore the use of etcd clustering. We use go-raft as the underlying distributed protocol which provides consistency and persistence of the data across all of the etcd instances. @@ -399,5 +419,5 @@ curl http://127.0.0.1:4002/v1/keys/foo #### Using Https between server and client In the previous example we showed how to use SSL client certs for client to server communication. Etcd can also do internal server to server communication using SSL client certs. To do this just change the ```-client*``` flags to ```-server*```. -We require all the server using http or https. There should not be a mix. +If you are using SSL for server to server communication, you must use it on all instances of etcd. From ccd98ec009d3c435213714b74bc87ca5b2a6664e Mon Sep 17 00:00:00 2001 From: Xiang Li Date: Tue, 23 Jul 2013 13:00:36 -0700 Subject: [PATCH 6/8] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 7266f0023..6aa584856 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ A highly-available key value store for shared configuration and service discover * Fast: benchmarked 1000s of writes/s per instance * Reliable: Properly distributed using Raft -Etcd is written in go and uses the [raft][raft] consensus algorithm to manage replicated +Etcd is written in go and uses the [raft][raft] consensus algorithm to a manage replicated log for high availability. See [go-etcd][go-etcd] for a native go client. Or feel free to just use curl, as in the examples below. @@ -238,7 +238,7 @@ We should see the response as an array of items which meas `foo=barbar` is a key-value pair under `/foo` and `foo_dir` is a directory. -#### Using Https between server and client +#### Using HTTPS between server and client Etcd supports SSL/TLS and client cert authentication for clients to server, as well as server to server communication Before that we need to have a CA cert```clientCA.crt``` and signed key pair ```client.crt, client.key``` . From b9fa9e2f0041b54c9f6a0597264d8f6c1af12e50 Mon Sep 17 00:00:00 2001 From: Xiang Li Date: Tue, 23 Jul 2013 13:02:29 -0700 Subject: [PATCH 7/8] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 6aa584856..f7827ee46 100644 --- a/README.md +++ b/README.md @@ -417,7 +417,7 @@ curl http://127.0.0.1:4002/v1/keys/foo {"action":"GET","key":"/foo","value":"bar","index":5} ``` -#### Using Https between server and client +#### Using HTTPS between servers In the previous example we showed how to use SSL client certs for client to server communication. Etcd can also do internal server to server communication using SSL client certs. To do this just change the ```-client*``` flags to ```-server*```. If you are using SSL for server to server communication, you must use it on all instances of etcd. From d17fec82341fc83e0d33928740007e604ee1667e Mon Sep 17 00:00:00 2001 From: Xiang Li Date: Tue, 23 Jul 2013 13:10:54 -0700 Subject: [PATCH 8/8] Update README.md --- README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index f7827ee46..9692c76e7 100644 --- a/README.md +++ b/README.md @@ -7,8 +7,7 @@ A highly-available key value store for shared configuration and service discover * Fast: benchmarked 1000s of writes/s per instance * Reliable: Properly distributed using Raft -Etcd is written in go and uses the [raft][raft] consensus algorithm to a manage replicated -log for high availability. +Etcd is written in go and uses the [raft][raft] consensus algorithm to manage a highly availably replicated log. See [go-etcd][go-etcd] for a native go client. Or feel free to just use curl, as in the examples below.