大家好,我是王一可今天很高兴和我的同事袁定平和大家一起分享我们在Kubernetes集群构建中对于控制平面的安全和家库方面的一些思考和想法我们目前就职于微微技术中国研发中心主要工作的话会面向Kubernetes网络方向相关的产品和技术现在回到我们的主题Kubernetes作为容器管理平台目前已经在很多企业落地为了构建Kubernetes集群公有云提供商提供了拖管Kubernetes的服务例如我们常听到的EKS、AKS等等向WinWin也推出了TKG等企业级的产品可以帮助客户在私有云和公有云上去构建Kubernetes平台我们都知道Kubernetes控制平面的核心组件包括有API Server、ETCD还有Controller Manager等等但是为了实现刚才所提到的各个Provider能在其基础设施上能够对集群的生命周期进行管理其实还需要CPI以及CSI例如CPI可以管理集群的节点的生命周期复杂薰红服务的生命周期像CSI可以管理Wallium的生命周期为了介入基础设施还有它上面的存组资源CPI和CSI组件其实是需要基础设施相关的匪单设或者说是全线的所以说在Control Plan上除了存储着集群的管理员的Cubiconfig其实还存在着可以接入基础设施的相关的重要的Create Dancer或者说全线这些Create Dancer存在Control Plan上肯定会带来一些安全的隐患的比如说当这个Control Plan上它装了Cubilot用户或者攻击者其实是可以在Control Plan上去运行一个炮炮的同时去挂载Control Plan上存储着这些敏感信息的Wallium这样的话他们是有机会去拿到基础设施的Create Dancer或者说集群的管理全线Cubiconfig的如果他们拿到了基础设施的Create Dancer那么就可以去接入甚至是操作基础设施这样就会对基础设施带来破坏或者说损失如果他拿到了这个集群管理员的Cubiconfig作为集群中愿意的普通用股他就可以侵入到这个集群中别的区域去创建资源甚至是对这个集群发起攻击另外还有一个就是说这个集群中CSI的话它是需要有特殊的全线才能去操作Wallium的如果说这些全线通过特定的方式获取到以后像攻击者就可以对别的集群甚至是管理集群的Control Plan进行攻击他们可以将这个Control Plan的Wallium保存下来然后就可以拿到其中存储的重要的数据比如说基础设施的Create Dancer或者说别的集群的Cubiconfig等等这样的话就会对基础设施或者说别的集群造成破坏常见的我们保护Control Plan上这些Create Dancer的或者说特殊全线的方法的话一般我们会利用一些全线控制或者说策略控制的机制可以限制普通用户在Control Plan上可以限制他们在这上面的这些危险的行为还有就是可以把CSI Controller去乱在这个Control Plan的外部这样Cluster内部就不需要有CSI的特殊全线最后还有一个就是我们补在这个Control Plan上安装Cubilot这样的话用户就没有办法在Control Plan上去运行炮的那么在常见的各个Provider的解决方案中确实会经常采用不在Control Plan上安装Cubilot这种方式这样的话像这些Cubonatis的Core Components其实只能以Process去运行同时于此同时他们可能还会还会在这个API Server外点部署一个LB这样的话用户和工作起点访问API Server的时候只能通过外部的LB这样的话就可以避免用户直接接触到这个Control Plan上的物理资源最大限度的保护Control Plan的安全像这样以传统的Process方式启动这些Core Components的方式虽然说他们在物理上使他们无法去获取到这些Create Dancer没有办法直接获取到但是也带到一个缺点就是这些Core的Components他们没有办法利用Cubonatis的优势失去了HA的能力在Tribal Shooting的时候也不够灵活基于刚才提到的常用的方案我们就会想还会有更好的办法去解决这样的事情我们是不是也可以将Control Plan上的这些核心组建像刚才的方案一样和工作节点和离开但是核心组建依然是一个Cubonatis Cloud的方式去运行这样的话他们依然可以拥有Cloud Nat5的优势是不是具有这种可能谢谢你实际上现有的方案在解决安全问题本身上面并没有什么的问题那我们为什么要去想新的解决办法呢这主要是因为从18年很多KBS Engine出现到现在KBS社区又有很新的技术出现其中非常重要的一个就是Class的API用KBS创始人就伟大的话来说Class的API要做的事情就是把KBS用来管理工作负载的技术用来管理KBS自己上面我个人的理解这个一方面是对技术的体制追求另外一方面从实践上证明了KBS里面所实现的这些技术是同用的和真正可扩展的如果对Class的API感兴趣的话可以去官方的Class的API布可去承诺了解现在我们回到问题本身其实要解决的问题很简单就是防止CPI和CSI的credentials也就是密码被非法的使用这个图里面是一个现在的KBS的NG的模型我们把它放到一个Class的API的视角下去再去思考这个问题你会发现原来由各个云服务厂上实现的KBSNG现在是由一个KBS的Class来替代了也就是这个management cluster在这个视角下面我们想要保护CPI和CSI的credentials最简单的方法就是把CPI和CSI进行一个托管就是托管给这个新的management cluster在算法上可以算是一个暴力解法但是它是真的解决这个问题的实际上它成功的隐藏了CPI和CSI但是还有两个新的问题需要解决第一当前这个KBS生态里面并不是所谓的Cloud provider都是独立部署的还有很多intro的Cloud provider这一部分是没有办法单独部署的第二就是当我们把CPI和CSI从原有的class里面移到management cluster之后它跟原有的class之间的同一系问题怎么解决目前我们并没有看到一个很好的方案来解决这个问题不过我们再深入思考一下既然已经把CPI和CSI都移出去了我们干脆把class的整个control frame单独放到management cluster里面来部署这样行不行实际上是可行的它也就是我们今天要分享的新思路看起来很简单不过它跟我们的前面的暴力结合有一些类似的问题那最主要的一个就是control frame跟class的node network之间的通信问题要解决这个通信问题我们先来理解一下KBS的control frame跟node network之间是具体如何通信的首先node network需要通过kubernetes这个系统build in the service去访问APS server然后APS server在两种情况下也会主动去访问node network第一它在某些kubernetes的命令执行的时候会去访问kubernetes的端客第二当class的内部部署带有webhook的CRD时它会主动去访问这些aggregation controller的服务端客那我们怎么来解决这两条通信不许问题呢第一从node network访问APS server这个比较简单只需要把APS server作为一个service暴露出来class的node network和它暴露出来端客实现layer所谓的通信就可以了我们再看第二个问题近两年这个社区给出了这个问题的答案就是APS server network proxy在通信的两端各部署一个组建利用这两个组建建立一个隧道这种解决我们的问题有关APS server network proxy的具体工作原理的话可以去github上进行一个深入的了解到这里我们这个问题是不是都解决了实际上我们手动的把class的分别部署到了两个地方但是我们现在要解决的是怎么使用这个kbs engine创建出来的class它本身就像我们现在部署的这个样子我给出了一个给出了一个设计方案的架构图实际上在class的APS的视角下要实现上面我们提到的这种手动部署的过程其实并不复杂第一class的APS它已经提供了两个control manager来负责新集群的创建和状态维护也就是这个图里面紫色的这两个框其次我们需要我们还需要一个class的control manager来负责真正的对云基础设施通信就是图里面中间的这个框它的内部至少有四个control第一个是集群同用状态管理的control就是class的control然后我们如果有withfair我力的话它还需要有三个withfair相关的集群状态管理包括我很多的状态管理以及底层的VM状态管理的control当然还有一些跟identity以及AZ相关的一些control在这里简化就不提了最后我们还需要一个针对control plane的control manager它的内部也有很多这个control第一个control是管理APS over the end point这个很重要因为APS over是我们最终要访问的这个入口还有其他的control每一个control plane你的一个独立的组件都用一个单独的control来负责部署以及维护它的状态这总共一共有12个control我们就可以把前面描述的方案变成一个kbs engine里的一部分让整个pro-v形过程自动化自动管理kbs class的生命周期这里看起来可能功能量比较大那实际上需要做的部分我们可以利用社区移入的一些成果来减少很多的coding工作在class API的生态里面有很多pro-vider以前面的价格图为例我们完全可以levelcap b和cap end这两个项目这两个项目里面已有的实现图上那个浅绿色的这些control实际上在visual provider里面已经实现好了生绿色的control也在nasty的control也就是cap end这个项目里面有一些参考实现我们真正需要从头开始编写的control只有四个并且他们都是无状态的就是scade or the practice overcp or csa的control他们都只需要跟APS over通信然后以state of state的形式我们把它部署在management class里面就可以了这几个的工作量都相对比较简单以上就是我们新光的整体思路和加速设计当然还有一个问题就是这个cluster创建好了之后我们该怎么去仿佛它呢我们同样可以继续设计的项目很容易的把这东西解决你看到的解法我们不止一个首先你需要一个ingress认可一个开源的第三方的ingress都可以用然后我们还需要部署一个external DNS去把ingress的fqdn给注册到这个dns容器里面这样用户在仿佛class的时候就跟仿佛Vanilla的class都没有任何区别了这个它还这个方案还有一些应点比如像march tenement以及cloud native的这些应点我在这里就不再提了但是这个方案有什么缺陷呢大家可能会想到它可能会有一些单点问题我的理解是这种以破的显示运行的confirmation实际上比no的显示运行的confirmation更具有任性就是无论eGcd它是直接运行在no的上面还是以破的显示运行它的可能性其实主要依赖于pv如果都是用相同的pv不会在用显示运行的实际上这两种运行方式没有本质的区别另外如果many你们class的confirmation淡掉了class的内部的overgracing controller这个确实会受到影响所以我们唯一需要注意的就是在class的内部部署confirmation的時候尽量避免使用overgracing controller好如果大家对这个问题很感兴趣想要深入交流的话可以通过下面的方式跟我有其他联系谢谢大家希望大家能享受接下来的其他分享谢谢