- 综合排序
- 最热优先
- 最新优先
- 来自专栏绿盟科技研究通讯
【云原生应用安全】云原生应用安全风险思考
观点一 云原生应用继承了传统应用的风险和API的风险 云原生应用源于传统应用，因而云原生应用风险也就继承了传统应用的风险。 观点二 应用架构变革将会带来新的风险 由于应用架构变革，云原生应用遵循面向微服务化的设计方式，从而导致功能组件化、服务数量激增、配置复杂等问题，进而为云原生应用和业务带来了新的风险。 二、传统应用面临的风险 由于云原生应用也是应用，因而云原生应用风险可以参考传统应用风险，传统应用风险则以Web应用风险为主，主要包含注入、敏感数据泄露、跨站脚本、使用含有已知漏洞的组件、不足的日志记录和监控等风险 3.2云原生业务带来的新风险 在之前的概述小节中，笔者提到应用架构的变革也会为云原生应用业务带来新的风险，说到此处，读者们可能会产生疑问，云原生应用业务风险和上一小节提到的云原生应用风险有何区别，笔者看来 五、总结 本文较为详细的为各位读者分析了云原生应用面临的风险，可以看出，云原生应用相比传统应用面临的风险主要为应用架构变革及新的云计算模式带来的风险，而针对应用本身的风险并无较大变化，因而对云原生应用架构和无服务器计算模式的深度理解将会有助于理解整个云原生应用安全
2.9K33发布于 2021-08-06 - 来自专栏云技术+云运维
云原生与云原生应用概念解析
在一般用法中，“云原生”是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。“云原生”是关于如何创建和部署应用程序，和位置无关。 这意味着应用程序位于云中，而不是传统数据中心。 云原生应用 云原生应用是天然适合云特点的应用，云原生应用系统需要与操作系统等基础设施分离，不应该依赖Linux或Windows等底层平台，或依赖某个云平台。 CNCF给出了云原生应用的三大特征： 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。 云原生应用和本地部署应用程序之间的差异 云原生应用程序开发采用与传统企业应用程序完全不同的体系结构。 可更新 云原生应用程序始终是最新的，云原生应用始终可用。 本地部署应用程序需要更新，并且通常由供应商按订阅提供，并且在安装更新时需要停机。 弹性 云原生应用程序通过在峰值期间增加的资源来利用云的弹性。
3.7K34发布于 2019-10-29 - 来自专栏绿盟科技研究通讯
【云原生应用安全】云原生应用安全防护思考（一）
一、概述 应用是云原生体系中最贴近用户和业务价值的部分，笔者在之前《云原生应用安全风险思考》一文中分析了云原生应用面临的风险，相信各位读者已经有所了解，本文为云原生应用安全防护系列的第一篇，主要针对传统应用安全 二、传统应用安全防护 从《云原生应用安全风险思考》一文中对传统应用风险的介绍，我们得知传统应用为云原生应用奠定了基石，因而笔者认为云原生应用安全防护也可参照传统应用安全防护，接下来笔者将为各位读者介绍传统应用的安全防护方法 最后，在云原生应用架构下，我们可使用云原生API网关，其与传统的API网关有何不同，能为云原生应用风险带来哪些新的防护是我们关心的问题。 3.3云原生API网关 云原生API网关，顾名思义指云原生应用环境下的API网关，笔者认为，云原生API网关与传统API网关的区别主要有两方面，一方面是应用架构带来的区别，另一方面是部署模式的区别。 本文为各位读者介绍了云原生应用在传统应用安全、API安全、云原生应用业务安全三个维度的相应防护方法，结合之前风险篇的相应介绍，首先我们可以看出传统应用防护技术适用于云原生应用，因而深刻理解传统应用防护内容非常重要
2.5K12发布于 2021-09-27 - 来自专栏绿盟科技研究通讯
【云原生应用安全】云原生应用安全防护思考（二）
二、微服务架构下的应用安全 针对《云原生应用安全风险思考》一文中对云原生应用的新风险分析，我们可以看出应用的微服务化带来的新风险主要包含数据泄露、未授权访问、被拒绝服务攻击，那么如何进行相应的防护也应从以上三方面去考虑 2.3数据安全 如《【云原生应用安全】云原生应用安全防护思考（一）》一文中提到的，传统应用架构中，我们可以通过安全编码、使用密钥管理系统和使用安全协议的方式防止数据泄露，在微服务应用架构中，我们可以考虑使用 ，因而针对Serverless应用的安全防护各位读者可以大体参考《【云原生应用安全】云原生应用安全防护思考（一）》一文中传统应用安全的防护方式，尤其是应用程序的代码漏洞缓解、依赖库漏洞防护、数据安全防护 针对应用程序访问控制，除了《【云原生应用安全】云原生应用安全防护思考（一）》中提到的使用基于角色的访问控制之外，由于Serverless云计算模式带来的变化，还需要进行更深层次的防护，笔者认为函数隔离及底层资源隔离是较为合适的防护方法 】微服务架构下API业务安全分析概述 【云原生应用安全】云原生应用安全风险思考 【云原生应用安全】云原生应用安全防护思考（一） 关于星云实验室 星云实验室专注于云计算安全、解决方案研究与虚拟化网络安全问题研究
2.3K22发布于 2021-10-15 - 来自专栏Java升级打怪进阶之路
云原生应用的概念和云原生应用的 15 个特征
云原生应用的概念 顾名思义，云原生应用的概念由云和原生两个部分组成，云在这里指的是云平台，也就是平台即服务（Platform as a Service，PaaS）；原生应用指的是专门针对云平台而设计和实现的 起初CNCF(云原生计算基金会)认为云原生系统需包含的属性： 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。 随着近几年来云原生生态的不断壮大，所有主流云计算供应商都加入了该基金会，且从 Cloud Native Landscape 中可以看出云原生有意蚕食原先非云原生应用的部分。 结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。 云原生应用的特征 与其他应用相比，总结起来，云原生应用有如下 15 个特征。 随时可丢弃 **云原生应用的生命周期可能是短暂的，随时可能被终止。**云平台可能会随时启动和停止应用的实例，这就要求云原生应用的启动和停止速度都要非常快。 支撑服务 云原生应用的运行离不开支撑服务。
1.6K20编辑于 2022-11-28 - 来自专栏yeedomliu
云原生应用架构实践
推荐序一 云原生与传统云计算最大的区别在于，传统云计算关注的是如何提供性价比最高的计算、存储、网络资源，而云原生关注的是 如何让产品能够支持快速验证业务模式 如何简化复杂的开发流程、提升研发效率 如何保障产品的高可用性让业务无需承受成长之痛 如何实现大规模弹性伸缩轻松应对业务爆发 ---- 内容简介 实现云原生应用面临的功能和非功能（高性能、高可用、可扩展、安全性、高可靠等）的不同阶段需求和实现方案进行了较为完整的梳理 ---- 第1章 ，也就是常说的用好“云”，发挥云计算的最大价值 1.3 云原生应用架构 云原生（CloudNative）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。 采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力 目前业界公认的云原生主要包括以下几个层面的内容 敏捷基础设施 开发人员可以随时拉取一套基础设施来服务于开发 面向云原生应用的3个不同层次的特点 高可用设计（Design for Availability），不同区域、机房、机柜、服务器、进程的高可用 可扩展设计（Design for Scale），所有应用设计是无状态的
1.2K40发布于 2021-11-02 - 来自专栏云计算D1net
为什么云原生应用需要云原生勒索软件保护
企业无法保证云计算环境免受勒索软件的侵害。如果应用程序是云原生的，由于保护可靠的时间点备份或检查点(包括数据量和应用程序配置信息)面临的特殊挑战，将会令人更加担心。 在云原生环境中需要识别和保护大量数据是一个障碍，只有在备份应用程序及其数据时才会保护应用程序。 云原生勒索软件防护的关键考虑因素 人们需要了解在Kubernetes环境中保护数据时面临的一些独特挑战。第一个也是最明显的问题是参与云原生应用程序责任链的参与者数量。 该框架相应的功能有助于为云原生应用程序提供全面的勒索软件保护和可恢复性。 对于运行云原生应用程序的企业来说，与NIST网络安全框架保持一致的主要好处是数据保护方案的一致性，因此可以跨行业共享知识，以及采用不会导致管理开销的方法。
1.2K10发布于 2021-11-08 - 来自专栏大数据-BigData
云原生模式部署Flink应用
基本介绍 Kubernetes 是一种流行的容器编排系统，用于自动化计算机应用程序的部署、扩展和管理。 Flink 的原生 Kubernetes 集成允许您直接在运行的 Kubernetes 集群上部署 Flink。 Flink 应用程序，因为这些模式为应用程序提供了更好的隔离。 LoadBalancer：使用云提供商的负载均衡器向外部公开服务。 由于云提供商和 Kubernetes 需要一些时间来准备负载均衡器，您可能会在客户端日志中获得一个 NodePort JobManager Web 界面。
2.5K30编辑于 2022-02-27 - 来自专栏程序猿DD
云原生应用的12要素
适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。 本文综合了我们关于 SaaS 应用几乎所有的经验和智慧，是开发此类应用的理想实践标准，并特别关注于应用程序如何保持良性成长，开发者之间如何进行有效的代码协作，以及如何 避免软件污染 。 云原生应用的12要素 I. 分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12-Factor 进行开发。 多个应用共享一份基准代码是有悖于 12-Factor 原则的。 相反的，应该借助操作系统的进程管理器(例如 Upstart ，分布式的进程管理云平台，或是类似 Foreman 的工具)，来管理 输出流 ，响应崩溃的进程，以及处理用户触发的重启和关闭超级进程的请求。
4.8K110发布于 2018-02-01 - 来自专栏亨利笔记
VMware的云原生应用战略
为方便阅读和分享，应读者要求，把《云原生应用战略》上、下两篇合并发表。作为福利，新增加了vSphere Integrated Container的演示视频。 从技术栈上看，涵盖了云原生应用的开发栈，生产栈和DevOps三部分，这里分别给大家介绍一下。 ? 在云原生应用中，随着微服务架构和容器技术广泛使用，在开发调试的时候少不了用虚拟机构建分布式的环境，因此，用二类(Type 2)Hypervisor来搭建这类环境最适宜。 通过本文的介绍，我们看到VMware在云原生应用的各个领域全面发力，产品Roadmap涵盖了开发栈，生产栈和DevOps三大部分。 其中的生产栈平台分为vSphere Integrated Container(传统与云原生应用混合)和Photon Platform（大规模云原生应用平台），适合不同转型阶段的企业选用。
2.4K51发布于 2019-04-12 - 来自专栏Apache IoTDB
开源云原生，论道中关村 | 云原生开源项目应用实践专场回顾
2 月 25 日，「DaoCloud 道客」本年度的第一场技术 Meetup——云原生开源项目应用实践专场终于在北京中关村和大家见面啦。 01 HwameiStor 赋能数据存储 众所周知，存储是应用运行的基石，随着云原生技术的不断成熟，存储系统也面临着新的挑战。 最后，李翔以工业 4.0 液体实验室、“首制船” 的生物降解系统为例，让大家更直观地感受到云原生赋能 AIoT 开发的应用实践及效果。 05 云原生架构上的 低代码开发 在智能技术繁荣发展的今天，低代码平台的应用降低了技术门槛，在成本最小化的同时实现了敏捷开发。 之后，王洁介绍了云原生技术架构与低代码平台的整合方式，对多租户和管理引擎、多人协作与本地开发的功能架构以及应用实践进行了详细的介绍。
73010编辑于 2023-03-21 - 来自专栏绿盟科技研究通讯
【云原生安全】从分布式追踪看云原生应用安全
四、云原生应用安全 前文介绍了在云原生架构下，可以通过分布式追踪系统，实现对云原生应用的可观察性追踪。根据追踪数据，进而实现对应用的性能分析、故障定位等。 接下来本章将介绍，基于分布式追踪系统获取的可观察性数据，如何实现云原生应用的安全检测与防护。 4.1什么是云原生应用安全 应用安全是指应用级别的安全措施，旨在保护应用内的数据或代码免遭窃取和劫持。 基于微服务架构的云原生应用，通常采用Docker、Kubernetes、Service Mesh、Serverless等云原生计算支撑技术，实现对应用程序的运行支撑。 4.4云原生应用的API安全 回到云原生应用的本身，基于微服务的架构设计，使得应用之间的交互模式从Web请求/响应为主转向各类API的请求/响应，API通信在云原生应用交互中占据了重要的地。 因此，API安全也成为了云原生应用安全中尤为重要的一个部分。
1.2K10发布于 2020-12-30 - 来自专栏亨利笔记
VMware的云原生应用战略（上）
转眼间一年过去了，在今年刚结束的VMworld大会上，VMware发布了一系列和容器相关的技术和产品，我们逐渐清晰地看到VMware在云原生应用(Cloud Native Apps)领域的布局和蓝图，仿佛一幅宏大的画卷缓缓地展现在我们面前 从技术栈上看，涵盖了云原生应用的开发栈，生产栈和DevOps三部分，这里分别给大家介绍一下。 ? Photon Platform（光子平台） VMware的云原生应用产品名字都是和光有关的，如Photon, Lightwave等，“光”的英文单词是“Light”，又有轻盈灵巧的含义。 VIC目标是给用户提供虚拟机和容器的统一管理平台（Unified Platform），相比之下，另一产品Photon Platform（光子平台）则是专门为云原生应用设计的，特别适合运行由成千上百、海量规模的容器组成的微服务应用 Lightwave的代码是从vSphere源码安全模块中抽取出来的，是历经多年实用验证过的，这部分开源的ESX代码以及即将开源的Photon Controller，都显示了VMware推动云原生应用技术发展的决心
2K10发布于 2019-04-12 - 来自专栏CODING DevOps
持续演进的云原生应用交付
什么是云原生 云原生是指导企业应用上云的方法论和技术体系，包含应用的开发、交付、运行时等阶段， Cloud Native 可以理解为： Cloud 表示应用运行在云端，而非传统的 IDC； Native 表示应用从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用云平台的弹性和敏捷。 持续演进的云原生应用交付 从 CNCF 的调研报告中得出的核心结论是企业需求未被满足，持续交付的方法论和工具建设依然处于持续演进中，下面我们回顾一下云原生应用持续演进的重要方法论及相关工具。 因此我们相信，2021 年会有更多的方法论和工具出现在云原生应用交付域，尝试解决企业级云原生交付问题。 CODING 作为国内一站式 DevOps 头部品牌，将在下半年推出云原生应用交付工具，服务企业更好的落地云原生，实现研发效能升级。 点击深度探索云原生之旅
1.4K31发布于 2021-07-27 - 来自专栏架构之家
基于云原生应用架构设计
消息中间件主要解决应用耦合、异步投递消息、流量削峰，采用RabbitMQ. 这一步可以实现DevOps进一步提高效率，采用的技术方案Jekins+Kubernets。 二、应用架构介绍 云原生架构主要对业务场景、隔离故障、容错、自动恢复等非功能性要求考虑较多，通过云原生架构可实现弹性资源的要求、跨机房的高可用、数据高可用（可达99.9999999%）。 云原生架构概念 敏捷基础设施要求像机器等基础资源，能够支持开发人员、运维人员和业务人员通过代码随时拉取、随时释放，同时以接口的方式提供弹性、按需的计算和存储能力，且是自动化。 一般公有云提供服务端服务 发现机制。技术选型可选择ZooKeeper或Consul中间件来实现。 Dubbo是阿里针对大规模网站应用研发微服务架构，主要应用于长链接小数据的模式提供服务，但如果产品业务后台逻辑复杂、时间长而导致异步逻辑比较多的话，可能Dubbo不太合适。具体请参看官方文档。
93720编辑于 2022-09-01 - 来自专栏k8s技术圈
云原生应用实现规范 - 初识 Operator
与此同时，在云原生的大背景下，生态系统是衡量一个平台成功与否的重要标准，而广大的应用开发者作为 Kubernetes 的最直接用户和服务推广者，他们的业务需求更是 Kubernetes 的生命线。 项目强大的影响力下，越来越多的企业级分布式应用选择拥抱云原生并开始了自己的容器化道路，而 Operator 的出现无疑极大的加速了这些传统的复杂分布式应用的上云过程。 这也成为了容器技术在云原生应用生产化道路上的一个瓶颈。 与此同时，谷歌于 2014 年基于其内部的分布式底层框架 Borg 推出了 Kubernetes 并完成了第一次代码提交。 2015 年，Kubernetes v1.0 版本正式发布，同时云原生计算基金会 Cloud Native Computing Foundation，简称 CNCF）正式成立，基于云原生这个大背景，CNCF 云原生应用下一个重要存在。
94721发布于 2020-09-22 - 来自专栏有文化的技术人
OAM—云原生下的应用模型
OAM概述 OAM （Open Application Model）是一个专注于描述应用的标准规范，OAM的愿景是在应用的维护生命周期内，提供一种标准化的沟通方式。 将应用开发者、应用运维人员和基础设施运维人员，以一种标准化的方式连接起来，并且强化了应用生命周期中各个角色的职责。 这就要求一个真正面向最终用户侧的应用定义，需要能够为业务研发和应用运维人员提供各自视角的应用定义原语。 特点： 开发和运维关注点分离：开发者关注业务逻辑，运维人员关注运维能力，让不同角色更专注于领域知识和能力； 平台无关与高可扩展：应用定义与平台实现解耦，应用描述支持跨平台实现和可扩展性； 模块化应用部署和运维特征 OAM规范模型 应用定义 OAM通过一个application配置来定义一个整体的应用实例，如下： apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration
1.1K20编辑于 2023-09-09 - 来自专栏yeedomliu
云原生应用管理：原理与实践
如何重新配置或定义复杂的分布式应用；是否需要大量的专业模板定义和复杂的命令操作；是否可以向无状态应用那样用一条kubectl命令就完成应用的更新？ 如何备份和管理系统状态和应用数据？ custom resources and controllers的概念，这正是Operator的核心概念 基于custom resources和相应的自定义资源控制器，我们可以自定义扩展Kubernetes原生的模型元素 ，这样的自定义模型可以如同原生模型一样被Kubernetes API管理，支持kubectl命令行； 这样的设计范式使得应用部署者只需要专注于配置自身应用的期望运行状态，而无须再投入大量的精力在手工部署或是业务在运行时刻的烦琐运维操作 “上云”过程 历史上第一个Operator—etcdoperator。 同时，Operator应用如此广泛的覆盖面也使它超过了分布式应用这个原始的范畴，成为整个Kubernetes云原生应用下一个重要的存在 RedHat在2019年初联合AWS、谷歌、微软等大厂推出了OperatorHub.io
2K50发布于 2021-11-12 - 来自专栏Andy的技术专栏
谈谈对云原生应用的理解
顾名思义，云原生就是面向云设计的应用，自从2013年Matt Stine提出概念后，更多是一套技术体系和方法论，官方定义一直在演变，但核心还是通过基础云平台、云中间件、微服务、容器编排调度、Devops 抽空读完《未来架构-从服务化到云原生》，结合笔记也谈谈对云原生的一些简单理解 目录 云原生诞生背景是什么？ 云原生能帮助研发解决什么问题？ 云原生应用的定义是什么？ 云原生当前生态圈是怎么样的？ 云计算本质：按需分配资源和弹性计算 云原生应用特点：核心是利用按需分配和弹性伸缩来设计的应用，让应用更适合在云平台运行 云原生十二要素：Heroku团队提出的云应用设计理念 1、Codebase 基准代码 提供日志、图片、文档存放，弱化单机磁盘存储 2、Container Runtime：云原生应用选择容器作为轻量级运行载体，推荐docker主流 3、Cloud-Native Network：云原生网络解决每个容器独立 云原生生态的基石 kubernetes CNCF整个技术栈都是围绕k8s建立，不仅是解决了容器的编排问题，更进一步可以说对云原生应用提供了定义规范 kubernetes核心组件 [l1chg84gzk.png
4.1K270发布于 2019-08-04 - 来自专栏亨利笔记
VMware的云原生应用战略（下）
（续上篇） 拙文《VMware的云原生应用战略（上）》发表后，反响强烈，收到许多朋友的鼓励和支持，特此谢过。此为下篇，希望能给大家带来更多启示。 AppCatalyst AppCatalyst直译就是“应用的催化剂”。顾名思义，这个工具是为了加快云应用开发过程，目标是提供“本本上的数据中心”(Data center on a laptop)。 在云原生应用中，随着微服务架构和容器技术广泛使用，在开发调试的时候少不了用虚拟机构建分布式的环境，因此，用二类(Type 2)Hypervisor来搭建这类环境最适宜。 通过本文的介绍，我们看到VMware在云原生应用的各个领域全面发力，产品Roadmap涵盖了开发栈，生产栈和DevOps三大部分。 其中的生产栈平台分为VMware Integrated Container(传统与云原生应用混合)和Photon Platform（大规模云原生应用平台），适合不同转型阶段的企业选用。
1.2K20发布于 2019-04-12
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号