idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

摘要
使用 Istio 可以很方便地实现微服务间的访问控制。本文演示了使用 Denier 适配器实现拒绝访问,和 Listchecker 适配器实现黑白名单两种方法。

使用场景

有时需要对微服务间的相互访问进行控制,比如使满足某些条件(比如版本)的微服务能够(或不能)调用特定的微服务。

访问控制属于策略范畴,在 Istio 中由 Mixer 组件实现。

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

Mixer拓扑图,来源官方文档

如上图所示,服务的外部请求会被 Envoy 拦截,每个经过 Envoy 的请求都会调用 Mixer,为 Mixer 提供一组描述请求和请求周围环境的属性。Mixer 进行前置条件检查和配额检查,调用相应的 adapter 做处理,并返回相应结果。Envoy分析结果,决定是否执行请求或拒绝请求。从而实现了策略控制。

环境准备

在 Kubernetes 集群上部署 Istio

部署 Bookinfo 示例应用

配置 Bookinfo 应用各个微服务的 destinationrule 和 virtualservice。其中 reviews 服务的 destinationrule 和 virtualservice 配置如下:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

按上图配置后,对于 reviews 服务的请求,来自用户 “kokokobe” 的请求会被路由到v2 版本,其他用户的请求会被路由到 v3 版本。

使用 Denier 适配器实现简单的访问控制

使用 Istio 对微服务进行访问控制时,可以使用 Mixer 中的任何属性。这是一种简单的访问控制,实现基础是通过 Mixer 选择器拒绝某些条件下的请求。

