（一） IDC机房安全防护
成都创新互联服务项目包括泌阳网站建设、泌阳网站制作、泌阳网页制作以及泌阳网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，泌阳网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到泌阳省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
IDC机房防火墙可预防所有常见的攻击。我们在给客户部署我们容器云产品时，会递交一份产品网络规划说明。说明书上详细说明的产品的网络拓扑图、使用的端口号等等。我们建议客户只开启说明书中提到的端口号。在我们的实践中，对于需要外网访问的用户。我们只需要开启80端口。
部署容器云产品的每台物理机器会开启防火墙。
1. 控制授信机器之间可以互相访问。
2. 禁用icmp协议。
使用vpn远程访问容器服务平台跳板机器。由跳板机器登录容器服务平台所在机器进行日常运维。
（二） Docker daemon 安全
Docker daemon的安全更多是出现在docker engine API的防护上。我们在docker daemon做如下配置
1. 配置tls方式访问docker daemon
2. http remote api 绑定IP地址（只用户内网调度系统访问）
3. 使用非root用户运行docker daemon。例如：创建docker:docker 用户与用户组。
（三） 镜像安全
我们的私有容器云服务镜像来源于两个地方：客户自行构建的镜像与我们的公有云镜像中心。
1. 客户自行构建的镜像
客户自行构建的镜像有两种方式，一种是通过我们容器云平台定制的模板来构建。这种方式下，基础镜像由平台提供，安全最有保证。另外一种由用户编写Dockerfile自行构建的镜像。此类镜像我们通过两种手段来保障容器的安全：人工审核与在线安全扫描。我们会不定期通知用户更新我们的镜像安全扫描特征库来保证镜像的安全。
2. 我们的共有云镜像中心
目前，公有云镜像中心中的镜像全部由我们研发团队与安全管控团队制作，几乎不会存在安全问题的。公有云镜像中心，主要是提供工具类相关的镜像，譬如：缓存、redis、mongodb、微服务架构等等。
（四） 容器安全
我们主要从以下几个部分管控容器安全。
1. 网络安全
不同用户之间容器网络隔离。默认，不同用户的容器与容器之间不能互相访问；同一用户的所有容器可以互相访问。
容器与宿主机网络隔离。默认，容器是不能网络内网环境下任何一台宿主机。
2. 数据安全
宿主机挂在目录。用户通过统一运维管理平台，只能将固定目录挂在到容器中。
不同容器之间文件共享。用户通过统一运维管理平台，可以将自己的数据分享给指定的容器（或者其他用户）。
分布式文件系统。用户通过统一运维管理平台申请数据文件。通过apikey/secrekey访问平台提供的分布式文件存储。
3. 进程安全
采用docker 默认隔离策略。
以Docker 容器的安全问题为例
(1) Docker 自身安全
Docker 作为一款容器引擎，本身也会存在一些安全漏洞，CVE 目前已经记录了多项与 Docker 相关的安全漏洞，主要有权限提升、信息泄露等几类安全问题。
(2) 镜像安全
由于Docker 容器是基于镜像创建并启动，因此镜像的安全直接影响到容器的安全。具体影响镜像安全的总结如下。
镜像软件存在安全漏洞：由于容器需要安装基础的软件包，如果软件包存在漏洞，则可能会被不法分子利用并且侵入容器，影响其他容器或主机安全。
仓库漏洞：无论是Docker 官方的镜像仓库还是我们私有的镜像仓库，都有可能被攻击，然后篡改镜像，当我们使用镜像时，就可能成为攻击者的目标对象。
用户程序漏洞：用户自己构建的软件包可能存在漏洞或者被植入恶意脚本，这样会导致运行时提权影响其他容器或主机安全。
(3) Linux 内核隔离性不够
尽管目前Namespace 已经提供了非常多的资源隔离类型，但是仍有部分关键内容没有被完全隔离，其中包括一些系统的关键性目录（如 /sys、/proc 等），这些关键性的目录可能会泄露主机上一些关键性的信息，让攻击者利用这些信息对整个主机甚至云计算中心发起攻击。
而且仅仅依靠Namespace 的隔离是远远不够的，因为一旦内核的 Namespace 被突破，使用者就有可能直接提权获取到主机的超级权限，从而影响主机安全。
(4) 所有容器共享主机内核
由于同一宿主机上所有容器共享主机内核，所以攻击者可以利用一些特殊手段导致内核崩溃，进而导致主机宕机影响主机上其他服务。
既然容器有这么多安全上的问题，那么我们应该如何做才能够既享受到容器的便利性同时也可以保障容器安全呢？下面我带你来逐步了解下如何解决容器的安全问题。
如何解决容器的安全问题？
(1) Docker 自身安全性改进
事实上，Docker 从 2013 年诞生到现在，在安全性上面已经做了非常多的努力。目前 Docker 在默认配置和默认行为下是足够安全的。
Docker 自身是基于 Linux 的多种 Namespace 实现的，其中有一个很重要的 Namespace 叫作 User Namespace，User Namespace 主要是用来做容器内用户和主机的用户隔离的。在过去容器里的 root 用户就是主机上的 root 用户，如果容器受到攻击，或者容器本身含有恶意程序，在容器内就可以直接获取到主机 root 权限。Docker 从 1.10 版本开始，使用 User Namespace 做用户隔离，实现了容器中的 root 用户映射到主机上的非 root 用户，从而大大减轻了容器被突破的风险。
因此，我们尽可能地使用Docker 最新版本就可以得到更好的安全保障。
(2) 保障镜像安全
为保障镜像安全，我们可以在私有镜像仓库安装镜像安全扫描组件，对上传的镜像进行检查，通过与CVE 数据库对比，一旦发现有漏洞的镜像及时通知用户或阻止非安全镜像继续构建和分发。同时为了确保我们使用的镜像足够安全，在拉取镜像时，要确保只从受信任的镜像仓库拉取，并且与镜像仓库通信一定要使用 HTTPS 协议。
(3) 加强内核安全和管理
由于仅仅依赖内核的隔离可能会引发安全问题，因此我们对于内核的安全应该更加重视。可以从以下几个方面进行加强。
宿主机及时升级内核漏洞
宿主机内核应该尽量安装最新补丁，因为更新的内核补丁往往有着更好的安全性和稳定性。
使用Capabilities 划分权限
Capabilities 是 Linux 内核的概念，Linux 将系统权限分为了多个 Capabilities，它们都可以单独地开启或关闭，Capabilities 实现了系统更细粒度的访问控制。
容器和虚拟机在权限控制上还是有一些区别的，在虚拟机内我们可以赋予用户所有的权限，例如设置cron 定时任务、操作内核模块、配置网络等权限。而容器则需要针对每一项 Capabilities 更细粒度的去控制权限，例如：
cron 定时任务可以在容器内运行，设置定时任务的权限也仅限于容器内部；
由于容器是共享主机内核的，因此在容器内部一般不允许直接操作主机内核；
容器的网络管理在容器外部，这就意味着一般情况下，我们在容器内部是不需要执行ifconfig、route等命令的 。
由于容器可以按照需求逐项添加Capabilities 权限，因此在大多数情况下，容器并不需要主机的 root 权限，Docker 默认情况下也是不开启额外特权的。
最后，在执行docker run命令启动容器时，如非特殊可控情况，–privileged 参数不允许设置为 true，其他特殊权限可以使用 --cap-add 参数，根据使用场景适当添加相应的权限。
使用安全加固组件
Linux 的 SELinux、AppArmor、GRSecurity 组件都是 Docker 官方推荐的安全加固组件。下面我对这三个组件做简单介绍。
SELinux (Secure Enhanced Linux): 是 Linux 的一个内核安全模块，提供了安全访问的策略机制，通过设置 SELinux 策略可以实现某些进程允许访问某些文件。
AppArmor: 类似于 SELinux，也是一个 Linux 的内核安全模块，普通的访问控制仅能控制到用户的访问权限，而 AppArmor 可以控制到用户程序的访问权限。
GRSecurity: 是一个对内核的安全扩展，可通过智能访问控制，提供内存破坏防御，文件系统增强等多种防御形式。
这三个组件可以限制一个容器对主机的内核或其他资源的访问控制。目前，容器报告的一些安全漏洞中，很多都是通过对内核进行加强访问和隔离来实现的。
资源限制
在生产环境中，建议每个容器都添加相应的资源限制。下面给出一些执行docker run命令启动容器时可以传递的资源限制参数：
1 --cpus 限制 CPU 配额
2 -m, --memory 限制内存配额
3 --pids-limit 限制容器的 PID 个数
例如我想要启动一个1 核 2G 的容器，并且限制在容器内最多只能创建 1000 个 PID，启动命令如下：
1 $ docker run -it --cpus=1 -m=2048m --pids-limit=1000 busybox sh
推荐在生产环境中限制CPU、内存、PID 等资源，这样即便应用程序有漏洞，也不会导致主机的资源完全耗尽，最大限度降低安全风险。
(4) 使用安全容器
容器有着轻便快速启动的优点，虚拟机有着安全隔离的优点，有没有一种技术可以兼顾两者的优点，做到既轻量又安全呢？
答案是有，那就是安全容器。安全容器是相较于普通容器的，安全容器与普通容器的主要区别在于，安全容器中的每个容器都运行在一个单独的微型虚拟机中，拥有独立的操作系统和内核，并且有虚拟化层的安全隔离。
安全容器目前推荐的技术方案是Kata Containers，Kata Container 并不包含一个完整的操作系统，只有一个精简版的 Guest Kernel 运行着容器本身的应用，并且通过减少不必要的内存，尽量共享可以共享的内存来进一步减少内存的开销。另外，Kata Container 实现了 OCI 规范，可以直接使用 Docker 的镜像启动 Kata 容器，具有开销更小、秒级启动、安全隔离等许多优点。
作者 | Drishti Shastri
译者 | 天道酬勤 责编 | 徐威龙
封图| CSDN 下载于视觉中国
在当今时代，企业网络和数据安全风险从未像现在这样具有里程碑意义。尽管如此，传统方法（包括公有云运营商使用的方法）基本上是相同的。
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
云原生应用的兴起及其安全威胁
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
在当今时代，企业网络和数据安全风险从未像现在这样具有里程碑意义。尽管如此，传统方法（包括公有云运营商使用的方法）基本上是相同的。
转向应对威胁攻击而不是阻止威胁的反应措施。云原生应用程序日益受到重视，用各种可能的方式质疑了传统智慧。
从基础架构到应用程序的开发，堆栈在传统方法与更现代的基于云的方法之间形成了鲜明的对比，其中大多数已对成功的模式和实践达成了主流观点：DevOps文化、持续交付和微服务架构 。为什么我们还没有重新构想云原生的安全性呢？我们对此大胆的新想法在哪里呢？
可以肯定地说，在交付应用程序的过程中，云原生的安全性一直在被长期追踪。传统的IT安全团队将自己视为中间人。他们必须正确地完成工作，否则将面临代理机构所面临的更大风险。
它们在所有过程中都对安全性有很高的要求，但是要满足这些级别需要花费时间、测试和修订。因为这会延迟应用程序的开发并且通常不能确保全面的保护，所以开发团队经常会抱怨。
当组织希望提高和加快应用程序改进生命周期并调度云原生应用程序时，安全将成为更为突出的测试。大部分云原生应用程序都在新模型中运行，这些模型可提供非常规的生产力、适应性和成本优势。
使用dev-ops进行开发的云原生进一步将DevSecOps作为其安全组件。DevSecOps试图将安全纳入速度、敏捷性和连续交付流程中。但是，如果DevSecOps忽略了集成、业务流程功能和控制，并且对用户的安全性较低，则可能很难在连续交付系统中提供安全性。
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
云原生漏洞
云原生肯定会发生漏洞。我们是人类，肯定会犯错误，尤其是在苛刻的期限和产品交付之后。尽管有全部的警告、标志和注意事项，我们也会做出一些错误的判断。
在发出警告的过程中，人们继续盲目地从Stack Exchange复制和粘贴，来掩盖在GitHub上发现的应用程序，甚至随机地将代码从一个毫无头绪的文件夹中随机拉出，并且只能怀疑地认为该作者从未遇到过或甚至没有与之交谈过的第三方。
微服务应用程序的分布式性质意味着，即使在内部编写所有代码的情况下，通过消除第三方参与者的风险，不同的组件也可能由不同的团队拥有。
团队之间的沟通障碍会导致一系列问题，包括在测试、质量保证甚至应用程序中的漏洞解决方面缺乏协调。
一个单独的云原生应用程序可以包括分散在众多基础上的数千个剩余任务。在本地数据中心、众多公有云和边缘数据中心中可能会有奇异的微服务，最后，在组织领域中，我们目前似乎还无法发展。
每个开发人员和每个开发团队都知道并了解如何解决不同的问题。他们所做的就是相应地培养他们的注意力和知识。在内部代码环境中，即使所有部门都以某种方式保护自己的更广泛程序的一部分，微服务也必须与其他部门联系，并且通信在这里是风险或脆弱性。
这些所有说法听起来都令人生畏和令人恐惧，但云原生确实解决了一些非常复杂的现实问题，我们再也不能忽视它的存在。随着我们不断升级其安全性，云原生的漏洞正在不断发展并一直存在。
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
对云原生应用程序的主要威胁
尽管公司开始体验云原生应用程序的优势，但他们对处理和维护此类系统的实际方面却知之甚少。与在云环境中相比，保护的后果是否与传统系统相比有很大不同？防护措施和保障措施如何对其产生影响？
以下是基于云的环境的一些最高安全性问题：
1.云配置错误
IaaS和云数据存储的配置错误是当今一些最具破坏性的云违规和数据泄露的主要原因。无论你要删除结构化的云安全设置、使用通用代码、无限制地访问某些资源还是其他任何原因，配置错误问题都会导致许多未知威胁，这些威胁仅在尴尬的遭遇后经常在报纸上看到。最新的《 2019年云安全报告》称，大约40％的组织认为错误配置云平台是他们对网络安全的主要关注点。
2.商业化管理的IT
不用担心“影子IT”或“流氓IT”。毫不夸张地说， 几家公司将基础架构的收购趋势标记为，将获得和运营云服务的业务桥梁客户称为“商业化管理的IT”，以及创造力和发展的引擎。《 Harvey Nash /毕马威CIO 2019调查》报告称，目前有超过三分之二的公司为企业推广或允许IT管理。这是因为这样做的公司击败行业竞争对手的能力提高了52％，提供更好的员工服务的可能性提高了38％。
令人担忧的是，如果没有信息和网络安全专业人员的合作，这些云技术孤岛可能成为组织的巨大安全障碍。这些公司的发展速度相当快，但调查显示，冗余的安全隐患波长的可能性是后者的两倍。
3.购买多云产品
《云保护联盟报告》显示，大多数公司都依赖各种各样供应商的云环境来购买多云产品。大约66％的公司具有多云设置，其中大约36％取决于多云和混合系统的混合。
目前，由于云实际上是希望降低其运营处理成本的所有其他企业的首选工具，因此云计算向其云消费者提供一系列服务（SaaS、PaaS、IaaS）。云在其整个上下文中提供安全、迅速响应和服务质量。但是，每次用户无法从一个云迁移到另一个云时，它都会保持成本和QoS可伸缩性。为了克服这种多云计算框架，引入了基于云的系统之间的资源动态共享。在多云设备中，安全性甚至是一个更为复杂的问题。
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
4.混合架构
根据著名的《云安全联盟报告》，大约55％的组织拥有复杂的、混合操作的云计算环境。该系统为大型组织提供了一种逐步过渡到云的绝佳方法，但是当他们难以跟踪整个架构中的资产并监视众多混合云连接的活动时，它给安全性带来了挑战。实际上，Firemon先前发布的一份报告显示，80％的组织都在挑战混合安全监控和管理工具的局限性和复杂性。
5.暗数据
就像电信行业的暗光纤一样，暗数据也适用于企业和商业。这里有大量未开发的、大多是不受监管的数据，它们只是存在而已，什么也没做。
不幸的是，尽管暗光纤明确代表了仅点亮即可增加功率和带宽的优点，即使被识别和忽略，暗数据也可能存在安全风险，无论它们在用户手中出现错误还是落在用户的范围之外。
有关暗数据的大多数争论都倾向于集中于组织的潜在价值和有用性。实际上，对于愿意花费资本（资金、设备和时间）来创建和利用暗数据中锁定的知识和兴趣的组织，这些前景无疑是有利可图的。这也说明了为什么许多公司尽管不打算代表他们工作，却拒绝在短期内或在计划过程中进一步交换黑暗的细节。
就像许多潜在的富有吸引力的信息资源一样，企业还必须意识到，暗数据或者关于暗数据及其客户和他们的云运营的暗数据，可能会给他们持续的健康和福祉带来风险，超出了他们的直接控制和管理范围。根据最近的研究，有40％的组织仍处于有关容器环境的安全策略的规划或基本阶段。
6.容器与容器编排
如果你使用容器在表面上开发应用程序或将现有的单源（单片）应用程序带入容器化的生态系统，则必须理解容器环境会带来奇怪的安全威胁。从第一天开始，你就应该准备好应对这些威胁。开始构建自己的容器，该容器将在生产行业中安装和运行。
以下是最常见的容器安全风险：
特权标志：即使是那些对容器有深入了解的人也可以知道特权容器的含义。使用特权标志的容器几乎可以执行服务器可以执行的任何操作，执行并获得对客户端资源的访问。这意味着，如果入侵者进入一组受保护的标志箱，则它们可能会被破坏。
无限制的交互：为了实现其目标，容器必须彼此交互。但是，容器和微服务的数量以及容器的短暂设计通常意味着，要执行符合最低权限概念的联网或防火墙法规可能会很困难。但是，你的目标应该是使容器只能在减少攻击面所必需的容器中进行交互。
缺乏隔离：容器安全是一把双刃剑。除了使用寿命短和功能受限外，它们的不变性质还提供了各种安全优势。但是容器也可以用来攻击主机。我们之前讨论过，这种危险存在于带有特权标志的容器中。基础主机可能会受到许多其他错误配置的威胁。
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
确保全面安全
为了接近云原生的安全性，最好不要使用传统的手动安全技术。此外，为了建立成功的DevSecOps，IT部门应将重点放在自动化和安全人员融入DevOps团队中。由于其在容器基础结构中的微服务体系结构软件包，因此基于云的应用程序可以比传统应用程序更快地扩展。以上意味着手动安全方法太慢而无法保留，并且自动化是强制性的。将安全团队归入DevOps组可确保安全性包含在应用程序代码中，而不是一旦发现问题便进行修改。这也可以加快并澄清对问题的响应。
让我们谈谈五个DevSecOps支柱，这些支柱在确保全面网络安全方面具有重大潜力：
安全合规的部署管道：分析工具、集成管道以及如何将合规性和审核融入到DevSecOps和Cloud-Native Development的管道中。
安全且合规的云平台：身份和访问管理评估、检测控制、基础结构保护、数据保护和响应事件。
代码一致性：在软件开发过程中，合规性被视为代码框架，以确保管理、合规性和任何风险缓解问题。
机密信息管理：在混合云业务模型中管理基于云的敏感信息、密钥和证书。
容器隐私：容器如何适应安全策略，如何链接容器安全威胁以及如何审查容器操作模型和检查。
所有这些支柱都是侧重点领域，因此，始终地、完全地应用了业务安全，并且需要进一步进行审查。为了提供每个实施支柱的跨部门愿景，对所有支柱进行横向治理。这些治理模型适用于每个支柱，并确保支柱以互惠互利的方式运作。
受保护的交付：确保支持的应用程序平台和云基础架构稳定、合规且安全。
安全模式：开发安全位置和威胁模型以支持客户的多样化接受。
信息保护：确保内部和外部员工不受客户数据的保护。
风险评估：包括当前体系结构、容器策略和云基础架构，并对应用程序进行差距分析。
技术变更日志：创建有序的战术执行积压，通过交付工程结果来推动3-6个月的路线图和战略实施计划。
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
对新安全原型的需求
统计数据显示，到2021年，将有92％的公司成为云原生公司。
话虽如此，通常使组织陷入困境的是为它构建一个5000美元的应用程序和一个5美元的安全系统。就云安全性而言，安全性同等或是一个更重要的因素。因此，DevSecOps的概念需要尽早实施并认真对待。
DevSecOps在应用程序开发过程的所有阶段均提供合规性，并负责设计和安装应用程序。首先要评估团队或实体的性质，并建立代表该团队或实体的程序。
第一步是在团队之间分配孤岛，以确保每个人都对保护负责。由于开发团队出于安全原因构建应用程序，因此Ops将更快地交付软件，并且使你高枕无忧，因为他们理解开发人员知道稳定性和保护至关重要。
实际上，必须有可以立即进行安全检查的过程。
服务器记录表明谁进行了修改、进行了哪些更改以及何时进行了更改，这些都是在审核程序时要知道的所有重要事实。保持保护的最简单方法是始终保证系统运行最新的软件更新。安全修复程序无需花费数月的时间，并且应该是快速而自动的。同样，在开发API和新功能时，应进行潜在的更新，以防止软件承担责任并阻止框架打补丁以防止崩溃。
创建云原生应用程序时，仍然没有单一的安全方法来保护你的软件。为了保护云中的服务器资源，你需要采取多方面的方法。为了保护你的容器，你需要采取几种策略。归根结底，要将安全放在适当的优先级列表中，你需要DevSecOps策略。
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
理想的云原生安全框架会是什么样？
为了允许基于云的转换，公司需要在设计安全策略之前考虑以下进一步要求：
高标准的安全自动化：常规的基于预防措施的安全操作根本无法使基于云的系统保持几乎无限的动态性。根本不是手动工作流程的选择。对云原生安全性的需求是自动检测和大规模灵敏性。
混沌设计：在微服务架构中，运行时组合在一起的许多软件组件可以用于任何功能。从安全的角度来看，这意味着检测和控制的逻辑不能依赖于对操作安全性的事先了解。云原生安全性应该包含混沌工程的原理——高效、有效地运行测试等。
快速识别，涵盖本地并立即追踪：云原生程序本质上是分配了计算应用程序。在这样的生态系统中，随后无法轻松执行全局安全性选择。因此，你希望确定措施的优先级，使你能够在系统范围的恶意趋势蔓延之前迅速识别，恢复并涵盖本地影响。尽管你的安全决策并非100％准确，但是本地操作和快速恢复可以为你提供更兼容的现有系统。
随后，你的云解决方案应具有哪些原生安全性？简而言之，让我们关注编译器功能。作者认为主要功能如下：
混合堆栈可见性和决策支持
在服务器、VM、数据库、软件和API服务中，即使分布了应用程序，但短期内还是动态资源和容器，仍需要云原生数据中心中的可见性和决策支持。在这些不同层上获得的数据应该进入引擎，以便实时进行选择过程。
快速反应和警告功能可限制爆炸半径
万一发生事故或袭击，安全解决方案将减轻并控制影响。这种论点等同于迅速的决策和有见地的控制措施，可以在发生不可逆转的破坏之前阻止恶意行为。在云原生环境中，智能检测系统可以完全识别入侵的出现并影响本地控制。
严密监控与调查
由于所有分布式组件和API服务，云本机工作负载安全调查可能会很复杂，因此监视和安全调查必须最大程度地降低性能影响和存储要求。这包括一个集中的监视体系结构，没有网络瓶颈，并且工作负载可以扩展。
与自动化工具集成
容器工作负载可以在云原生环境中由Kubernetes、Openshift、Amazon ECS或Google GKE管理。你可以（可选）使用Puppet、Ansible或Chef自动执行部署。安全工具可以与要保护的工作负载一起自动部署，云环境必须是与此类组件的必备集成。
对于替换第一代物理服务器和虚拟机的事件驱动的容器和应用程序，安全性必须找到正确的切入点，以最大化可视性并降低风险，同时允许创造力和适应连续云交付的复杂性。
云原生的漏洞与威胁有哪些？安全性如何？这里有你想知道的一切
结论
从整体环境迁移到云原生环境确实听起来很吸引人，但是一旦决定这样做，请确保评估可能出现的所有安全问题，评估是否有足够的资源和团队来处理这些问题。而且最重要的是，如果要实现这种转变，你的企业才能真正脱颖而出并发展壮大。
希望这篇文章对你有用，欢迎评论区和我们讨论。