本章的内容主要是讲解服务间通讯的安全和集群外部访问内部服务的 jwt token 验证。
通过将一个单一应用划分为多个原子服务的方式,可以提供更好的灵活性,可扩展性以及重用服务的能力。然而微服务对安全有特殊的要求:
安全是一个非常重要的话题,但也是平时容易被忽略的一个话题,我们在开发应用的时候,往往会忽略安全,但是当应用上线后,安全问题就会暴露出来,这时候就会造成很大的损失。Istio 通过在服务之间注入 Sidecar 代理,来实现对服务之间的流量进行控制和监控,从而实现服务之间的安全通信。
接下来我们配置一个安全网关,为外部提供 HTTPS 的访问方式。首先,确认 curl 命令是否通过LibreSSL去编译的:
在微服务架构中,应用程序是由多个相互连接的服务组成的,这些服务协同工作以实现所需的业务功能。所以,一个典型的企业级微服务架构如下所示:
基于角色的访问控制(RBAC)为服务提供服务级别和方法级别的访问控制。RBAC政策是附加的。依次检查策略。根据操作以及是否找到匹配的策略,允许或拒绝请求。
王者的诞生:为什么Istio有如此高的呼声? 什么是 Istio? 官方定义:它是一个完全开源的服务网格,作为透明的一层接入到现有的分布式应用中。它也是一个平台,可以与任何日志、遥测和策略系统进行集成。Istio 多样化的特性让你能够成功且高效地运行微服务架构,并提供保护、连接和监控微服务的统一方法。 Service Mesh 的新形态:增加控制平面 为什么 Istio 能 C 位出镜? 出击及时(2017 年 5 月发布 0.1版本) 三巨头光环加身 第二代 Service Mesh Envoy 的加入让
首先了解istio的认证策略和相关的mutual TLS认证概念,然后使用default配置安装istio
istio 中的授权策略为网格内部的服务提供访问控制。授权策略是快速、强大及被广泛使用的功能,自istio 1.4首次发布以来,我们进行了持续改进,以使策略更加灵活,包含 DENY action, 排除语义, X-Forwarded-For 头支持, 嵌套 JWT claim 支持等,这些功能提高了授权策略的灵活性,但是此模型仍然不支持许多用例,例如:
部署Bookinfo。由于下例在策略中使用了principal和namespace,因此需要启用mutual TLS。
[1] https://k8s.io/docs/concepts/services-networking/ingress
在过去两年,以Istio为代表的Service Mesh的问世因其出色的架构设计及火热的开源社区在业界迅速聚集了一批拥簇者,BAT等大厂先后也发布了自己的Service Mesh落地方案并在生产环境中部署运行。Service Mesh不仅可以降低应用变更过程中因为耦合产生的冲突(传统单体架构应用程序代码与应用管理代码紧耦合),也使得每个服务都可以有自己的团队从而独立进行运维。在给技术人员带来这些好处的同时,Istio的安全问题也令人堪忧,正如人们所看到的,微服务由于将单体架构拆分为众多的服务,每个服务都需要访问控制和认证授权,这些威胁无疑增加了安全防护的难度。Istio在去年一月份和九月份相继曝出三个未授权访问漏洞(CVE-2019-12243、CVE-2019-12995、CVE-2019-14993)[12],其中CVE-2019-12995和CVE-2019-14993均与Istio的JWT机制相关,看来攻击者似乎对JWT情有独钟,在今年2月4日,由Aspen Mesh公司的一名员工发现并提出Istio的JWT认证机制再次出现服务间未经授权访问的Bug, 并最终提交了CVE,CVSS机构也将此CVE最终评分为9.0[6],可见此漏洞之严重性。
Ingress、Istio 和 APISIX 都是与云原生环境紧密相关的技术,在现代应用部署中扮演着重要角色,尤其是在微服务架构中。今天这篇文章内容,先弄明白他们都是干嘛的,然后有什么区别,后面的文章再分别深入展开实例了解。
本文为云原生应用安全防护系列的第二篇,也是最终篇,本文笔者主要针对微服务架构下的应用安全、Serverless安全提出一些防护见解及思考。文章篇幅较长,内容上与之前笔者发表的若干文章有相互交叉对应的部分,希望能为各位读者带来帮助。
第2章 Istio入门 ---- 什么是Istio 它是一个完全开源的服务网格,以透明层的方式构建在现有分布式应用中。它也是一个提供了各种API的平台,可以与任何日志平台、监控系统或策略系统集成。Istio的多样化特性可以让你高效地运行分布式微服务架构,并提供一种统一的方式来保护、连接和监控微服务 Istio为微服务应用提供了一个完整的解决方案,可以以统一的方式去检测和管理微服务。同时,它还提供了管理流量、实施访问策略、收集数据等功能,而所有这些功能都对业务代码透明,即不需要修改业务代码就能实现 有了Ist
- 前言 - 在本教程中,我们将介绍服务网格的基础知识,并了解它如何实现分布式系统架构。 我们将主要关注Istio,它是服务网格的一种具体实现。在此过程中,我们将介绍Istio的核心架构。 - 什么是服务网络 - 在过去的几十年中,我们已经看到了单体应用程序开始拆分为较小的应用程序。此外,诸如Docker之类的容器化技术和诸如Kubernetes之类的编排系统加速了这一变化。 尽管在像Kubernetes这样的分布式系统上采用微服务架构有许多优势,但它也具有相当的复杂性。由于分
译文链接: https://zhuanlan.zhihu.com/p/369068128 译者:iyacontrol 来源:分布式实验
我们将主要关注Istio,它是服务网格的一种具体实现。在此过程中,我们将介绍Istio的核心架构。
微服务网关(Microservices Gateway)是微服务架构中的一种关键组件,它作为一个入口点,接收客户端的请求并将其路由到相应的微服务上。它起到了前端与后端微服务之间的“门户”的作用,协调整个微服务系统的请求流量和服务访问。具备的功能如下:
微服务架构可谓是当前软件开发领域的技术热点,它在各种博客、社交媒体和会议演讲上的出镜率非常之高,无论是做基础架构还是做业务系统的工程师,对微服务都相当关注,而这个现象与热度到目前为止,已经持续了近 5 年之久。
冉昕,腾讯云服务网格TCM产品经理,现负责云原生流量接入网关与应用通信可观测性等产品特性策划与设计工作。
大家好,我是来自灵雀云的邢海涛,今天演讲的主题是Service Mesh安全,主要从四个方面来跟大家做一下分享。首先介绍Service Mesh 安全需求,然后详细介绍Istio的安全实现,随后介绍两款Service Mesh产品的安全特性:LinkerD 和 Alauda Service Mesh。希望通过这个演讲,让大家了解Istio的无代码侵入,灵活的安全解决方案,启发大家思考自己的安全解决方案,以及如何迁移到Istio的安全模型。
从上面的定义中可以了解到,Istio 为微服务应用提供了一个完整的解决方案,可以以统一的方式去检测和管理微服务。同时,它还提供了管理流量、实施访问策略、收集数据等功能,而所有这些功能都对业务代码透明,即不需要修改业务代码就能实现。
Dubbo 在 2011 开源之后,一直是国内最受欢迎的 RPC 框架,之后 Spring Boot 和 Spring Cloud 的面世,助推了微服务的火热程度。计算机的世界变化很快,自从容器和 K8s 登上舞台之后,给原有的 RPC 领域带来了很大的挑战。这个文章主要讲述 RPC 领域遇到的问题,以及 RPC 怎么去拥抱 K8s 怀抱的一些思考。
既然我们已经对Istio的核心概念有了深入的了解,那就让我们来使用它吧。我们将部署包含在Istio发行版中的示例Bookinfo应用程序,稍后我们将使用一些Istio bells和whistles对其进行改进。具体来说,我们将演示Zipkin的分布式跟踪和JWT的强制用户身份验证。
Istio 提供一种简单的方式来为已部署的服务建立网络, Istio 使用 Envoy 代理的扩展版本, Envoy 被部署为 sidecar,和对应服务在同一个 Kubernetes pod 中。下面我们开始在mac m1环境搭建istio。
框架解耦的流量管理能力作为ServiceMesh的看家本事,一直是大多数团队选择ServiceMesh的主要原因。传统的流量管理大多需要在框架层面集成一种中心化的服务发现中心,通过服务发现中心去做流量控制分发。这对服务发现中心的的稳定性要求很高,同时限制了框架选择和扩展性。而ServiceMesh基于 sidecar 形式通信代理,将服务和流量控制解耦,服务不关心流量从哪里来,去往哪个具体ip,sidecar通过流量劫持的形式,对进出服务的流量进行修改,达到控制流量的目的,类似中间人攻击。
大概很多人和我一样,是从 Istio 那里听说 SPIFFE(读音 Spiffy [ˈspɪfi]) 的,Istio 中用 SPIFFE 方式为微服务提供身份。SPIFFE 全称为 Secure Production Identity Framework For Every one,顾名思义,这是一个解决身份问题的框架;而 SPIRE 则是 SPIFFE 的一个实现,全称为 SPIFFE Runtime Environment。
本文是在看了国外 Solo 公司 CTO 的博客之后整理的,本来是想按原文翻译,但是考虑到我自己在公司实践的思路,还是想把他的思路和我自己的思路做一些结合。所以本文中有部分内容是来自这位高手的思考,也有有我在公司实践中的思考。
了解Istio得从微服务架构谈起,微服务是在2012年提出的概念,其根本思想是通过拆分原则,希望一个服务只负责业务中一个独立的功能,这样任何一个需求不会因为发布或者维护而影响到不相关的服务,所有服务都可以做到独立部署运维,当然这也只是微服务架构给我们带来的好处之一。
最初于2018年11月17日在Medium发布。自此以来,该帖子已更新,可以使用最新版本的JHipster(6.3.0)和Istio(1.3.0)。
将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性、可伸缩性和可复用性。但这也带来了一些安全问题:
JSON Web Token (JWT) 是一个开放标准 ( RFC 7519 ),它定义了一种紧凑且自包含的方式,用于在各方之间以 JSON 对象的形式安全传输信息。此信息可以验证和信任,因为它是数字签名的。JWT 可以使用密钥(使用HMAC算法)或使用RSA或ECDSA的公钥/私钥对进行签名。
JSON Web Token (JWT) 是一个开源标准(RFC 7519),它定义了一种紧凑且自完备的方法用于在各参与方之间以JSON对象传递信息。以该种方式传递的信息已经被数字签名,因而可以被验证并且被信任。JWT既可以使用盐(secret)(HMAC算法)进行签名,也可以使用基于RSA/ECDSA算法的公钥/秘钥对进行签名。
JWT介绍 JSON Web Token(JWT)是一种开放标准(RFC 7519),它定义了一种紧凑独立的基于JSON对象在各方之间安全地传输信息的方式。这些信息可以被验证和信任,因为它是数字签名的。JWTs可以使用一个密钥(HMAC算法),或使用RSA的公钥/私钥密钥对对信息进行签名。 让我们进一步解释这个定义的一些概念。 紧凑 由于其较小的体积,JWTs可以通过URL、POST参数或HTTP头部参数进行传递,体积小也意味着其传输速度会相当快。 独立 有效负载包含了所需要的关于用户的所有信息,避免了
JSON Web Token (JWT)是一个开放标准(RFC 7519),它定义了一种紧凑的、自包含的方式,用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任,因为它是数字签名的。
系统开发来讲,安全验证永远是最重要的,从最原始的session、cookie验证方式,到符合restful风格、满足前后端分离需求、启用https请求,各方面都在不断变化中。
备注:本文根据腾讯云赵化冰和知乎唐阳在 IstioCon 2021 中的演讲 “How to Manage Any Layer-7 Traffic in an Istio Service Mesh?”
赵化冰,腾讯云高级工程师,Istio Member,ServiceMesher管理委员,Istio 项目贡献者, Aerika 项目创建者 ,热衷于开源、网络和云计算。目前主要从事服务网格的开源和研发工作。 唐阳,知乎基础架构工程师。Istio 项目贡献者,Argo 项目贡献者,专注于开源,云原生与微服务。目前负责知乎服务网格的研发工作。 本文根据腾讯云高级工程师赵化冰和知乎基础架构工程师唐阳在 IstioCon 2021 中的演讲 “How to Manage Any Layer-7 Traffic
JSON Web Token(JWT)是一个开放式标准(RFC 7519),它定义了一种紧凑(Compact)且自包含(Self-contained)的方式,用于在各方之间以JSON对象安全传输信息。 这些信息可以通过数字签名进行验证和信任。 可以使用秘密(使用HMAC算法)或使用RSA的公钥/私钥对对JWT进行签名。
这里查看pod可能会发现有pod一直处于creating状态,通过describe命令可知“istio-token”找不到: MountVolume.SetUp failed for volume "istio-token":failed to fetch token: the API server does not have TokenRequest endpoints enabled 看我们的k8s集群是否支持第三方令牌 { "name": "serviceaccounts/token", "s
JWT是一种用于双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT作为一个开放的标准(RFC 7519),定义了一种简洁的,自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在,这些信息是可信的,JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。
Istio帮助使“服务网格”概念变得更加具体和可访问,随着Istio 1.0的最新发布,我们可以预期人们对它的兴趣会激增。Jasmine Jaksic在InfoQ之前的一篇文章中很好地介绍了Istio和服务网格,因此我想借此机会介绍Istio的一个特定领域,它将为云服务和应用程序的开发人员和运营商带来巨大的价值:安全性
JWT (JSON Web Token) 是目前最流行的跨域认证解决方案,是一种基于 Token 的认证授权机制。 从 JWT 的全称可以看出,JWT 本身也是 Token,一种规范化之后的 JSON 结构的 Token。
多租户方案是指由多个客户或租户共同使用应用的解决方案。 租户不同于用户,来自单个组织、公司或组的多个用户形成一个租户。
现在最火的后端架构无疑是微服务了,微服务将之前的单体应用拆分成了许多独立的服务应用,每个微服务都是独立的,好处自然很多,但是随着应用的越来越大,微服务暴露出来的问题也就随之而来了,微服务越来越多,管理越来越麻烦,特别是要你部署一套新环境的时候,你就能体会到这种痛苦了,随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等问题。如果从头到尾完成过一套微服务框架的话,你就会知道这里面涉及到的东西真的非常多。当然随着微服务的不断发展,微服务的生态也不断完善,最近新一代的微服务开发就悄然兴起了,那就是服务网格/Service Mesh。
领取专属 10元无门槛券
手把手带您无忧上云