小玩闹：给 Node Exporter 加上 Basic 认证
前两天在成老师群里问了个无聊的问题——Node Exporter 输出的数据，是不是就应该匿名获取呢？本着 0 信任原则，缺省情况下使用 Host Network 的 Node Exporter 暴露的端口的确是令人稍有不安的，那么如何改善呢？
Node Exporter 新版本中提供了一个 TLS 认证的实验性功能，恰好 Prometheus 也是支持双向 TLS 认证的。不过很多服务会通过 Endpoint 方式提供 Exporter 服务，用 Nginx Sidecar 会是个更加通用的方式。下面举个简单的例子，其他的 Exporter 也可以照猫画虎，并且 Nginx 很成熟，完全可以提供其他更丰富的认证能力。
首先使用 Helm 安装 Prometheus：
helm install stable/prometheus \
--generate-name \
--set alertmanager.enabled=false\
--set nodeExporter.hostNetwork=false \
--set pushgateway.enabled=false \
--set server.persistentVolume.enabled=false启动之后，会生成一组 Prometheus 组件的资源对象， 要修改的包括几个项目：
- 生成 Basic 认证所需的文件
- 为 Nginx 编写反向代理配置
- 以 Sidecar 的形式把 Nginx 加入 Node Exporter 的 Pod 中
- 变更 Node Exporter 的抓取配置
- 变更 Prometheus 的采集参数
可以使用 htpasswd 工具生成密码文件，例如：htpasswd -c -m passwd.dat admin。
接下来编写一个配置文件片段：
server {
listen 9101;
server_name localhost;
auth_basic "login";
auth_basic_user_file /etc/nginx/conf.d/passwd.dat;
location / {
root /usr/share/nginx/html;
proxy_pass http://127.0.0.1:9100;
}
}这里使用一个非常简单的配置，引用前面生成的密码文件进行验证，并且对来自 9091 端口的请求，转发到同一个 Pod 中 9100 端口的 Node Exporter 上。
用前面的两个文件生成 Configmap 供容器引用：
kubectl create configmap nginx-config \
--from-file=proxy.conf --from-file=passwd.dat生成 Nginx 配置之后，就需要把 Nginx 加入 NodeExporter 了，可以使用 kubectl edit 在线编辑，或者导出 YAML，加入如下内容：
spec:
containers:
...
- image: nginx:stable-alpine
ports:
- containerPort: 9101
name: proxy
protocol: TCP
name: nginx
volumeMounts:
- mountPath: /etc/nginx/conf.d
name: nginx-config
readOnly: true
...
volumes:
...
- name: nginx-config
configMap:
name: nginx-config因为端口发生了变化，所以还需要修改 Service 的抓取标签，注解中加入：
annotations:
prometheus.io/port: "9101"
prometheus.io/scrape: "true"最后修改 Prometheus 的配置，在 kubernetes-service-endpoints 加入如下内容：
- job_name: kubernetes-service-endpoints
basic_auth:
username: admin
password: password重启 Prometheus，之后，可以看到工作还是继续进行，但是使用 CURL 访问会得到 401：
$ curl http://192.168.14.252:9101/metrics
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.16.1</center>
</body>
</html>以此类推，如果在 Nginx 中引入 TLS 双向认证，还可以使用 CA 的方式对认证过程进行进一步的集中管理，让更多的 Exporter 进入管理范围。