在使用或部署Kubernetes时，人们面临着非常多的问题。虽然Kubernetes所面临的一些挑战是独一无二的，但更多挑战都是典型的使用大量技术所带来的成长中的痛苦。最近CNCF主导了一项有关“Kubernetes生态系统状况”的一项调研，对于当红炸子鸡Kubernetes来说，哪些方面的挑战是最突出的？小数还另外翻译了K8S环境中4种最可能的威胁模型。
“Kubernetes生态系统状况”阐述了在选择容器编排解决方案时不同标准的重要性，以及阻碍Kubernetes采用的主要因素。与安全性或资源优化等标准相比，扩展性成为编排解决方案的基本要求。其中最大的挑战是，使用Kubernetes经常需要改变IT组织的几个部分的角色或职责。
CNCF最近的调查询问到人们在使用或部署容器时面临的挑战。在我们对数据的独立分析中，我们将答案发布在“Kubernetes Deployment & Security Patterns”一文中，并将焦点集中于使用Kubernetes管理容器的组织。这提供了一种方法来说明Kubernetes用户所面临的问题。
研究结果表明，在对Kubernetes的普遍批评中，复杂性仅仅是排在第五位的挑战。领先的是与基础设施相关的挑战。在Kubernetes用户中，有46%的人提到了安全问题，网络和存储排在第二和第三位。
KubeCon +CloudNativeCon会议召集了采用者和技术专家，进一步推进云原生计算的教育和发展。供应商中立的技术有该领域专家和关键维护者的支持，比如Kubernetes, Prometheus, gRPC，Envoy，OpenTracing等等。
Twistlock利用先进的智能，机器学习功能以及自动策略创建和执行功能，保护当今应用程序免受未来的威胁。作为第一个端到端的容器安全解决方案，Twistlock是专门为交付现代安全性而构建的。
Alcide提供网络安全平台，专为由多个编排系统运营的容器、虚拟机和裸金属数据中心组合而设计。Alcide通过简化和自动控制为DevOps，安全和工程团队授权，以管理和保护不断发展的数据中心和混合云。
23%的人表示，基于负载的扩展部署是一个挑战。这意味着许多需求得到满足Kubernetes实际上是在帮助扩展它应该做的事情。在列表的底部，10%的问题得到了供应商的支持。很少有人抱怨Kubernetes支持供应商的原因之一是，许多部署并不依赖于供应商的分销。展望未来，提供高质量服务的可能性很大，因为CNCF最近推出了Kubernetes认证服务供应商计划，确保服务提供商达到一定的能力。
![复杂性排第5，当红炸子鸡K8S对用户来说最大的槽点是啥？[kubernetes最新资讯]](/upload/image/2023/08/10/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1)
超过40%的人认为安全、网络和存储是与容器相关的挑战。
和其他研究一样，我们发现较大的组织更倾向于将许多问题列为他们所关心的挑战。例如，1000名或更多员工的组织中，有55%的人认为安全是一个挑战，而不到100名员工的组织中只有39%的人这么认为。这种情况下，与可靠性等其他类别一样，大型企业的需求与小企业不同。
在其他领域，例如网络，与仅使用容器数量相比，IT基础设施(带宽和站点数量)的规模和广度可能会给Kubernetes带来更多独特的挑战。事实上，在拥有6个或6个以上集群的组织中，以网络作为挑战的比例从42%上升到53%。
一些挑战不符合上述模式。对于存储，一种解释是技术“问题”不是基于可扩展性的。在监管方面，中型企业更有可能面临挑战。正如我们之前在文章中提到的，对容器运营的监控，小企业通常不需要创建正式的监控流程，而大型企业则有资源来创建更健壮的、自定义的监视系统。被困在中间的是那些拥有100到999名员工的企业。
图1.8:在拥有1000名或更多员工的组织中，安全与网络更大可能被列为与容器相关的挑战。
影响组织与容器相关的挑战的另一个因素是，它们是否只将容器部署到公有云或在本地服务器上。在只使用本地服务器的容器中，存储是最常见的挑战。这是因为这些企业需要管理自己的存储基础设施，甚至可能由一支独立的IT团队来处理。
图1.9：54%仅供本地使用的容器用户面临存储挑战，而只有34%的公有云组织面临存储挑战。
对于只在公有云上使用容器的组织来说，监控和日志记录常常被认为是一个挑战。尽管云供应商应该支持可扩展性，但只有使用本地服务器才能使用容器的组织很难说扩展部署是一项挑战。
CNCF的调查还询问了几种类型的云原生基础设施和工具，其中一些是专门针对与Kubernetes合作的。本系列的下一篇文章将讨论Kubernetes用户用来解决他们面临的挑战的最常用工具。
4种Kubernetes威胁模型
在Kubernetes环境中，通常有四种类型的威胁，不管部署模型是什么(有一些边界情况例外)：
1.旨在危害Kubernetes控制的外部攻击：所有连接系统均存在此威胁。在Kubernetes集群环境中，这代表攻击者获得对系统的访问权限，或者损害某些会影响系统安全的控制。
2.受影响的容器或节点：如果Kubernetes控制的环境中存在恶意容器或集群内的恶意节点，那么对其他节点或集群有什么影响？你能否在节点和集群内有效地包含“爆炸半径”？
3.妥协的凭证：当Kubernetes管理员的凭据被泄露时会发生什么情况？这对集群有多大影响？
4.滥用合法权限：当系统配置错误，缺乏控制或操作不严密时，可能会发生这种情况。
这些不同的威胁可能会导致大量妥协和不受欢迎的情况，包括特权提升，敏感数据泄露，运营折中或违反合规政策。
KubeCon + CloudNativeCon会议聚集了采用者和技术专家，进一步推动云原生计算的教育和发展。供应商中立的特色领域由领域专家和关键维护者的支持，如Kubernetes，Prometheus, gRPC，Envoy,OpenTracing等等。
引起相当多关注的攻击场景之一是“爆炸半径”——受损容器对同一节点上的其他容器会造成多大的损害，或者受损的节点会对集群的其余部分造成多大的损害? 对于Kubernetes部署的所有安全考虑都是基于这些威胁模型以及最小化“爆炸半径”的需要。
在Kubernetes环境中，外部可访问的组件将受到外部攻击。这些组件可以包括API服务器、kubelet和etcd。
为了减轻外部攻击的威胁，确保只有必要的Kubernetes服务被公开。始终执行身份验证并为任何公开的服务配置正确的网络安全策略。
最终，Kubernetes管理在容器中运行的工作负载。如果一个容器被破坏，问题是容器是否可以升级权限来控制其他容器或集群。
Kubernetes的隔离机制，比如命名空间或网络分割，以及一些内置的os级控制，调节容器可以访问的内容，可以帮助限制受影响的容器的影响。另一个控制用户应该注意的是限制能够以特权模式运行的容器数量的能力——如果一个特权容器被破坏，它将会比普通的容器造成更多的伤害。
当合法的用户凭证被破坏时，系统中可能有恶意用户。因此，正确地规范和限制用户对集群资源的访问并密切监视用户操作是非常重要的。
为了减少恶意用户的影响，需要强制执行最小权限访问、基于角色的访问控制或其他细粒度访问控制。
如果系统配置不正确，可能导致滥用用户权限。例如，如果网络策略不限制pods或命名空间之间访问，用户可能能够读取其他命名空间的通信流，而这些命名空间最初不应访问。
防止滥用特权的主要防御措施是适当强化。确保所有系统组件（如容器，pod，命名空间和kubelets）都得到了强化，以显著降低特权滥用的可能性。
另一个重要的防御是授权控制。Kubernetes支持插件架构，它允许包含复杂的授权逻辑。正确设计和实施授权;这是反对特权滥用最有效的武器之一。
原文链接：
1、The TopChallenges Kubernetes Users Face with Deployment
https://thenewstack.io/top-challenges-kubernetes-users-face-deployment/
2、4 Threat Models for Kubernetes Deployment Security
https://www.tuicool.com/articles/AfI7RbQ
