TLS authentication
Overview
If necessary, issue a private TLS certificate so that only clients with that TLS certificate can use the ETCD3. You can access the cluster and force it to perform data CRUD.
Create a certificate
Install the necessary tools
cfssl
, cfssljson
installation
#!/bin/bash
CFSSL_VERSION=1.6.5
CFSSL_PATH=/usr/local/bin
ARCH=amd64
curl -L "https://github.com/cloudflare/cfssl/releases/download/v${CFSSL_VERSION}/cfssl_${CFSSL_VERSION}_linux_${ARCH}" -o cfssl
curl -L "https://github.com/cloudflare/cfssl/releases/download/v${CFSSL_VERSION}/cfssljson_${CFSSL_VERSION}_linux_${ARCH}" -o cfssljson
curl -L "https://github.com/cloudflare/cfssl/releases/download/v${CFSSL_VERSION}/cfssl-certinfo_${CFSSL_VERSION}_linux_${ARCH}" -o cfssl-certinfo
chmod +x cfssl cfssljson cfssl-certinfo
sudo cp cfssl cfssljson cfssl-certinfo ${CFSSL_PATH}/
Issue a certificate
Modify the Makefile as needed, as shown below.
On this example, the name template is changed for the
.pem
file that is generated by exporting with thecfssljson
command for ease of file management.
$ vim Makefile
.PHONY: cfssl ca req clean
CFSSL = @env PATH=$(GOPATH)/bin:$(PATH) cfssl
JSON = env PATH=$(GOPATH)/bin:$(PATH) cfssljson
all: ca req
cfssl:
HTTPS_PROXY=127.0.0.1:12639 go get -u -tags nopkcs11 github.com/cloudflare/cfssl/cmd/cfssl
HTTPS_PROXY=127.0.0.1:12639 go get -u github.com/cloudflare/cfssl/cmd/cfssljson
HTTPS_PROXY=127.0.0.1:12639 go get -u github.com/mattn/goreman
ca:
mkdir -p certs
$(CFSSL) gencert -initca config/ca-csr.json | $(JSON) -bare certs/etcd-ca
req:
$(CFSSL) gencert \
-ca certs/etcd-ca.pem \
-ca-key certs/etcd-ca-key.pem \
-config config/ca-config.json \
config/req-csr.json | $(JSON) -bare certs/${infra0}
$(CFSSL) gencert \
-ca certs/etcd-ca.pem \
-ca-key certs/etcd-ca-key.pem \
-config config/ca-config.json \
config/req-csr.json | $(JSON) -bare certs/${infra1}
$(CFSSL) gencert \
-ca certs/etcd-ca.pem \
-ca-key certs/etcd-ca-key.pem \
-config config/ca-config.json \
config/req-csr.json | $(JSON) -bare certs/${infra2}
$(CFSSL) gencert \
-ca certs/etcd-ca.pem \
-ca-key certs/etcd-ca-key.pem \
-config config/ca-config.json \
config/req-csr.json | $(JSON) -bare certs/${infra0}-peer
$(CFSSL) gencert \
-ca certs/etcd-ca.pem \
-ca-key certs/etcd-ca-key.pem \
-config config/ca-config.json \
config/req-csr.json | $(JSON) -bare certs/${infra1}-peer
$(CFSSL) gencert \
-ca certs/etcd-ca.pem \
-ca-key certs/etcd-ca-key.pem \
-config config/ca-config.json \
config/req-csr.json | $(JSON) -bare certs/${infra2}-peer
clean:
rm -rf certs
Modify the certificate CSR (Certificate Signing Request) as needed, as shown below.
Delete the "CN" entry. The Python gRPC gateway that Patroni currently uses as a client to access ETCDs does not support certificates with TLS Common Name applied.
In the
host
entry, enter the IP address and hostname (if necessary) of the ETCD cluster to be configured as an array.
$ vim config/req-csr.json
{
"CN": "etcd", # Delete the Patroni -> etcd connection if you have an encrypted configuration
"hosts": [
"localhost",
"127.0.0.1",
"node1",
"node2",
"node3",
"172.176.0.2",
"172.176.0.3",
"172.176.0.4"
],
"key": {
"algo": "ecdsa",
"size": 384
},
"names": [
{
"O": "autogenerated",
"OU": "etcd cluster",
"L": "the internet"
}
]
}
Modify the certificate authority (CA) CSR as needed, as shown below.
Delete “CN” entry.
Modify the
names
entry as needed, as shown below.
$ vim config/ca-csr.json
{
"CN": "Autogenerated CA",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"O": "TmaxTibero",
"OU": "OpenSQL",
"L": "Seongnam-si",
"ST": "Gyeonggi-do",
"C": "KR"
}
]
}
Execute make
to generate the certificate.
The values of the
infra0
,infra1
, andinfra2
environment variables you set are used as file names for the generated .pem certificate.
$ infra0=node1 infra1=node2 infra2=node3 make
$ ls -l
total 84
-rw-r--r-- 1 yhyjeon yhyjeon 985 1월 6 18:10 etcd-ca.csr
-rw------- 1 yhyjeon yhyjeon 1679 1월 6 18:10 etcd-ca-key.pem
-rw-rw-r-- 1 yhyjeon yhyjeon 1281 1월 6 18:10 etcd-ca.pem
-rw-r--r-- 1 yhyjeon yhyjeon 623 1월 6 18:10 node1.csr
-rw------- 1 yhyjeon yhyjeon 288 1월 6 18:10 node1-key.pem
-rw-rw-r-- 1 yhyjeon yhyjeon 1196 1월 6 18:10 node1.pem
-rw-r--r-- 1 yhyjeon yhyjeon 623 1월 6 18:10 node2.csr
-rw------- 1 yhyjeon yhyjeon 288 1월 6 18:10 node2-key.pem
-rw-rw-r-- 1 yhyjeon yhyjeon 1196 1월 6 18:10 node2.pem
-rw-r--r-- 1 yhyjeon yhyjeon 623 1월 6 18:10 node3.csr
-rw------- 1 yhyjeon yhyjeon 288 1월 6 18:10 node3-key.pem
-rw-rw-r-- 1 yhyjeon yhyjeon 1196 1월 6 18:10 node3.pem
-rw-r--r-- 1 yhyjeon yhyjeon 623 1월 6 18:10 node1-peer.csr
-rw------- 1 yhyjeon yhyjeon 288 1월 6 18:10 node1-peer-key.pem
-rw-rw-r-- 1 yhyjeon yhyjeon 1196 1월 6 18:10 node1-peer.pem
-rw-r--r-- 1 yhyjeon yhyjeon 623 1월 6 18:10 node2-peer.csr
-rw------- 1 yhyjeon yhyjeon 288 1월 6 18:10 node2-peer-key.pem
-rw-rw-r-- 1 yhyjeon yhyjeon 1196 1월 6 18:10 node2-peer.pem
-rw-r--r-- 1 yhyjeon yhyjeon 623 1월 6 18:10 node3-peer.csr
-rw------- 1 yhyjeon yhyjeon 288 1월 6 18:10 node3-peer-key.pem
-rw-rw-r-- 1 yhyjeon yhyjeon 1196 1월 6 18:10 node3-peer.pem
ETCD integration
When executing ETCD, set up
https
connection and certificate through environment variable file/etc/etcd/etcd.env
or command line arguments. Only clients with certificates signed using the certificate authority (CA) certificatesetcd-ca
,etcd-ca-key
that you created can access this ETCD instance.
$ vim /etc/etcd/etcd.env
#/etc/etcd/etcd.env
## Add the following to register the certificate authority and public and private keys of the certificates to be allowed.
## The located .pem certificate is a file that the user who will start the etcd process has read permission to read.
#Cert
ETCD_TRUSTED_CA_FILE=/etc/etcd/pki/etcd-ca.pem
ETCD_CERT_FILE=/etc/etcd/pki/node3.pem
ETCD_KEY_FILE=/etc/etcd/pki/node3-key.pem
ETCD_PEER_TRUSTED_CA_FILE=/etc/etcd/pki/etcd-ca.pem
ETCD_PEER_CERT_FILE=/etc/etcd/pki/node3-peer.pem
ETCD_PEER_KEY_FILE=/etc/etcd/pki/node3-peer-key.pem
Change ADVERTISE_CLIENT_URLS
, LISTEN_CLIENT_URLS
via command line arguments when running /etc/etcd/etcd.env
file or ETCD
http://127.0.0.1:2379
is for use in a local environment and can be deleted if not needed.The #Certs entry registers the certificates issued through the above process. The
peer
is utilized for the client and the rest for the server-side TLS certificates.ETCD_TRUSTED_CA_FILE
: Path to the certificate authority (CA) certificate for the TLS certificate that the server will trust. If a valid certificate is configured, the ETCD server will validate the certificate for all clients. If you are utilizing client authentication without setting up a separate certificate authority, you should utilize theETCD_CLIENT_CERT_AUTH=true
option.ETCD_CERT_FILE
: Path to the TLS certificate to be used for Client - Sever communication.ETCD_KEY_FILE
: TLS Key path to be used for Client - Server communication.ETCD_PEER_TRUSTED_CA_FILE
: Path to the certificate authority (CA) certificate of the TLSfor ETCD peer-to-peer communication.
ETCD_PEER_CERT_FILE
: Path to the TLS certificate to be used for communication between ETCDpeers.
ETCD_PEER_KEY_FILE
: TLS Key path to be used for communication between ETCD Peers.
#/etc/etcd/etcd.env
# ...
ETCD_ADVERTISE_CLIENT_URLS=https://172.18.0.2:2379
ETCD_LISTEN_CLIENT_URLS=https://172.18.0.2:2379,http://127.0.0.1:2379
# ...
#Certs
ETCD_TRUSTED_CA_FILE=/etc/etcd/pki/etcd-ca.pem
ETCD_CERT_FILE=/etc/etcd/pki/node1.pem
ETCD_KEY_FILE=/etc/etcd/pki/node1-key.pem
ETCD_PEER_TRUSTED_CA_FILE=/etc/etcd/pki/etcd-ca.pem
ETCD_PEER_CERT_FILE=/etc/etcd/pki/node1-peer.pem
ETCD_PEER_KEY_FILE=/etc/etcd/pki/node1-peer-key.pem
Last updated