比如,上文所述的 Bookinfo 应用中的 ratings 服务会被多个版本的 reviews 服务访问。下面的示例中我们将会切断来自 v3 版本的 reviews 服务对 ratings 服务的调用。

  1. 用浏览器打开 Bookinfo 的 productpage(http://$GATEWAY_URL/productpage

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

如上图所示,如果用 “kokokobe” 的用户登录,能看到每条 review 下面的黑色星星,说明此时 ratings 服务被 v2 版本的 reviews 服务调用。

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

从上面两张图可以看出,如果使用其他用户登录(或未登录),能看到每条 review 下面的红色星星,说明此时 ratings 服务被 v3 版本的 reviews 服务调用。

  1. 创建 denier 适配器,拒绝来自 v3 版本的 reviews 服务对 ratings 服务的调用

编辑 mixer-rule-deny-label.yaml 内容如下:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

这也是Mixer的adapter的标准配置格式,一般需要配置三种类型的资源:

  1. 配置一组 handler。Handler是配置好的 adapter 的实例,adapter 封装了 Mixer 和特定基础设施后端之间的接口。

  2. 基于 template 配置一组 instance。Instance 定义了如何将 Envoy 提供的请求属性映射到 adapter 的输入。

  3. 配置一组规则。这些规则描述了何时调用特定的 handler 及 instance。

在这里其中定义了一条名为 denyreviewsv3 的规则,一个 denier 类型的 handler,一个checknothing 类型的模板的实例。

在 denyreviewsv3 规则中,方框内的条件表达式匹配的条件是:来自 reviews 服务,version 为 v3 ,目标为 ratings 服务的请求。这条规则使用 denier 适配器拒绝来自 v3 版本的 reviews 服务的请求。

这个 denier 适配器会拒绝符合上述规则的请求。可以预先指定 denier 适配器的状态码和消息,如方框中所示。

然后执行如下命令创建上述规则的 denier 适配器:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

  1. 在浏览器中刷新 productpage 页面

如果已经登出或者使用不是 “kokokobe” 的用户身份登录,不再看到红色星星,因为v3版本的 reviews 服务对 ratings 服务的访问已经被拒绝了。

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

相反,如果使用 “kokokobe” 用户登录,仍然能够看到黑色星星。因为该用户使用的是 v2 版本的 reviews 服务,不符合拒绝的条件。

通过listchecker适配器实现黑白名单

Istio 也支持基于属性的黑名单和白名单。下面的白名单配置和上一节的 denier 配置是等价的,拒绝来自 v3 版本的 reviews 服务的请求。

  1. 删除上一节配置的 denier 规则

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

  1. 在登出状态下浏览 Bookinfo 的 productpage(http://$GATEWAY_URL/productpage

此时能看到红星图标。在完成下述步骤之后,只有在使用 “kokokobe” 的身份登录之后才能看到星形图标。

  1. 创建包含 v2 版本白名单的 listchecker 适配器

编辑 whitelist-handler.yaml 内容如下:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

通常会在外部维护黑白名单的列表,然后指定 providerUrl 参数进行异步获取。在这个例子中,我们使用 overrides 字段提供一个静态的黑白名单列表。

然后运行如下命令创建 listchecker 适配器:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

  1. 创建一个 listentry 模板的实例

Listentry 模板可以用来判别一个字符串是否存在于一个列表中,本例中我们使用它来判别版本标签是否存在于白名单中。

编辑 appversion-instance.yaml 内容如下:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

然后运行如下命令:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

  1. 为 ratings 服务启用 whitelist 检查功能

编辑 checkversion-rule.yaml 内容如下:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

然后运行如下命令:

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

  1. 在浏览器中刷新 productpage 页面

如果已经登出或者使用不是 “kokokobe” 的用户身份登录,看不到星形图标;如果使用 “kokokobe” 用户登录,仍然能够看到黑色星星。

总结

通过上述示例,可以发现使用 Istio 实现微服务间的访问控制非常方便。既可以使用denier 适配器实现简单的访问控制,也可以通过listchecker 适配器实现较复杂的黑白名单。

相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

原文地址:http://blog.51cto.com/14051317/2348359

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


istio的授权功能,也称为基于角色的访问控制(RBAC),它为istio服务网格中的服务提供命名空间级别、服务级别和方法级别的访问控制。基于角色的访问控制具有简单易用、灵活和高性能等特性。本文介绍如何在服务网格中为服务进行授权控制。·前置条件·•安装istio的k8s集群,启用认证功能、
Errorfromserver(Forbidden):errorwhencreating"oot/istio.yaml":configmaps"istio-galley-configuration"isforbidden:unabletocreatenewcontentinnamespaceistio-systembecauseitisbeingterminatedErrorfromserver(Forbid
3.1Istio的核心组件及其功能Istio总体分两部分:控制面和数据面。数据面(sidecar):sidecar通过注入的方式和业务容器共存于一个pod,会劫持业务容器的流量,并接受控制面组件的控制,同时会向控制面输出日志、跟踪以及监控数据。控制面:Istio的核心,管理Istio的所有功能。
在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统。本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS。使用场景 在部署了Istio的集群中,使用人员
在之前的最佳实践中,已经带大家通过一系列的实践任务领略了Istio的无穷魅力。今天,将向大家介绍如何用Istio实现流量熔断。熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意***等场景。在接下来
流量镜像流量镜像,也称为影子流量,流量镜像提供一种尽可能低的风险为生产带来变化的强大功能。镜像会将实时流量的副本发送到镜像服务。镜像流量发生在主服务的关键请求路径之外。在非生产或者测试环境中,尝试访问一个服务所有可能的测试用例组合是个非常不现实的任务。在某些情况下
一、负载均衡算法原理与实战负载均衡算法(loadbalancingalgorithm),定义了几种基本的流量分发方式,在Istio中一共有4种标准负载均衡算法。•Round_Robin:轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求。•Random:随机算法,将所有的请求随机分发给健康的实例•
本文整理自华为CloudBU技术专家在K8S技术社上关于Istio调用链的分享。前言大家好,我是idouba,来自华为CloudBU,当前在做Istio服务网格在华为云容器服务的产品化工作。今天跟大家分享的主题是Istio调用链相关内容。通过剖析Istio的架构机制与Istio中调用链的工作原理来解答一个大
今天,我们就来谈谈Istio主打功能---保护服务。那么,便引出3个问题:Istio凭什么保护服务?Istio具体如何保护服务?如何告诉Istio发挥保护能力?Istio凭什么保护服务?将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性、可伸缩性和可复用性
istio-opentracing链路追踪方案istio-opentracing链路追踪主要是由sidecar(envoy)支持的,istio只是在上层进行配置的修改。envoy链路追踪envoy主要用三个功能来支撑系统范围内的跟踪生成RequestID:envoy会在需要的时候生成UUID,并操作名为[x-request-id]的HTTPHeader。应用可
在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移。这两个方面的功能都是Istio流量治理的一部分。今天将继续带大家了解Istio的另一项功能,关于请求超时的管理。首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理。看过ido
调用链原理和场景正如ServiceMesh的诞生是为了解决大规模分布式服务访问的治理问题,调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器,可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用
在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统。本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS。使用场景在部署了Istio的集群中,使用人员刚
前言在Istio的世界里,如果想把外部的请求流量引入网格,你需要认识并会学会配置IstioIngressGateway什么是IngressGateway由于KubernetesIngressAPI只能支持最基本的HTTP路由,使用KubernetesIngress资源来配置外部流量的方式不能满足需求。因此Istiov1alpha3routingAPI引
Istio是什么?使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给DevOps团队带来压力。开发人员必须使用微服务已满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上,Istio有助于降低这些
Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness:liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用。readiness探针用来使容器准备好接收流量。
摘要使用Istio可以很方便地实现微服务间的访问控制。本文演示了使用Denier适配器实现拒绝访问,和Listchecker适配器实现黑白名单两种方法。使用场景有时需要对微服务间的相互访问进行控制,比如使满足某些条件(比如版本)的微服务能够(或不能)调用特定的微服务。访问控制属于策略
导读目前以Kubernetes为基础构建的容器生态逐渐完善,这其中Kubernetes、Istio、Knative三个独立项目被越来越多的人提及,并且已经开始尝试大规模落地实践,它们恰好构成了容器云的未来拼图。今天与大家一起分享下,这三个项目究竟解决了什么问题,为什么它们能够一鸣惊人。随着微服务理念
注:以下讲述的按理环境场景是基于Kubernetes环境基础上部署的Istio环境。涉及到Envoy概念介绍请参考深度解析Istio系列之流量控制篇。本文重点针对Envoy初始化场景进行拆解。Istio-proxy(Envoy)作为Istio数据平面的重要组件,基于sidecar方式与业务应用混合部署到同一pod,为应用提
使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给DevOps团队带来压力。开发人员必须使用微服务以满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上,Istio有助于降低这些部署的复杂性,