继续我的第一篇文章关于服务网格的概念和讨论,接下来我将关注NATS 2.0和服务网格在安全领域的概念。服务网格的安全部分包括端到端加密(相互TLS)、身份验证、授权策略以及服务之间的服务到服务访问控制。有了NATS 2.0和NKeys、JWT以及操作员-帐户-用户安全模型的引入,我相信可以使用NATS,实现更安全的通信基础设施。在这篇文章中,我们将详细讨论这个问题,并将NATS模型与主流服务网格的安全模型进行比较和对比。
Istio 从 v1alpha3 开始,用 Ingress Gateway 组件替代了符合 Kubernetes 规范的 Ingress Controller,因此对入站流量具有了更大的控制能力,但是用法也有了较大不同。
Istio 1.1 已于今天发布了正式版,官方表示自推出 1.0 正式版后,用8个月的时间对整个产品进行了一些重大改进,其中包括来自华为,Google,IBM,VMware,RedHat,思科,SAP,Salesforce,Pivotal,SUSE,Datadog 和 LightStep 等厂商提供的修复和功能。
默认情况下,istio的CA会生成一个自签的根证书和密钥,并使用它们签发负载证书。istio的CA也会使用管理员指定的证书和密钥,以及管理员指定的根证书来签发负载证书。本节展示如何将这些证书和密钥插入Istio的CA。
书籍英文版下载链接为 https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/,作者 Burr Sutter 和 Christian Posta。
先说说泛解析证书。 之前通过免费的地址可免费申请泛解析证书,后来貌似被发现恶意签发,被停止了。 然而我在 :https://www.91yun.co/archives/22961看到了80VPS赞助的野卡证书。 泛解析证书最大的好处是再也不用每一个二级域名签发一次证书,一次签发域名下通用。 说起证书,我想起了之前GitHUB学生包里面有$9一年的证书,但是对于我这种博客和脚本公用的人来说, 就会使得Linux服务器获取脚本时候出现: Unable to locally verify the issuer's
在上一篇文章一文带你彻底厘清 Kubernetes 中的证书工作机制中,我们介绍了 Kubernetes 中证书的工作机制。在这篇文章中,我们继续探讨 Istio 是如何使用证书来实现网格中服务的身份认证和安全通信的。
作者赵化冰,腾讯云高级工程师,Istio Member,ServiceMesher管理委员,热衷于开源、网络和云计算。目前主要从事服务网格的开源和研发工作。 目录 Istio 安全架构 控制面证书签发流程 为什么要通过 Pilot-agent 中转? 控制面身份认证 SDS 工作原理 网格边车证书配置 Gateway 证书配置 数据面使用的所有证书 小结 参考文档 在这篇文章中,我们将探讨 Istio 是如何使用证书来实现网格中服务的身份认证和安全通信的。 本文是对 Istio 认证工作机制的深度分
大家好,我是来自灵雀云的邢海涛,今天演讲的主题是Service Mesh安全,主要从四个方面来跟大家做一下分享。首先介绍Service Mesh 安全需求,然后详细介绍Istio的安全实现,随后介绍两款Service Mesh产品的安全特性:LinkerD 和 Alauda Service Mesh。希望通过这个演讲,让大家了解Istio的无代码侵入,灵活的安全解决方案,启发大家思考自己的安全解决方案,以及如何迁移到Istio的安全模型。
在Istio项目中,watcher.go文件位于istio/pilot/pkg/keycertbundle目录下,它的主要作用是管理密钥和证书的观察者(watcher)。
上一篇中我们介绍了EnvoyXdsServer的结构以及EnvoyXdsServer的启动流程、怎么与envoy客户端建立连接,当Istio CRD配置、K8s服务事件变化后,怎么监控到事件并把相关配置传到EnvoyXdsServer的channel中,如何进行防抖及推送,最后把事件传到每个客户端的connection中。这里我们介绍下envoy客户端的启动过程以及envoy如何与istiod建立连接。
Istio帮助使“服务网格”概念变得更加具体和可访问,随着Istio 1.0的最新发布,我们可以预期人们对它的兴趣会激增。Jasmine Jaksic在InfoQ之前的一篇文章中很好地介绍了Istio和服务网格,因此我想借此机会介绍Istio的一个特定领域,它将为云服务和应用程序的开发人员和运营商带来巨大的价值:安全性
https://istio.io/latest/docs/reference/config/networking/gateway/#ServerTLSSettings credentialName: The secret (of type generic) should contain the following keys and values: key: <privateKey> and cert: <serverCert> 创建证书 k8s secret 在 标准模式 下, 必须使用 key 作为私钥
随着虚拟化技术的不断发展,以容器为核心的微服务概念被越来越多人认可,Istio因其轻量级、服务网格管理理念、兼容各大容器编排平台等优势在近两年脱颖而出,许多公司以Istio的架构设计理念作为模板来管理自己的微服务系统,但在其势头发展猛劲之时,也有许多专家针对Istio的安全机制提出了疑问,比如在Istio管理下,服务间的通信数据是否会泄露及被第三方劫持的风险;服务的访问控制是否做到相对安全;Istio如何做安全数据的管理等等,这些都是Istio目前面临的安全问题,而我们只有深入分析其机制才能明白Istio是如何做安全的。
签名我们了解了位于服务网格内部的应用应如何访问网格外部的 HTTP 和 HTTPS 服务,我们学习了如何通过 ServiceEntry 对象配置 Istio 以受控的方式访问外部服务,这种方式实际上是通过 Sidecar 直接调用的外部服务,但是有时候我们可能需要通过专用的 Egress Gateway 服务来调用外部服务,这种方式可以更好的控制对外部服务的访问。
微服务架构中,各服务间常有通信交互,以完成复杂业务流程,这给安全性和可扩展性带来挑战。启用双向 TLS(mTLS)可提高安全性,本文将详述 mTLS 的使用入门方法。
前面我们已经完成了OPNsense的安装和基本设置,现在开始OPNsense的各项常用功能设置。本文主要是讨论OPNsense的系统管理部分的常用内容。
将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性、可伸缩性和可复用性。但这也带来了一些安全问题:
在kubernetes环境中,kubernetes ingress资源用于指定暴露到集群外的服务。在istio服务网格中,使用了一种不同的配置模型,称为istio网关。一个网关允许将istio的特性,如镜像和路由规则应用到进入集群的流量上。
本文是旧文更新,由于 cert-manager-webhook-dnspod 之前的作者很久没有继续维护,chart 包已不兼容最新的 cert-manager ,所以博主决定自己开发一个,支持最新版 cert-manager,且接入腾讯云API密钥 (DNSPod 被腾讯收购,官方推荐用腾讯云标准的云 API 密钥方式,而不用 apiID 和 apiToken)。本文内容中使用的 cert-manager-webhook-dnspod 也替换成了新开发的版本,开源地址: https://github.com/imroc/cert-manager-webhook-dnspod
安全是一个非常重要的话题,但也是平时容易被忽略的一个话题,我们在开发应用的时候,往往会忽略安全,但是当应用上线后,安全问题就会暴露出来,这时候就会造成很大的损失。Istio 通过在服务之间注入 Sidecar 代理,来实现对服务之间的流量进行控制和监控,从而实现服务之间的安全通信。
如果你的域名使用 DNSPod 管理,想在 Kubernetes 上为域名自动签发免费证书,可以使用 cert-manager 来实现。
- 前言 - 在本教程中,我们将介绍服务网格的基础知识,并了解它如何实现分布式系统架构。 我们将主要关注Istio,它是服务网格的一种具体实现。在此过程中,我们将介绍Istio的核心架构。 - 什么是服务网络 - 在过去的几十年中,我们已经看到了单体应用程序开始拆分为较小的应用程序。此外,诸如Docker之类的容器化技术和诸如Kubernetes之类的编排系统加速了这一变化。 尽管在像Kubernetes这样的分布式系统上采用微服务架构有许多优势,但它也具有相当的复杂性。由于分
译文链接: https://zhuanlan.zhihu.com/p/369068128 译者:iyacontrol 来源:分布式实验
我们将主要关注Istio,它是服务网格的一种具体实现。在此过程中,我们将介绍Istio的核心架构。
通过将一个单一应用划分为多个原子服务的方式,可以提供更好的灵活性,可扩展性以及重用服务的能力。然而微服务对安全有特殊的要求:
7月17日,在Cloud Native Days China云原生多云多集群专场,eBay软件工程师陈佑雄发表了《eBay基于Istio的应用网关的探索和实践》主题演讲,分享了eBay在多集群,多环境,大规模的场景下,Istio落地实践的探索和实践。
尽管 Istio 提供多集群连接功能,但配置它可能会复杂而繁琐。新工具可以提供帮助。
在 Intenseye,我们 follow(跟随) trends(趋势) & hype(最被炒作) 的技术,并在使用时应用最佳实践。我们在用 Scala、Go、Python 等编写的 Kubernetes 上运行了数百个 pod,其中大多数使用 gRPC。
Helm 是目前 Istio 官方推荐的安装方式,除去安装之外,还可以利用对输入值的一些调整,完成对 Istio 的部分配置工作。官方提供了 Istio 的 Helm 部署方式,侧重于快速启动,而这一组文章将会采用由上至下的顺序,基于 Istio 1.0.2 版本的 Helm Chart 做一系列的讲解。
本文主要和大家聊一聊istio的双向tls。双向 tls支持主要针对通信方面,将明文传输的服务通信,转换为 Envoy 之间的加密通信。这一安全设置可以在全局、Namespace 或者单个服务的范围内生效。
istio搁置有一段时间了,并且现在开始介入的是最新版本1.4.2,所以难免有些错误的地方,非常欢迎指正与讨论。
用户空间Pod要想加入服务网格, 首先需要注入sidecar container, istio 提供了2种方式实现注入:
作者赵化冰,腾讯云高级工程师,Istio contributor,ServiceMesher管理委员,热衷于开源、网络和云计算。目前主要从事服务网格的开源和研发工作。 本系列文章将介绍用户从 Spring Cloud,Dubbo 等传统微服务框架迁移到 Istio 服务网格时的一些经验,以及在使用 Istio 过程中可能遇到的一些常见问题的解决方法。 什么是『无头服务』? 『无头服务』即 Kubernetes 中的 Headless Service。Service 是 Kubernetes 对后端一组提供
本系列文章将介绍用户从 Spring Cloud,Dubbo 等传统微服务框架迁移到 Istio 服务网格时的一些经验,以及在使用 Istio 过程中可能遇到的一些常见问题的解决方法。
微服务架构可谓是当前软件开发领域的技术热点,它在各种博客、社交媒体和会议演讲上的出镜率非常之高,无论是做基础架构还是做业务系统的工程师,对微服务都相当关注,而这个现象与热度到目前为止,已经持续了近 5 年之久。
越来越多的现代云原生应用开发体系中都会有好几个独立的开发团队,每个团队采用不同的开发迭代周期,新功能以周或天为单位迭代上线,只对他们自己的任务负责。Istio的使命是从组成整个应用的所有微服务层面,确保一定程度的连续性。Isitio的关键能力之一是实施安全约束,同时对每个服务的逻辑代码透明。有了Istio代理后,你就可以在服务之间的网络层面施加这些约束。
我们将继续按照2020年发布的路线图中概述的方向航行,提高可用性,安全性和可靠性,并专注于多集群网格和VM工作负载。我们已经在必要时引入了新功能来实现这些目标,但总的来说,我们一直专注于错误修复和完善-我们将一直持续到2021年。
作者:Christian Posta 译者:海松 原题:Low-risk Monolith to Microservice Evolution Part II 继续来深入探讨!在之前的文章(第一部分)中,我们为本篇文章建立了一个上下文环境(以便于讨论)。一个基本原则是,当微服务被引入到现有架构中时,不能也不应该破坏当前的请求流程(request flows)。“单体应用(monolish)”程序依然能带来很多商业价值(因此仍将在新的时代被使用,编者注),我们只能在迭代和扩展时,尽可能地减少其负面影响,这
该文为前期热门文章《eBPF将如何提供服务网格解决方案--告别sidecar》的后续。其介绍了Cilium提供非sidecar模式的服务网格的解决方案。在本篇文章中,我们将目光扩展到mTLS的主题上,并研究Cilium如何提供基于mTLS非sidecar模式的双向认证,其同时具备出色的安全性和性能优势。
接下来我们配置一个安全网关,为外部提供 HTTPS 的访问方式。首先,确认 curl 命令是否通过LibreSSL去编译的:
•添加了 values.global.proxy.holdApplicationUntilProxyStarts config选项,它使sidecar注入器在pod容器列表的开始处注入sidecar,并将其配置为阻止所有其他容器的开始,直到代理就绪为止。默认情况下禁用此选项。(#11130)•新增了对用于客户端证书和CA证书的SDS支持,该证书用于使用DestinationRule从Egress Gateway发起的TLS/mTLS(#14039)
Istio 为网格中的微服务提供了较为完善的安全加固功能,在不影响代码的前提下,可以从多个角度提供安全支撑,官方文档做了较为详细的介绍,但是也比较破碎,这里尝试做个简介兼索引,实现过程还是要根据官方文档进行。
不同于1.1版本万众期待,发布时间一推再推,最后历时七个半个月,1.2的发布效率确实出乎很多人意外。但是注意到1.2版本前1.1版本足足发满了1.1.1~1.1.9九个小版本,1.2更像是第三位满十进位的一个版本。总体看下来没有大的特性增加,更像是一个对于1.1中大粒度特性和之前特性的完善、增强和Bug修复。
这是一个系列文章,将会通过七篇内容和大家一起聊聊 Kubernetes 中的证书管理。
本教程已加入 Istio 系列:https://istio.whuanle.cn
这是我在kubernetes之上部署Istio系列文章中的第三篇,内容是关于我们试图通过Vamp Lamia实现的更多细节以及我们为什么选择Istio的原因,可以查看我的第一篇和第二篇文章。
Istio网关Gateway是一个负责处理南北向流量的组件,它通常会暴露服务网格内部的服务,以便外部的请求能够访问到服务网格中的服务。Istio网关Gateway支持多种协议,包括HTTP、HTTPS和GRPC等。
涵盖官方文档Traffic Management章节中的egress部分。其中有一小部分问题(已在下文标注)待官方解决。
本章的内容主要是讲解服务间通讯的安全和集群外部访问内部服务的 jwt token 验证。
领取专属 10元无门槛券
手把手带您无忧上云