USING KUBE-RBAC-PROXY TO SECURE KUBERNETES WORKLOADS
在使用Prometheus监控Kubernetes集群时，我注意到一个反复出现的问题：Prometheus检索的指标可能包含敏感信息（例如，Prometheus节点导出器暴露了主机的内核版本），潜在的入侵者可能利用这些信息在各自的Kubernetes集群中钻营。所以我问自己一个问题。如何认证和授权来自Prometheus的请求，以便Prometheus（只有Prometheus）能够从Pod中运行的应用程序中检索指标？
在Prometheus中验证和授权指标端点的默认答案是使用TLS客户端证书，然而，由于发行、验证和轮换客户端证书会变得相当复杂，因此，Prometheus请求在大多数情况下根本没有经过验证和授权。
我建立了kube-rbac-proxy，这是一个针对单一上游的小型HTTP代理，可以使用SubjectAccessReviews对Kubernetes API执行RBAC授权。在这篇文章中，我想解释一下，它是如何使用Kubernetes RBAC来完成这个任务的。
RBAC是如何在幕后工作的？
Kubernetes基于角色的访问控制（RBAC）本身只解决了一半的问题。顾名思义，它只涉及访问控制，意味着授权，而不是认证。在一个请求能够被授权之前，它需要被认证。简单地说：我们需要找出谁在执行这个请求。在Kubernetes中，服务自我认证的机制是ServiceAccount令牌。
Kubernetes API公开了验证ServiceAccount令牌的能力，使用所谓的TokenReview。TokenReview的响应仅仅是ServiceAccount令牌是否被成功验证，以及指定的令牌与哪个用户有关。kube-rbac-proxy期望ServiceAccount令牌在Authorization HTTP头中被指定，然后使用TokenReview对其进行验证。
在这一点上，一个请求已经被验证，但还没有被授权。与TokenReview平行，Kuberenetes有一个SubjectAccessReview，它是授权API的一部分。在SubjectAccessReview中，指定了一个预期的行动以及想要执行该行动的用户。在Prometheus请求度量的具体案例中，/metrics HTTP端点被请求。不幸的是，在Kubernetes中这不是一个完全指定的资源，然而，SubjectAccessReview资源也能够授权所谓的 “非资源请求”。但可能性是无穷的，例如：授权一个代理请求，SubjecAccessReview也可以检查以确保用户有服务/代理RBAC角色。
当用Prometheus监控Kubernetes时，那么Prometheus服务器可能已经拥有访问/metrics非资源url的权限，因为从Kubernetes apiserver检索指标需要同样的RBAC角色。
kube-rbac-proxy
现在已经解释了所有必要的部分，让我们看看kube-rbac-proxy是如何具体地验证和授权一个请求的，案例在本博文的开头就已经说明了。普罗米修斯从节点输出器中请求度量。
当Prometheus对node-exporter执行请求时，kube-rbac-proxy在它前面，kube-rbac-proxy用提供的ServiceAccount令牌执行TokenReview，如果TokenReview成功，它继续使用SubjectAccessReview来验证，ServiceAccount被授权访问/metrics HTTP端点。
可见，从Prometheus验证和授权请求的整个流程是这样的:
总结
如果你想做的是用一个静态授权配置文件来授权某些请求，你可能想看看kube-rbac-proxy。
虽然在你的工作负载中执行授权可能仍然有用–特别是当需要更精细的或特定的数据访问时–但很高兴知道在Kubernetes中，你有可用的工具，可以让你在花费时间之前走得更远。
