我们知道在APM架构图中：
APM Agents 访问APM server如果不做安全的设置，那么任何一个应用都有可能把数据传输到APM server中。如果是恶意的软件，那么我们可能得到的数据是错误的。那么怎么保证我们的安全传输呢？
答案是在传输的时候使用secret token。
Secret token 是什么？
您可以配置一个Secret token来授权对APM服务器的请求。 这样可以确保只有您的Agent才能将数据发送到您的APM服务器。 代理和APM服务器都必须配置相同的Secret toke，并且scecret token仅在与SSL/TLS结合使用时才提供安全性。
要使用Secret token 保护APM代理与APM服务器之间的通信安全：
在APM服务器中启用SSL/TLS
在Agent和服务器中设置Secret token
在APM agent中启用HTTPS
实战练习
接下来，我们按照上面的步骤来操作演示是如何实现的。
按照Elasticsearch， Kibana 及 APM server
如果你还没有安装好自己的Elasticsearch, Kibana及APM服务器的话，你可以参阅我之前的文章“Solutions：应用程序性能监控/管理(APM)实践”进行安装。
生成证书
安装上面的要求，我们需要启动SSL/TLS。我们必须有自己的证书。我们在Elasticsearch安装的根目录下打入如下的命令：
./bin/elasticsearch-certutil ca --pem
$ pwd
/Users/liuxg/elastic3/elasticsearch-7.6.2
$ ./bin/elasticsearch-certutil ca --pem
This tool assists you in the generation of X.509 certificates and certificate
signing requests for use with SSL/TLS in the Elastic stack.
The 'ca' mode generates a new 'certificate authority'
This will create a new X.509 certificate and private key that can be used
to sign certificate when running in 'cert' mode.
Use the 'ca-dn' option if you wish to configure the 'distinguished name'
of the certificate authority
By default the 'ca' mode produces a single PKCS#12 output file which holds:
* The CA certificate
* The CA's private key
If you elect to generate PEM format certificates (the -pem option), then the output will
be a zip file containing individual files for the CA certificate and private key
Please enter the desired output file [elastic-stack-ca.zip]:
就像上面显示的那样，上面的命令将会生成一个名字叫做elastic-stack-ca.zip的文件。我们接着使用如下的命令把上面的文件进行解压：
unzip elastic-stack-ca.zip
$ pwd
/Users/liuxg/elastic3/elasticsearch-7.6.2
liuxg:elasticsearch-7.6.2 liuxg$ unzip elastic-stack-ca.zip
Archive: elastic-stack-ca.zip
creating: ca/
inflating: ca/ca.crt
inflating: ca/ca.key
在上面，我们可以看到在当前的目录下生成了一个新的目录ca，里面含有两个文件：ca.crt及ca.key。请注意这里的ca.crt证书将在我们一下的agent里将会被用到。 接下来，我们按照如下的命令来生成证书：
./bin/elasticsearch-certutil cert --ca-cert ./ca/ca.crt --ca-key ./ca/ca.key --pem --name localhost
$ pwd
/Users/liuxg/elastic3/elasticsearch-7.6.2
$ ./bin/elasticsearch-certutil cert --ca-cert ./ca/ca.crt --ca-key ./ca/ca.key --pem --name localhost
This tool assists you in the generation of X.509 certificates and certificate
signing requests for use with SSL/TLS in the Elastic stack.
The 'cert' mode generates X.509 certificate and private keys.
* By default, this generates a single certificate and key for use
on a single instance.
* The '-multiple' option will prompt you to enter details for multiple
instances and will generate a certificate and key for each one
* The '-in' option allows for the certificate generation to be automated by describing
the details of each instance in a YAML file
* An instance is any piece of the Elastic Stack that requires an SSL certificate.
Depending on your configuration, Elasticsearch, Logstash, Kibana, and Beats
may all require a certificate and private key.
* The minimum required value for each instance is a name. This can simply be the
hostname, which will be used as the Common Name of the certificate. A full
distinguished name may also be used.
* A filename value may be required for each instance. This is necessary when the
name would result in an invalid file or directory name. The name provided here
is used as the directory name (within the zip) and the prefix for the key and
certificate files. The filename is required if you are prompted and the name
is not displayed in the prompt.
* IP addresses and DNS names are optional. Multiple values can be specified as a
comma separated string. If no IP addresses or DNS names are provided, you may
disable hostname verification in your SSL configuration.
* All certificates generated by this tool will be signed by a certificate authority (CA).
* The tool can automatically generate a new CA for you, or you can provide your own with the
-ca or -ca-cert command line options.
By default the 'cert' mode produces a single PKCS#12 output file which holds:
* The instance certificate
* The private key for the instance certificate
* The CA certificate
If you specify any of the following options:
* -pem (PEM formatted output)
* -keep-ca-key (retain generated CA key)
* -multiple (generate multiple certificates)
* -in (generate certificates from an input file)
then the output will be be a zip file containing individual certificate/key files
Please enter the desired output file [certificate-bundle.zip]:
Certificates written to /Users/liuxg/elastic3/elasticsearch-7.6.2/certificate-bundle.zip
This file should be properly secured as it contains the private key for
your instance.
After unzipping the file, there will be a directory for each instance.
Each instance has a certificate and private key.
For each Elastic product that you wish to configure, you should copy
the certificate, key, and CA certificate to the relevant configuration directory
and then follow the SSL configuration instructions in the product guide.
For client applications, you may only need to copy the CA certificate and
configure the client to trust this certificate.
在上面的命令中，我们生产一个绑定localhost的证书，也即是说这个证书只能在当前的localhost中进行使用。就像上面显示的那样，它在当前的目录中生产一个叫做certificate-bundle.zip的文件。这文件含有我们所需要的证书信息。我们使用如下的命令来解压缩这个文件：
unzip certificate-bundle.zip
$ pwd
/Users/liuxg/elastic3/elasticsearch-7.6.2
liuxg:elasticsearch-7.6.2 liuxg$ unzip certificate-bundle.zip
Archive: certificate-bundle.zip
creating: localhost/
inflating: localhost/localhost.crt
inflating: localhost/localhost.key
从上面，我们可以看出来它在localhost中生成了我们想要的证书文件localhost.crt及localhoset.key。我们把这两个文件拷入到我们的APM 服务器安装的根目录中。在APM服务器的安装目录中，我可以看到：
$ pwd
/Users/liuxg/elastic3/apm-server-7.6.2-darwin-x86_64
liuxg:apm-server-7.6.2-darwin-x86_64 liuxg$ ls
LICENSE.txt apm-server data key.pem localhost.key
NOTICE.txt apm-server.yml fields.yml kibana
README.md certificate.pem ingest localhost.crt
另注：我们可以使用如下的命令把一个.crt的证书转换为一个.pem的证书：
openssl x509 -in mycert.crt -out mycert.pem -outform PEM
配置APM 服务器
我们在这一步需要为我们的APM服务器配置SSL/TLS。我们使用一个我们喜欢的编辑器，打开apm-server.yml文件，并把如下的配置加到该文件的最后面：
apm-server.ssl.enabled: true
apm-server.secret_token: "123456"
apm-server.ssl.key: "localhost.key"
apm-server.ssl.certificate: "localhost.crt"
在上面，我们打开了，设置了token为123456，同时也把证书加入了。
通过上面的配置后，我们重新启动我们的APM server:
./apm-server -e
如果你配置正确的话，那么你可以看到如下的画面：
如果你的证书不正确的话，那么在这个输出中你将会看到很多说证书不正确的信息。
测试APM agent
在今天的测试中，我们将使用我之前的例子“Solutions：为Nodejs微服务提供APM功能”。我们通过如下的方法下载测试应用：
git clone https://github.com/liu-xiao-guo/apm-zipcode-microservice
我们把server.js文件中的这个部分作如下的修改：
// Add this to the VERY top of the first file loaded in your app
var apm = require('elastic-apm-node').start({
// Override service name from package.json
// Allowed characters: a-z, A-Z, 0-9, -, _, and space
serviceName: 'zipcode service',
// Use if APM Server requires a token
secretToken: '1234561',
// Set custom APM Server URL (default: http://localhost:8200)
serverUrl: 'http://localhost:8200'
verifyServerCert: true,
serverCaCertFile: "localhost.crt"
})
在上面，我们同时加入了如下的两行：
verifyServerCert: true,
serverCaCertFile: "localhost.crt"
如上面所示，我们需要把之前生成的ca.crt证书拷入到该应用的根目录中：
$ pwd
/Users/liuxg/nodejs/apm/zipcode-microservice-node
liuxg:zipcode-microservice-node liuxg$ ls
LICENSE ca.crt package.json
README.md node_modules server.js
api package-lock.json service
等修改完后，我们重新启动我们的nodejs应用：
npm start
如果我们的证书配置正确的话，那么我们可以看到如下的画面：
如果我们的证书设置不正确的话，那么我们将会看到连接错误等等这样的信息。
在我们的浏览器中打入如下的地址：
http://localhost:3000/distance/84010/97229
我们在Kibana中的APM应用中可以看到：
从上面我们可以看出来我们的微服务的调用情况。
为了验证我们的Secret token是否已经起作用，我们可以使用一个不相匹配的Secret token，比如1234561111：
// Add this to the VERY top of the first file loaded in your app
var apm = require('elastic-apm-node').start({
// Override service name from package.json
// Allowed characters: a-z, A-Z, 0-9, -, _, and space
serviceName: 'zipcode service',
// Use if APM Server requires a token
secretToken: '1234561111',
// Set custom APM Server URL (default: http://localhost:8200)
serverUrl: 'https://localhost:8200',
verifyServerCert: true,
serverCaCertFile: "/Users/liuxg/nodejs/apm/zipcode-microservice-node/ca.crt"
})
那么重新启动我们的nodejs应用，那么我将会看到如下的画面：
上面标明我们的Secret token是起作用的。
————————————————
版权声明：本文为CSDN博主「Elastic 中国社区官方博客」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://elasticstack.blog.csdn.net/article/details/105527468