非常有高兴有机会来到Cooper-ConeCodernative-Cone分享我们在安全上的经验我们今天的议题叫Red Team ViewsCooper-Native 集群管理员的安全实践是本次会议中为数不多的安全议题之一我们希望能大家看看真实的攻击者看看他们是如何攻击Cooper-Native 集群的非常期待得到各位的反馈看悟或其他任何意见和想法首先我先向自我介绍一下我自己顺便简单介绍一下我的议题即使我们已经在议题的35分钟内塞入了很多信息和内容但是对Cooper-Native的安全来说时间还是太短了如果你有更多想要知道的内容或希望有我交流的话开源社区和安全社区的同学们经常叫我Nia这里有我的吉他哈布和个人邮箱欢迎你公开或者私密的方式联系我我之前在Blackheat的HitBWHC和CIS等安全和quick的会议中分享了关于Cooper-Native容器服务网格等相关技术的议题近期也在Cooper-Native中国开源社区中分享了一些安全建设的经验我个人非常喜欢开源社区点开我的吉他哈布首页你就能看到我曾经在吉他哈布的火星无人机计划做了一些微小的贡献也能看到我曾经捐助过几个非常有趣的开发者对于我来说携带马应该是一件非常愉快的事情我在腾讯负责的工作是公司内外部容器安全原生安全 潜度安全扣断安全等场景的工房对抗对其的核心原理进行分析和工房对抗能力的建设主导和工间多起内外部安全工房演习首先我们有一个简单的介绍除了前面的自我介绍和一体介绍之外我会带大家重问一些Cooper-Native的安全特性并非全部的安全特性如果你对CKS的考试内容很熟悉的话那么你对这些特性也不陌生之后我们会给予两个真实世界的Ratim案例来展示一些黑客攻击Cooper-Native的集群它的手法讲述黑客是如何一步一步的获取KBIS集群管理员的管理员权限有些非常经典有些具有原创性最终我们将总结几个KBIS集群管理员的新的安全提示希望也能带给你一些新的东西众所周知KBIS支持一些安全特性帮助我们安全的管理网络 基督日志管理诸护权限 保护节点和其他容器资源加密数据以及管理安全行情时而针对这些安全特性和能力黑客的攻击手法也在不断地进化针对Network Policy和Service Mesh对其网络管理的能力攻击者们进化出了新的内网东货什么技巧针对APS Subber的审计取消控制和Protosecurity Policy攻击者们研究了新的绕护手法针对APPARMAL、NASBASE、CGORUFAL和CAP的内核特性攻击者们研究了很多容器逃避的手段这些新的攻击手法是成出不穷的我们根据两个真实的红队攻击案例来带大家更直观地了解攻击者的手法这里指的红队就是指在企业的防御研调过程中扮演攻击者的角色让我们通过接下来的内容来解答攻击者是如何和上述Kubernetes安全特性作对抗的这也能带大家进一步了解Kubernetes的安全设计我们把黑客对Kubernetes继续的攻击方式根据他们的攻击起点分为两个类型一种来自身长碗以攻击现场应用为起点另一种来自办公碗一共之一人为起点要介绍的这个案例是属于办公碗这个类别的但是流程一般是这样的黑客会使用扣端软件的漏洞欺骗钓鱼等手段控制一台远古的电脑这是黑客的经典传统或许一个权限之后黑客会申请一个老的Kubernetes Configure用它的Token或者找到一个老的Kubernetes Configure Pages拥有一定的和APS-SUB交数的权利并尝试进行权限提升目的是突破RBAC控制其他用户的Kubernetes资源或许决业上的权限等等之中他们希望提升为Kubernetes Admin权限这是一个权限提升的过程那么接下来我们来一步一步的讲述2021年的一个真实案例带大家深入一些Kubernetes的安全设计进入一些细节需要注意的是本次材料中说的案例我们都是以红队为第一人称视角的也就是攻击者的视角那么在这期的案例里面我们之所以可以获取到企业的一个员工电脑权限控制一个员工的电脑是使用到了几时通讯软件的一个历史漏洞当黑客在几时通讯软件中收到并点击我们发生的恶意代码他的电脑就会被我们所控制这里和Kubernetes的安全关系不大我们就不再延伸更多的细节然后我们根据员工瀏览器的瀏览历史和瀏览器的科技信息会起到一个Kubernetes文件当然更多时候我们可以在Kubernetes的默认路径里就能找到这个配置文件员工使用这个配置文件在管理他属于他的业务和应用这个应用在这么大的一个公司里面只能算是一个小的边缘业务分配给这个员工的资源和权限也极为有限不过有趣的是中国有很多人很多开发者不像这个集群管理员一样管理集群很多人并没有规划RBAC把Kubernetes的Admin的Kubernetes配置文件分配给每个需要使用Kubernetes资源的开发者和运威这个是非常危险的幸好红队这次的目标集群是一个有安全意识且考取了CKS的架构施在管理并并且由于就员员工只负责一个大公司的小业务所以说到公司集群RBAC设计的影响它是不可能拥有集群Kubernetes的权限的也没办法查看不属于它的Nespace更无法管理NoteRubunding的资源那么下途所展示的结果就是我们当时在环境里面实际测试的结果我们希望搞清楚每个普通用户在集群中都拥有什么样的权限可以看到我们获取接电信息和Kubernetes的Port的信息是没有权限可以获取到的如果我们想要创建ServiceAccord就是我们想创建ServiceAccord也会被APS Server所拒绝支持非常典型的IPAC设计最终我们写了一个简单的脚本把所有资源类型和Kubernetes支持的操作类型跑了一遍我们发现Bobble这个员工只能在自己的业务和两个Nespace操作一定范围内的资源右侧的这个图就是一个简单的势力它没有其他业务管理员的权限当然它也没有集群管理员的权限对于没有掌握更多Kubernetes支持的攻击者来说去攻击其他员工会许是他的选择但是这个时间成本就比较大了针对Kubernetes有更多的手法值得黑客们去尝试攻击容器所在节点和节点上的其他容器是一个不错的选择如果能获取节点上的入了权限那么对黑客来说那么对黑客来说是一个不错的突破这类手法我们一般称之为特殊权限的容器或者容器逃逸但是针对于这一点Kubernetes依然有安全特性可以防御那就是Protest Security Policy现在叫Protest Security Admitius不过因为这个是一个2021年的Kubernetes那个时候唯一的标准和工具还是Protest Security PolicyProtest Security Policy会拦截所有不符合策略和规则的Protest创建性求因此员工和黑客只能创建符合规则的集权线Protest这里展示了目标集群的部分这里展示了部分目标集群的Protest Security Policy设置也就是我们右侧的这部分当我们在获取Kubernetes证明权限之后才能看到Protest Security Policy的详细信息在目前的这个情况黑客是看不到这些详细信息的这里你可能关注到了这个Protest Policy的一些细节这也是等会我们要讲的内容获取节点的权限对于黑客是非常重要的对于节点的危害也是非常大的这也是我们为什么要尽量避免特权容器在节点上面被创建黑客可以使用进程注入后门提权的手段对节点进行更多生存式的利用这里我们就不再多介绍了那么黑客的路子又被读始了细心的同学可能在上一页的Protest Policy发现了一些漏洞当但是当时我们是没有Protest Policy的详细信息的那么怎么获取到这些详细信息呢虽然无法查看创建控制特权的Protest但是搭钱Nate Space里面普通应用的Protest我们还是有权限的观察创建前压木配置和创建之后的Protest YAM信息我们可以掌握集讯管理员的一些其他设计其中Adminion WebHook里面插入的新设置是值得注意的我们看到这里有一个例子这个例子里面而插CFS的新挂载被插入到了Protest中在我们的理解里Adminion WebHook像是一个APSable的插线机制它可以响应用户提交上来的支援请求被插入新的配置和教院原有的配置值得注意的是在后来的Adminion WebHook设计中修改类型的Adminion必然会在教院类型之前而Protest Security Policy也是一种教院类型的Adminion也就是说修改类型的Adminion对Protest的修改对Protest Security Policy的修改最终都要经过Security Policy的教院因此我们可以判断此处由LXCFSAdminion插入的新目录安全策略所运行的主机挂载目录肯定为实际挂载的负目录如果不是负目录的话这对于不同的Protest的LXCFS的UID所形成的挂载目录就会被Protest Security Policy所拒绝到那时说的Prot就不能被创建了由于Protest Security Policy的规则是提前设定的而且是静态的不可能根据Adminion WebHook的新需求而变化Protest Security Policy所建置的挂载目录这必然会是Adminion WebHook所插入的主机挂载的负机目录才可以执行于是黑客可以主动挂载LXCFS的负目录到容金内也因此我们获取了可读可写的LXCFS目录而且由于我们最初到的负机目录我们也可以看到单线节点其他Prot在数字机上的LXCFS目录LXCFS的目录不仅包含了为每个容器蓄力出来的CPU内存等信息其实每个LXCFS目录还包括了对Importer的C Group设备制系统当我们可以以可读可写的方式挂载了LXCFS目录时我们就可以改写C Group对设备读写的限制也许我们在容器里面访问和读写任意吃饭设备这也就意味着我们可以读写数字机上面节点上的任意文件了而对于黑客来说就等于成功进行的东西逃逸并控制的母机这很容易理解只要我们在计划任务里写入一个新的任务又或者创建一个新的特权的恶意的Static Powder这样就可以了这一点也是很多安全系统没有防御和检测到的这里我们展示了整个利用的全过程单个节点的权限并非攻击者的所有目标集讯管理员的权限才是有些集讯管理员会在每个节点放自Class的Admin的Couple Configure这是很危险的做法我们应该纪念避免黑客在获取到节点权限之后就可以直接控制整个机群这是集讯管理员非常聪明它使用Democite对节点进行自动化运萎所以节点都非常干净没有任何的痕迹并用Democite的清理节点上黑客可能会利用到的所有密钥和密钥文件这是一个非常不错的运萎时间但我们也在众多节点的自定义Democite的副本中发现了一个特殊的Service Code它居然被赋予的可以查看可可系的密钥的信息和权限而这些信息里面就包含了Class的密钥信息由于Democite的会在每个节点上运行一个Prod副本所以赋予它的Service Code其Service Code Token会在每个节点上都能获取到至此我们今天也从办公宝获取Class的Democite权限的权过程这个真实的Keyz让Kubernetes的安全能力和黑客行为变得更加自观那么针对这些黑客技巧我们该如何防御呢这里有一些关键的终身防御关键时对于Kubernetes的窃取我们可以优化配置管理的保密信息来完成也可以基于EDR对Kubernetes的关键配置文件进行保护EDR可以发现黑客窃取Kubernetes的行为虽然本杂BAC并未出现明显的安全问题但是基于基线扫描可以避免一些明显的RPA-CPACPATCHPROPort的安全限制更推荐使用新版本的Port Security Admission之后我们会详细描述这个观点的主要原因而插线FS的挂载应该用Port Security Admission限制为制独权限无锡写权券的挂载而各家动态的限制应该在实现修改类Admission的同时实现安全限制的教验类Admission用来补齐Port Security Policy的短板容器讨议的行为可以使用运营时的安全行为容器讨议这种方式可以使用运营时安全进行检测和防御ServiceCard的权限过大也可以通过基线扫描的方式进行检测并提前限制和收敛ServiceCard的权限这里就到生产网类别的时间了不过在办公网的时间里我们介绍了很多详细的过程和动作在生产网里面我们不会这么做因为这样很佔用时间而且生产网的限制比办公网更多攻击门槛也更高黑客的行为也更加容易预测和检测而且有很多手法跟办公网里面是通用的这里我们画了一张简单的图介绍黑客在CouponNetflix默认的网络环境中可以攻击的对象黑客在CouponNetflix容器里接着说网络远比在传统爱丽系中要复杂从近到远一个被控制的耳容器在没有特殊的NetflixPolicy的限制下默认他可以反而问到所有Netflix里面中的容器所开放的端口和所有Service虚拟出来的端口另外容器母席接点上面的端口也是可以正常访问和攻击的竞点上面的服务漏洞也是获取竞点权限的一个采用手段其中都会远程API爱上75端口CouponNetflix102510250端口最为聪明同时我们也不能忘记了如果侷循所在的网络环境可以访问到外网或者其他内网服务和项铃集群的话那么那当然容器也都是可以访问和攻击的这里标注出来的是我们的攻击流程其中就包含了我们这一次通过生产网对目标进行攻击的主流程包括我们如何或许第一个容器的权限以及到最后或许classed enemy的步骤和流程大致流程一般是这样hicker会在外网找到一个安全漏洞并通过这个漏洞攻击CouponNetflix集群的一个容器权限通过这个容器在CouponNetflix网络中进行很像移动攻击其他容器 节点甚至攻击API server并逐步在不同的应用中收集云与CouponNetflix相关的密钥和证实信息其中达到控制classed enemy的权限指的注意的是我们获取的第一个容器权限是一个API 6容器这是云原生开源的API网关这类的网关这类的网关啊有一个通病稍后我会详细讲讲而API 6的这个安全问题甚至让hicker或许有容器的原生控制权限最终我们通过和云服场上的API进行交互获取的classed enemy的控制权限这是也是一种常见的hicker行为原车上购买云产生的CouponNetflix产品云API一般会支持或许classed enemy的coupon config权限大权限的API密钥其实比kbs classed enemy的权力还要大但hicker为了到具体的项目中取取具体的数据也会通过云API反线控制途广于云场上的容器机群这是一种常见的说法对于管理员能力保护力度的不充足其实目前开源于原生API网关的通历目前最出名的开源API网关解决方案就是Coupon和API 6开源版本的CouponAPI的命就是管理端口管理API默认没有进权能力只能通过网络来源进行限制而在这个方面之前的API 6主要依赖于API Key但是开发者在实验中经常不修改默认密钥又对于也又加上API 6支持载入新的路R代码设置动态路由接口导致hicker可以通过该功能在API 6容器上面执行证明命幸好API 6的开发者后面非常重持这里的安全设计另外一个值得注意的是因为API 6和Cone有很多人侵赖另外也有一群开发者为Cone和API 6开发了图形化的dashboard可惜的是和原有的API的命保护能力一样这些dashboard这健全和登陆的安全设计上面极为招高设置更差我曾经在Cone这个比较出名的第三发dashboard上面发现了多个登陆绕获的漏洞成为了Cone长期解决长期时间未解决的一宿拿下一篇网关对于攻击者来说是一个非常重要的节点这意味着攻击者或者说是黑客可以攻击掌控截持机讯所管理的栏被流量以此摸清和控制机讯对外的和对内的能力对攻防更重要的是获取机讯API网关可以挡通网络隔离的限制获得入网和出网的通道还有另外一个决定生产网安全水准的重点是应用漏洞对应DevOps安全重位者们遵从DevSecOps的概念可以有效帮助公司收敛应用漏洞另外一个互准安全建设的重点是硬形式安全硬形式安全可以帮助我们发现黑客和恶意软件的行动更容易识别容器逃逸的行为检测黑客的漏洞利用手段如果拥有一个建设完善的运行实安全检测能力的话那么之前我们提到的很多黑客行为包括办公室里面的部分都可以被运行实安全检测到那么剩下的时间也不多了是时候来讲讲一些新奇有序的安全提示帮助我们更好的保护Kubernetes机群第一个我们的提示是POLO SECURITY POLICY并不是一个保密的安全策略这么一听是不是有点不知所谓这场情况我们设计一个安全策略我们希望这个策略对于攻击者来说是保密的因为如果能获取安全策略的细节就容易绕过现有的安全策略POLO SECURITY POLICY原本的设计上也是一个POLO SECURITY POLICY的安全策略只有Cluster Admin机群管理员知道它的细节但对于K8S友好的出入提示来说由于这个出入提示过于友好黑客可以根据一个POLO SECURITY POLICY很容易碰撞出所有的POLO SECURITY POLICY信息攻击者也就更容易从中找出肉动进来影响到解决的安全POLO SECURITY ADMINTION的设计就解决了这个问题现象的环境的出入提示显示在英文支援中你只有查看事件的权限才可以获取到这个出入提示POLO SECURITY ADMINTION对于管理大开发者来说也更方便推荐大家使用这里我们所展示的就是我们使用一个简单的POLO SECURITY POLICY去尝试知习POLO SECURITY POLICY都进用的那些配置也列出了我们已知的一些可以获取节点全身的手段第二个tip可能同样不可失忆你有没有这样的想法如果我把一个没有健全能力的服务放在内网它就是相对安全的如果你也这么想那么这个提示可能就很适合你这个tip来自于Kubernetes一个很长时间未解决却已经公开的安全问题Kubernetes-19101493是一个服务端矿占请求尾照的漏洞这个漏洞可以允许hacker一定条件上面勾找APS-7和Master节点从Master节点发出的请求使用这个请求请求我们原本无法访问到的一些信息使内网保护和部分网络限制的保护没有效果这样的问题在Kubernetes中还是比较常见的安全中您信任的概念建议我们每个应用服务都应该是附带加密和健全能力的事实上如果你能像云上用户一样管理不同业务的网络这样将是一个不错的选择如果每个用户在新建制时都默认会更新Network Policy使得不同业务的Kubernetes之间无法相互访问简单需要时再申请Network Policy 百名单看多么严格的网络限制策略显然作为集群管理员我们很少能如此严格的管理集群网络几乎无法落地其实图的Network Policy即使在Kubernetes时代IP Tables的网络管理能力也不应该被忽略虽然老旧虽然有点老旧但是并不过时特别是当个pod内的网络限制由于pod内面多个容器共享一个net space共享一个net net space所以我们可以在引领的container跟set card container里面对义务容器的IP Tables策略进行设置在修改代码的情况下修复SSRF的漏洞或限制容器内端口的开放最后我们是要想想如果没有Kubernetes为我们提供的这些安全能力集群管理员没有进行我们今天所讲述的安全事件的话黑客攻击我们的集群会是什么样一个招呼的情况试想如果APS server没有健全能力黑客只需要能访问到APS server就能控制整个集群如果没有RBAC黑客只要获取到一个kubernetes或service account也能做到上手效果如果运用pod security policy折kubernetes的节点上面的安全就没有帮我得到保障也会影响到节点的稳定性如果没有k8sadmission webhook就没办法实现一些更灵活的动态交易如果没有network policy和service account和service mesh黑客只需要使用老舅的手法就能攻击集群建议的目标kubernetes的安全设计和安全特性和安全能力真的非常有用而且非常有趣感谢kubernetes的设计师和开发者们也非常感谢你听到这里如果你有更多想要知道的内容或希望与我进行交流的话欢迎通过github或邮箱联系我