在AKS中使用pod identity获取token - 简介

在AKS中使用pod identity获取token - 简介

pod identity是个啥，我估计大部分人可能都不是很清楚，一般情况下可能也用不到，而且也不是必须要用到，pod identity实际上是帮助简化了身份验证的流程，或者说是解耦可能更合适一点，它适用的场景其实是特指在应用程序需要和Azure进行交互，获取token时，这种场景就可以用到pod identity

举个例子，比如我们自己写了一个application，跑在AKS或者K8S上，这个程序会把数据存储在blob里，而application要想在blob中存储数据，只要blob不是公开的，那么就需要有权限才能写数据到blob，获取权限的方式有很多，比如storage account的key，或者service principal等等，但是无一例外，这些获取权限的方式都是代码级别的，需要编写对应代码来实现，而pod identity其实类似于抽象出来的一层，可以代替我们维护token的获取，refresh等等工作，业务代码不需要任何的变更。pod identity项目中是这么描述的

​without any code modifications, your containerized applications can leverage any resource in the cloud that depends on AAD as an identity provider.

​另外，这种授权方式是pod级别的，可以更精确的控制权限的划分，尽量做到最小权限模型​

下边这张图算是pod identity的架构图，里边描述了pod identity的一些核心组件，以及对应的作用

最为关键的两个组件分别是：

​Managed Identity Controller (MIC)​

MIC会通过K8S API Server监控pod, AzureIdentity , AzureIdentityBindings 的变动，然后新增/修改/删除AzureAssignedIdentity

​Node Managed Identity (NMI)​

NMI用于通过ADAL库和Azure交互，实现token的获取，pod中生成token的操作，都会通过iptables转发给NMI，然后NMI验证pod的信息，之后代为获取token

除了这两个之外，还有包括AzureIdentity，AzureIdentityBinding这两个必须知道的概念，这两个其实是K8S中pod identity自定义的resource，可以简单理解为K8S里Role和role binding的概念，也就是一个定义权限，一个定义授权给谁。azure identity其实定义的就是我们要给pod使用哪个identity，可以是service principal，也可以是managed identity，这里的managed identity必须是user assigned，system assigned identity是不支持的，而AzureIdentityBinding定义的就是要把这个权限assign给哪个pod

一般情况下，使用pod identity的流程大致如下：

现在AKS Cluster上部署pod identity的component，其实就是部署了很多service account以及MIC，NMI的pod，和最重要的CRD的资源管理员创建azureIdentity，定义要assume的service principal或者msi管理员创建azureIdentityBinding，指定要给哪类pod使用创建pod，确保满足azureIdentityBinding定义的条件

整体流程其实并不复杂，之后我们可以用官方的sample实际演示下用法

另外pod identity的社区团队不久前其实刚刚宣布，pod identity之后会被Azure Workload Identity取代，这点其实还挺尴尬，我们刚介绍，这个产品就要被替代了，不过新产品估计还要一段时间才能成熟，pod identity完全可以再撑一段不短的时间，之后有机会也可以研究下这个Workload Identity，看看是不是真的有很大的变化

接下来的内容，还是会围绕pod identity展开，来看下这玩意实际到底怎么用

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。