如何区分Pod身份?

我在kubernetes集群中有4个服务作为4个不同的部署/站点运行,分别命名为 A B C 和 D 。 D 提供了一项常见的服务, A B 通过剩余的API调用使用,但是在来自的请求之间行为不同A B 中的那些。对于 C 的请求, D 应该只是拒绝该请求(未经授权)。 是否有k8s内置的方式来支持在集群中识别/授权pod

我目前的方法是使用服务帐户,我在其中创建了两个服务帐户SA1和SA2,分别由 A B 和我的服务 D 已注册为令牌审阅者。 A B 都需要读取服务帐户令牌并将其与请求一起提交给 D 。通过查看令牌, D 可以判断请求是来自 A 还是 B 。这行得通,但是我不确定这是否是实现此目标的最佳方法。由于每个部署只能使用一个服务帐户,因此如果我们获得更多服务,这可能会增加服务帐户管理的复杂性和令牌审查的复杂性。

我浏览了kubernetes文档,例如RBAC,ABAC,节点授权等...但是这些似乎都是为授权集群API访问而设计的,而不是为集群中运行的服务授权的。

azure似乎有一个可以满足我的要求的解决方案https://github.com/Azure/aad-pod-identity,但它也依赖于其他部署(active Directory),我认为我们在集群中不会拥有它。

gsyyyy 回答:如何区分Pod身份?

您所拥有的是正确的, 服务帐户令牌是这样做的方法,其他系统通常建立在它们之上。大多数服务网格工具的确提供了更为简单的身份识别系统,尽管对于这么小的东西,可能会显得过大。

,

在我看来,这更多是关于在同一群集上运行的服务的服务到服务的安全性。

我知道已经有一个解决方案,可以在较小的规模上正常运行,但是担心的是它无法扩展到更多服务。同样,服务似乎也知道它们在Pod容器内的Kubernetes上运行,并且做了一些特殊的工作以使服务帐户令牌的身份验证有效-“ ... A和B都需要读取服务帐户令牌并与请求D”。

@coderanger在回答中提到了服务网格。如果您期望相互调用且必须确保增长的服务数量增加,那么Istio之类的服务网格将非常适合这里。 (我不隶属于Istio)

除了security之外,Istio还提供了很多功能,供用户选择使用或不使用。大规模地,它有助于从中央control plane进行管理,例如,通过自动密钥和证书的提供和轮换进行管理。

使用Istio,无需更改应用程序代码,因为Istio使用Sidecar容器模式在每个应用程序服务容器旁边的同一容器中部署代理;轻量级代理处理安全性,流量管理,遥测...一个很好的“副作用”是,开发人员仍然可以在本地开发和测试这些服务集成,而不必担心安全性。

本文链接:https://www.f2er.com/3115158.html

大家都在问