egress | 伪架构师

Istio 大入门——Egress Gateway

Fri, 24 Aug 2018 11:46:24 +0800

Istio 还是早期版本的时候，我曾经有个蒙事的混蛋设想：在网格里面搭建一个反向代理，用于代理网格甚至是集群之外的存量应用，让这些改不得甚至动不得又正在赚钱的应用，以网格内成员的身份对网格中的微服务提供服务。后来知道了，Istio 的 Egress Gateway 实现了这一混蛋想法。

原理

根据官方文档的解释：

Gateway 描述了一个负载均衡器，用于承载网格边缘的进入和发出连接。这一规范中描述了一系列开放端口，以及这些端口所使用的协议、负载均衡的 SNI 配置等内容。

之前的 Service Entry 一文中讲到了 ServiceEntry 对象，让网格内部的应用在访问外部应用时，可以使用 VirtualService 进行部分控制。但是如果我们进一步尝试策略的话，会发现常用的 Denier 等适配器都是无效的（这点并没有经过官方验证）。这里就需要使用刚才说的 Egress Gateway 了。

根据官方示例介绍，这种方式的基本访问流程是：

建立 Service Entry 对象，注册外部服务。
建立 Egress Gateway 注册出口。
创建 DestinationRule，定义一个到 istio-egressgateway.istio-system.svc.cluster.local 服务的目标规则。
创建 VirtualService 对象，这一对象对主机名 edition.cnn.com 生效：
- 如果流量发生在 mesh gateway，则把请求转发给 istio-egressgateway.istio-system 服务。
- 如果流量发生在 egress gateway，则把请求转发到外部。

开始之前

跟前文一样，需要部署两个版本的 sleep 服务。源码见后。

$ istioctl kube-inject -f sleep-v1v2.yaml | kubectl apply -f -
service/sleep created
deployment.extensions/sleep-v1 created
deployment.extensions/sleep-v2 created

接下来把两个版本的 Pod 分别保存到环境变量之中。

$ export SLEEP_V1=$(kubectl get pod -l app=sleep,version=v1 -o jsonpath={.items..metadata.name})
$ export SLEEP_V2=$(kubectl get pod -l app=sleep,version=v2 -o jsonpath={.items..metadata.name})
$ env | grep SLEEP
SLEEP_V2=sleep-v2-69f4fc6c68-s9d96
SLEEP_V1=sleep-v1-d5b4f795f-fcrxs

再建立一个 ServiceEntry，完成准备工作。

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin-ext
spec:
  hosts:
    - httpbin.org
  ports:
    - number: 80
      name: http
      protocol: HTTP
  resolution: DNS

设立别名并确认可访问性：

$ alias S1_HTTPBIN="kubectl exec -it $SLEEP_V1 -c sleep -- curl http://httpbin.org/ip"
$ alias S2_HTTPBIN="kubectl exec -it $SLEEP_V2 -c sleep -- curl http://httpbin.org/ip"
$ S1_HTTPBIN
{
  "origin": "13.67.109.88"
}

成功返回。

创建 Gateway 和 DestinationRule

建立 Gateway

这里为域名 “httpbin.org” 创建一个网关，selector 字段表明这里使用的是 Egress gateway。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: egressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - httpbin.org

为服务 `istio-egressgateway` 创建一个目标规则

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dest-rule-httpbin
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  subsets:
    - name: ext

上面的 host 字段使用了 istio-egressgateway 的 FQDN，指向 istio-system 命名空间。

创建 VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-httpbin
spec:
  hosts:
    - httpbin.org # 这一对象对域名 “httpbin.org” 生效。
  gateways: # 本对象所针对的 Gateway。
    - httpbin-gateway # 前面为 “httpbin.org” 注册的 Egress gateway。
    - mesh # 内置 Gateway，代表网格中的所有 Sidecar
  http:
    - match: # 这一条规则匹配的是 “mesh” Gateway 的流量
        - gateways:
            - mesh
          port: 80
      route: # 如果是 “mesh” gateway 的流量，则转发到 egress 网关服务。
        - destination:
            host: istio-egressgateway.istio-system.svc.cluster.local
            subset: ext
            port:
              number: 80
          weight: 100
    - match:
        - gateways: # 这一条规则匹配的是外发流量
            - httpbin-gateway
          port: 80
      route: # 通过 Service Entry 流向目标的外网流量
        - destination:
            host: httpbin.org
            port:
              number: 80
          weight: 100

这一对象创建之后，我们再次尝试访问 “http://httpbin.org/ip” ：

$ S1_HTTPBIN
{
  "origin": "10.240.0.41, 13.67.109.88"
}

可以看到访问成功，并且返回地址中因为转发的原因，代入了 Pod IP。

如果查看 Egress gateway controller 的日志，也会看到这一访问的踪迹：

$ kubetail  egress -n istio-system
Will tail 1 logs...
istio-egressgateway-55449548bd-99mvl
[istio-egressgateway-55449548bd-99mvl] [2018-08-25T15:07:29.272Z] "GET /ip HTTP/2" 200 - 0 44 477 473 "10.240.0.41" "curl/7.35.0" "e9cc4d93-7617-9f97-b29e-3411c3b66543" "httpbin.org" "52.73.140.127:80"

加入策略限制

经过上面一番折腾之后，应用对外部网站的请求就有了一段完全在网格内的部分，接下来就可尝试使用策略了。

Denier

首先我们尝试编写一个 Denier 策略，只允许 “v2” 版本对 “httpbin.org” 的访问：

注意：跨命名空间的策略，必须在 “istio-system” 命名空间中创建。

---
apiVersion: config.istio.io/v1alpha2
kind: denier
metadata:
  name: denysleepv1
  namespace: istio-system
spec:
  status:
    code: 7
    message: Not allowed
---
apiVersion: config.istio.io/v1alpha2
kind: checknothing
metadata:
  name: denysleepv1request
  namespace: istio-system
spec: null
---
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: deneysleepv1
  namespace: istio-system
spec:
  match: >-
    source.labels["app"]=="sleep" && source.labels["version"]=="v1" &&
    request.host=="httpbin.org"
  actions:
    - handler: denysleepv1.denier
      instances:
        - denysleepv1request.checknothing

创建这一策略之后进行验证：

 $ kubectl apply -f denier.yaml -n istio-system
denier.config.istio.io/denysleepv1 created
checknothing.config.istio.io/denysleepv1request created
rule.config.istio.io/deneysleepv1 created
$ S1_HTTPBIN
PERMISSION_DENIED:denysleepv1.denier.istio-system:Not allowed
$ S2_HTTPBIN
{
  "origin": "10.240.0.21, 13.67.109.88"
}

由上面的测试可以看到，策略应用之后。来自 “v1” 的请求被禁止。如果进一步测试还可以发现，“v1” 服务对其他的访问还是可以照常进行。

补充：1.0.1 中，ServiceEntry 应该在 istio-system 中创建。

频率限制

再次失败，等 Issue。

源码

sleep.yaml

apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
spec:
  selector:
    app: sleep
  ports:
    - name: ssh
      port: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: sleep-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: sleep
        version: v1
    spec:
      containers:
      - name: sleep
        image: dustise/sleep:latest
        imagePullPolicy: IfNotPresent
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: sleep-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: sleep
        version: v2
    spec:
      containers:
      - name: sleep
        image: dustise/sleep:latest
        imagePullPolicy: IfNotPresent
---

Istio 小入门 —— ServiceEntry 的对外通信

Mon, 20 Aug 2018 19:44:05 +0800

上一篇讲了一些入口流量的事情，在实际项目运行中，还有另外一类边界流量，就是出口流量，也常被称为 egress 流量。这一篇结合一点实际需求，设计一些常用场景，讲讲服务网格中对外部服务的调用过程。

这里我们需要几个服务定义，首先是用于模拟客户端服务的工作负载，这里继续使用 dustise/sleep 镜像。外部我们使用两个网站作为我们的外部服务演示，分别代表 http 和 https 两种：http://httpbin.org 和 https://api.jd.com/。

开始之前

根据安装文档的说明完成 Istio 的部署，这里建议使用 Helm 方式。

使用的 dustise/sleep 镜像生成两个负载，使用 version 标签将负载拆分为 v1 和 v2 两个版本。源码见文末。

$ istioctl kube-inject -f sleep.dual.yaml | kubectl apply -f -
service/sleep created
deployment.extensions/sleep-v1 created
deployment.extensions/sleep-v2 created

然后使用环境变量保存新建 Pod 名称：

export SLEEP_V1=$(kubectl get pod -l app=sleep,version=v1 -o jsonpath={.items..metadata.name})
export SLEEP_V2=$(kubectl get pod -l app=sleep,version=v2 -o jsonpath={.items..metadata.name})

创建 `ServiceEntry`

首先创建一个 ServiceEntry，指向 httpbin.org：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin-ext
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS

然后给 api.jd.com 创建一个 ServiceEntry：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: jd-api
spec:
  hosts:
  - api.jd.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS

发起外部访问

$ kubectl exec -it $SLEEP_V1 -c sleep sh
/ # curl http://httpbin.org/ip
{
  "origin": "168.63.251.242"
}
/ # curl https://api.jd.com
<html>
...
</html>
/ # curl -v http://api.jd.com
...
< HTTP/1.1 404 Not Found
...
* Connection #0 to host api.jd.com left intact

可以看到，已经注册了的主机，可以通过对应的协议来进行访问了，但是如果协议不匹配，也会返回 404 代码。后面的内容，会选择几个常见场景进行演示。

服务质量监控

Istio 提供了很多的指标数据，对于外部服务来说，其服务端并不受控，但是还是可以从客户端获取一定的指标，来判断服务的状态。例如用下面的命令生成负载之后：

kubectl exec -it $SLEEP_V2 -c sleep -- wrk -d 10m http://httpbin.org/

可以在 Grafana 中看到如下的图形：

设置超时限制

外部应用的服务质量通常是不受调用方管理的，为了防止意外超时拖累整体应用，我们可以给外部服务设置一个超时限制，超过这一规则的调用直接中断。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin-service
spec:
  hosts:
  - httpbin.org
  http:
  - timeout: 3s
    route:
    - destination:
        host: httpbin.org

应用之后，再次进入 Pod 执行指令访问 http://httpbin.org：

$ kubectl apply -f httpbin-timeout.yaml
virtualservice.networking.istio.io/httpbin-service created
$ kubectl exec -it $SLEEP_V1 -c sleep sh
/ # time curl -sSL http://httpbin.org/delay/2 >> /dev/null
real    0m 2.51s
user    0m 0.00s
sys     0m 0.00s
/ # time curl -sSL http://httpbin.org/delay/5
upstream request timeout
real    0m 3.01s
user    0m 0.00s
sys     0m 0.00s

上面的测试可以看出，第二次的延迟五秒调用已经返回了超时的结果，并且是在我们的三秒限制之内完成了调用。

使用 kubectl delete -f httpbin-timeout.yaml 删除这一定义，进行下一步。

仅允许指定源头访问

设想我们的网格中，仅有部分应用可以访问一些外部服务，这里我们借用 Istio 的故障注入功能，定义一个 abort 的注入，只允许 sleep:v2 访问 http://httpbin.org，其他服务的访问尝试会失败。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin-service
spec:
  hosts:
  - httpbin.org
  http:
  - match:
    - sourceLabels:
        app: sleep
        version: v2
    route:
    - destination:
        host: httpbin.org
  - route:
    - destination:
        host: httpbin.org
    fault:
      abort:
        percent: 100
        httpStatus: 403

上面的定义中，我们首先让 sleep:v2 的筛选条件的请求，转发给 httpbin.org；而其余流量，则会被注入一个 403 错误。

我们分别从 sleep:v1 和 sleep:v2 服务发起对 httpbin.org 的访问：

$ kubectl exec  $SLEEP_V2 -c sleep -- curl -s http://httpbin.org/ip
{
  "origin": "168.63.251.242"
}
$ kubectl exec  $SLEEP_V1 -c sleep -- curl -s -v http://httpbin.org/ip
*   Trying 52.72.80.190...
...
< HTTP/1.1 403 Forbidden
< content-length: 18
< content-type: text/plain
< date: Wed, 22 Aug 2018 06:20:04 GMT
< server: envoy
<
{ [18 bytes data]
* Connection #0 to host httpbin.org left intact
fault filter abort%

可以看到，结果和我们的预测是一致的。

To be continued

上面所述，只是针对 ServiceEntry 的一些粗浅应用，Istio 还提供了 Egress Gateway 这样的高级组件。可以提供更多管理能力，敬请期待。

部分源码

sleep.yaml

apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
spec:
  selector:
    app: sleep
  ports:
    - name: ssh
      port: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: sleep-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: sleep
        version: v1
    spec:
      containers:
      - name: sleep
        image: dustise/sleep:v0.5
        imagePullPolicy: IfNotPresent
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: sleep-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: sleep
        version: v2
    spec:
      containers:
      - name: sleep
        image: dustise/sleep:v0.5
        imagePullPolicy: IfNotPresent

HTTP Egress 流量的监控和访问策略管理

Sat, 23 Jun 2018 10:48:57 +0800

原文：Monitoring and Access Policies for HTTP Egress Traffic

作者：VADIM EISENBERG 和 RONEN SCHAFFER

Istio 的主要功能就是在服务网格内部管理微服务之间的通信，除此之外，Istio 还能对 Ingress（从外部进入网格）和 Egress（从网格发出到外部）流量进行管理。不管是网格内部流量，还是 Ingress 或者 Egress 流量，Istio 都能够在其中进行访问策略的控制，并完成遥测数据的聚合工作。

本文中我们会展示如何使用 Istio 在 HTTP Egress 流量中实施监控和访问策略控制。文中谈到的内容针对 Istio 0.8.0 及以上是有效的。

用例

假设一个组织正在运行的应用需要处理来自于 cnn.com 的内容。这些应用已经被解构为部署在 Istio 服务网格中的微服务。这些应用要获取 cnn.com 多个频道的内容：edition.cnn.com/politics、edition.cnn.com/sport 以及 edition.cnn.com/health。目前已经配置 Istio 使其允许访问 edition.cnn.com，一切运行良好。然而在某一天，他们决定限制政治方面的内容，技术上讲，就是要阻止对 edition.cnn.com/politics 的访问，继续允许对 edition.cnn.com/sport 以及 edition.cnn.com/health 的访问。对 edition.cnn.com/politics 的访问需要在应用程序、命名空间以及用户的不同粒度上进行访问控制。

要实现这个目标，运维人员需要监控对外部服务的访问，并分析 Istio 日志来确保对 edition.cnn.com/politics 的访问都是经过授权的。另外他们还要配置 Istio，让 Istio 自动阻止对 edition.cnn.com/politics 的（未授权）访问。

该组织决定防止对新策略发生篡改，通过技术手段执行策略，防止恶意应用访问受限内容。

开始之前

依照配置 Egress Gateway，使用 Egress Gateway 执行 TLS 访问任务中的步骤，不要执行清理操作。完成之后，就可在网格之内使用安装了 curl 的容器来访问 edition.cnn.com/politics 了。下面的内容中，我们假设名为 SOURCE_POD 的环境变量中包含了 Pod 名称。

配置监控和访问策略

既然要用安全方式来完成任务，就需要通过 egress gateway 来进行 egress 传输，这部分内容在配置 Egress Gateway 中有详细描述。这里所谓的安全方式指的是防止恶意应用绕过 Istio 监控和策略管理进行未经授权的访问。

我们的场景中，该组织执行了上一节“开始之前”的步骤。这个步骤完成后，开放了对 edition.cnn.com 的访问，并且配置了响应的 Egress Gateway。现在可以对 edition.cnn.com 进行监控和策略进行配置了。

日志

首先配置一下对 *.cnn.com 的记录。创建一个 logentry 和两个 stdio 类型的 handler，其中一个用 error 级别的日志来记录受限的访问，另外一个用 info 级别来记录所有到 *.cnn.com 的访问。接下来创建 rules 把 logentry 定向到 handler 上。对 *.cnn.com/politics 的访问会被指派给受限访问的规则，剩余的访问则会被另一条规则接收。要理解 Istio 的 logentries、rules 以及 handlers，可以阅读 Istio Adaper Model 一文。下面的示意图中包含了刚才讲到的这些实体和依赖关系：

创建 logentries、rules 以及 handlers：

# egress 访问的日志条目
apiVersion: "config.istio.io/v1alpha2"
kind: logentry
metadata:
name: egress-access
namespace: istio-system
spec:
severity: '"info"'
timestamp: request.time
variables:
destination: request.host | "unknown"
path: request.path | "unknown"
source: source.labels["app"] | source.service | "unknown"
sourceNamespace: source.namespace | "unknown"
user: source.user | "unknown"
responseCode: response.code | 0
responseSize: response.size | 0
monitored_resource_type: '"UNSPECIFIED"'
---
# Handler for error egress access entries
apiVersion: "config.istio.io/v1alpha2"
kind: stdio
metadata:
name: egress-error-logger
namespace: istio-system
spec:
severity_levels:
info: 2 # 输出级别为 error
outputAsJson: true
---
# 访问 *.cnn.com/politics 的规则
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-politics
namespace: istio-system
spec:
match: request.host.endsWith("cnn.com") && request.path.startsWith("/politics")
actions:
- handler: egress-error-logger.stdio
instances:
- egress-access.logentry
---
# Info 级别的 Egress 日志
apiVersion: "config.istio.io/v1alpha2"
kind: stdio
metadata:
name: egress-access-logger
namespace: istio-system
spec:
severity_levels:
info: 0 # 输出为 Info 级别
outputAsJson: true
---
# 访问 *.cnn.com 的规则
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-cnn-access
namespace: istio-system
spec:
match: request.host.endsWith(".cnn.com")
actions:
- handler: egress-access-logger.stdio
instances:
- egress-access.logentry

分别向 edition.cnn.com/politics、edition.cnn.com/sport 发送请求，所有请求都应该返回 200 OK。

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
200
200
200

查询 Mixer 的日志，查看日志中出现的请求信息：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer-type=telemetry -o jsonpath='{.items[0].metadata.name}') mixer | grep egress-access | grep cnn | tail -4

返回如下信息：

{"level":"info","time":"2018-06-18T13:22:58.317448Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":200,"responseSize":150448,"source":"sleep","user":"unknown"}
{"level":"error","time":"2018-06-18T13:22:58.317448Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":200,"responseSize":150448,"source":"sleep","user":"unknown"}
{"level":"error","time":"2018-06-18T13:22:58.317448Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":200,"responseSize":150448,"source":"sleep","user":"unknown"}
{"level":"info","time":"2018-06-18T13:22:59.354943Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","responseCode":200,"responseSize":332218,"source":"sleep","user":"unknown"}

会看到关于三个请求的四条日志。三个 info 级别的条目是关于 edition.cnn.com 的，一条 error 级别的条目就是关于 edition.cnn.com/politics 的访问。服务网格的运维人员能看到所有的访问情况，并且也能通过对 error 日志的搜索来查找受限访问。这是在禁止访问之前的第一个监控措施，把所有受限访问都作为错误记录下来，在某些情况下，这就足够安全了。

利用路由进行访问控制

在启动对 edition.cnn.com 的访问日志之后，自动启动了一个访问策略，只允许访问 /health 和 /sport URL。这样简单的策略控制可以用 Istio 路由来实现。

重新定义 edition.cnn.com 的 VirtualService：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
  - mesh
  port: 80
route:
- destination:
    host: istio-egressgateway.istio-system.svc.cluster.local
    port:
      number: 443
  weight: 100
- match:
- gateways:
  - istio-egressgateway
  port: 443
  uri:
    regex: "^.health|^.sport"
route:
- destination:
    host: edition.cnn.com
    port:
      number: 443
  weight: 100

注意这里加入了一个针对 uri 的 match 条件，会检查 URL 路径是不是 /health 或者 /sport。另外还要注意的是，这个条件是加入到 VirtualService 的 istio-egressgateway 部分，egress gateway 是一个需要注意安全的组件（参见 Egress Gateway 的安全考量），应该慎重对待其安全性，防止影响后续的策略实施过程。

再次发送之前的三个 HTTP 请求：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200
200

会看到 edition.cnn.com/politics 返回了 404 Not Found，edition.cnn.com/sport 和 edition.cnn.com/health 都返回了 200。

VirtualService 的传播和生效可能需要几秒钟的等待。

查询 Mixer 日志，看看刚才发生的请求在日志中的体现：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer-type=telemetry -o jsonpath='{.items[0].metadata.name}') mixer | grep egress-access | grep cnn | tail -4

得到结果如下：

{"level":"info","time":"2018-06-19T12:39:48.050666Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":404,"responseSize":0,"source":"sleep","sourceNamespace":"default","user":"unknown"}
{"level":"error","time":"2018-06-19T12:39:48.050666Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":404,"responseSize":0,"source":"sleep","sourceNamespace":"default","user":"unknown"}
{"level":"info","time":"2018-06-19T12:39:48.091268Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","responseCode":200,"responseSize":334027,"source":"sleep","sourceNamespace":"default","user":"unknown"}
{"level":"info","time":"2018-06-19T12:39:48.063812Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/sport","responseCode":200,"responseSize":355267,"source":"sleep","sourceNamespace":"default","user":"unknown"}

这里还能看到 edition.cnn.com/politics 的访问日志，只不过这次的 responseCode 是 404。

使用 Istio 路由之后，我们成功的实现了初步的访问控制，但是如果是更复杂的需要，这种程度还是不够的。例如希望允许特定条件下对 edition.cnn.com/politics 的访问，这需要一些更复杂的策略，只判断 URL 是不够的。这就需要 Istio Mixer Adapter，（例如白名单和黑名单）的协助，来协助控制对 URL 路径的允许和禁止行为。借 [Policy Rules] 的帮助，这样就可以使用 Istio expression language 来实现复杂条件的定义，完成包含逻辑控制在内的复杂限制了。这些规则可以在日志和策略检查之间进行复用。另外还可以使用 Istio RBAC进行更复杂的控制。

还有一个额外的需要就是和远程访问策略系统进行集成。如果用例中设计的组织已经有使用一些认证和访问管理系统，可能会需要配置 Istio 从这些系统中获取访问策略方面的信息。可以通过实现 Istio Mixer Adapter 的方式来进行集成。

取消掉前面我们使用路由规则实现的访问控制，接下来使用 Mixer 策略来实现。

用之前的 Configure an Egress Gateway 中的版本替换 edition.cnn.com 的 VertualService：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
  - mesh
  port: 80
route:
- destination:
    host: istio-egressgateway.istio-system.svc.cluster.local
    port:
      number: 443
  weight: 100
- match:
- gateways:
  - istio-egressgateway
  port: 443
route:
- destination:
    host: edition.cnn.com
    port:
      number: 443
  weight: 100

再次发送之前的三个到 cnn.com 的请求，这里会看到三个 200 的成功返回：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
200
200
200

VirtualService 的传播和生效可能需要几秒钟的等待。

使用 Mixer 策略进行访问控制

这一步中，我们使用 Listchecker adapter，这是白名单的一个变体。用一个静态 URL 列表定义一个 listentry，然后在 listchecker 中用 overrides 字段进行检查。如果有外部的认证和访问管理系统，可以使用 providerurl 字段取而代之。下面图示显示了更新之后的对象关系。注意这里复用了同样的策略，handle-cnn-access 对日志和访问策略同样生效。

定义 path-checker 以及 request-path：

apiVersion: "config.istio.io/v1alpha2"
kind: listchecker
metadata:
name: path-checker
namespace: istio-system
spec:
overrides: ["/health", "/sport"]  # 提供一个静态列表
blacklist: false
---
apiVersion: "config.istio.io/v1alpha2"
kind: listentry
metadata:
name: request-path
namespace: istio-system
spec:
value: request.path

修改 handle-cnn-access 规则，要求将 request-path 发送给 path-checker：

# 访问 cnn.com egress 的规则
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-cnn-access
namespace: istio-system
spec:
match: request.host.endsWith(".cnn.com")
actions:
- handler: egress-access-logger.stdio
instances:
  - egress-access.logentry
- handler: path-checker.listchecker
instances:
  - request-path.listentry

再次执行 curl 指令，发现 edition.cnn.com/politics 返回了 404：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200
200

使用 Mixer 策略进行访问控制（续）

在前面我们配置了日志和访问控制之后，新增一个需要就是允许在 policics 命名空间内的应用能够访问 cnn.com 的所有内容，并且不受监控。接下来我们在 Istio 中进行配置，完成这一要求。

创建 polictics 命名空间

$ kubectl create namespace politics
namespace "politics" created

在 polictics 命名空间中启动 sleep。

如果使用了自动注入 Sidecar，执行：$ kubectl apply -n politics -f samples/sleep/sleep.yaml，否则，就需要进行注入了：kubectl apply -n politics -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)。

预备使用 policics 命名空间中的 sleep pod 来发送请求，这里定义一个环境变量来保存 Pod 名称。
```
export SOURCE_POD_IN_POLITICS=$(kubectl get pod -n politics -l app=sleep -o jsonpath={.items..metadata.name})
```

这次从新的 Pod（$SOURCE_POD_IN_POLITICS）中发送刚才的请求。因为我们还没有给新的命名空间中的应用设置例外，edition.cnn.com/politics 还是返回了 404。

$ kubectl exec -it $SOURCE_POD_IN_POLITICS -n politics -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200
200

查询 Mixer 日志，会看到来自 politics 命名空间的访问记录：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer-type=telemetry -o jsonpath='{.items[0].metadata.name}') mixer | grep egress-access | grep cnn | tail -4

查询结果：

{"level":"info","time":"2018-06-19T17:37:14.639102Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":404,"responseSize":76,"source":"sleep","sourceNamespace":"politics","user":"unknown"}
{"level":"error","time":"2018-06-19T17:37:14.639102Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":404,"responseSize":76,"source":"sleep","sourceNamespace":"politics","user":"unknown"}
{"level":"info","time":"2018-06-19T17:37:14.653225Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/sport","responseCode":200,"responseSize":356349,"source":"sleep","sourceNamespace":"politics","user":"unknown"}
{"level":"info","time":"2018-06-19T17:37:14.767923Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","responseCode":200,"responseSize":334027,"source":"sleep","sourceNamespace":"politics","user":"unknown"}

上面的输出中可以看到 sourceNamespace 的值为 politics。

重新定义 handle-cnn-access 以及 handle-politics 策略，为新的命名空间定义例外的日志和访问策略。

apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-politics
namespace: istio-system
spec:
match: request.host.endsWith("cnn.com") && request.path.startsWith("/politics") && source.namespace != "politics"
actions:
- handler: egress-error-logger.stdio
instances:
- egress-access.logentry
---
# 访问 egress cnn.com 的规则
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-cnn-access
namespace: istio-system
spec:
match: request.host.endsWith(".cnn.com") && source.namespace != "politics"
actions:
- handler: egress-access-logger.stdio
instances:
  - egress-access.logentry
- handler: path-checker.listchecker
instances:
  - request-path.listentry

在 $SOURCE_POD 中重复执行测试：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200

$SOURCE_POD 是在 default 命名空间的，所以对 edition.cnn.com/politics 的访问会被拒绝。

在 $SOURCE_POD_IN_POLITICS 中重复执行测试：

$ kubectl exec -it $SOURCE_POD_IN_POLITICS -n politics -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
200
200
200

现在所有访问都可以通过了。

查看 Mixer 日志，会发现看不到 sourceNamespace 为 politics 的条目了：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer-type=telemetry -o jsonpath='{.items[0].metadata.name}') mixer | grep egress-access | grep cnn

Dashboard

让运维人员能够可视化的进行 egress 流量监控，也能增强安全性。

浏览使用 Grafana 进行指标可视化任务，完成其中的步骤 1-3。

从 $SOURCE_POD 发送到 cnn.com 的请求：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200
200

因为 $SOURCE_POD 是存在于 default 命名空间中的，所以对 edition.cnn.com/politics 的访问会被拒绝。

从 $SOURCE_POD_IN_POLITICS 发送到 cnn.com 的请求：

$ kubectl exec -it $SOURCE_POD_IN_POLITICS -n politics -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
200
200
200

滚动 Dashboard 到 HTTP 服务部分的 istio-egressgateway.istio-system.svc.cluster.local 一节。会看到大致如下的显示：

在左侧 Requests by Source, Version and Response Code 中，会看到 default 命名空间中的 unknown 版本的 sleep 应用收到的 404 返回码。运维人员可以据此发现试图访问受控目标的应用。还可以看到在 polictics 命名空间中 sleep 应用收到的 200 返回码，这样也就知道了对受控外部资源的有效访问情况。

和 HTTPS egress 控制的比较

这个用例中，应用使用的是 HTTP 和 Istio Egress Gateway 结合提供 TLS 的。换个方式，应用可以自行发送 TLS 请求给 edition.cnn.com，本节中我们会对两种方式的优劣进行一些比较。

HTTP 方式中，请求在本地是明文传输，经由 Sidecar 转发给 Egress Gateway 的。如果 Istio 使用双向 TLS 部署，Sidecar 代理和 Egress Gateway 之间的通信就是加密的。Egress Gateway 解密信息，查看 URL 路径，HTTP 方法和 Header，上报监控数据、执行前置检查。如果请求没有被拒绝，Egress Gateway 就会为外部目标执行 TLS 封装，这样请求就会被再次加密，以密文形式发送给外部目标。下图演示了这种方式中的网络流向。图中 Gateway 方块中的 HTTP 标志，代表报文在 Gateway 解密之后变成明文的阶段。

这种方式的缺陷在于，请求在本机是明文传输的，可能会违反某些组织的安全需要。有些 SDK 的外部服务 URL 包含协议部分都是硬编码的，因此发送 HTTP 请求是不可能的。这种办法的好处是可以获取 HTTP 头、方法以及 URL 路径，并可以据此制定规则。

在 HTTPS 形式下，从应用到外部目标的请求是端到端加密的。下图演示了这种方式的数据流。在 Gateway 中见到的报文，同样还是 HTTPS。

端到端的 HTTPS 可能是更好的一种加密方式。然而因为流量是加密通过 Istio 代理和 Egress Gateway 的，因此只能看到源和目的的 IP 以及 SNI。在 Istio 开通双向 TLS 的情况下，源身份也是可知的。Gateway 无法获知 HTTP 头、方法以及 URL 路径，因此基于 HTTP 信息的策略就无法实现了。我们的用例中要求可以访问 edition.cnn.com。如果 Istio 中启用了双向 TLS，组织可以设置部分应用允许访问 edition.cnn.com。然而却无法允许或禁止访问特定的 URL。对 /politics 的允许或者禁止，在这种上下文中都是无法实现的。

我们认为，这样讲解之后，用户就可以对这两种方法进行优劣势的评估，进而做出合适的选择。

结论

本文中我们展示了 Istio 用 HTTP 访问 Egress 时的监控和策略。其中的监控过程，可以配置日志适配器结合 Istio Dashboard 来完成。而访问策略可以通过配置 VirtualService 或者配置多种策略适配器来完成。我们演示了一个简单的策略，只允许某些 URL 的访问。我们另外还展示了稍微复杂一些的策略，通过放行指定命名空间中的指定应用，来做出例外。最后，我们比较了两种 HTTPS 过程的优劣，同时也就有不同的控制能力。

清理

执行配置 Egress Gateway 任务中的清理任务。

删除日志和策略配置：

kubectl delete logentry egress-access -n istio-system
kubectl delete stdio egress-error-logger -n istio-system
kubectl delete stdio egress-access-logger -n istio-system
kubectl delete rule handle-politics -n istio-system
kubectl delete rule handle-cnn-access -n istio-system
kubectl delete -n istio-system listchecker path-checker
kubectl delete -n istio-system listentry request-path

删除 politics 命名空间
执行使用 Grafana 进行指标可视化任务中的清理环节。

egress | 伪架构师

Istio 大入门——Egress Gateway

原理

开始之前

创建 Gateway 和 DestinationRule

建立 Gateway

为服务 `istio-egressgateway` 创建一个目标规则

创建 VirtualService

加入策略限制

Denier

频率限制

源码

sleep.yaml

Istio 小入门 —— ServiceEntry 的对外通信

开始之前

创建 `ServiceEntry`

发起外部访问

服务质量监控

设置超时限制

仅允许指定源头访问

To be continued

相关链接

部分源码

sleep.yaml

HTTP Egress 流量的监控和访问策略管理

用例

相关任务

开始之前

配置监控和访问策略

日志

利用路由进行访问控制

使用 Mixer 策略进行访问控制

使用 Mixer 策略进行访问控制（续）

Dashboard

和 HTTPS egress 控制的比较

结论

清理

egress | 伪架构师

Istio 大入门——Egress Gateway

原理

开始之前

创建 Gateway 和 DestinationRule

建立 Gateway

为服务 istio-egressgateway 创建一个目标规则

创建 VirtualService

加入策略限制

Denier

频率限制

源码

sleep.yaml

Istio 小入门 —— ServiceEntry 的对外通信

开始之前

创建 ServiceEntry

发起外部访问

服务质量监控

设置超时限制

仅允许指定源头访问

To be continued

相关链接

部分源码

sleep.yaml

HTTP Egress 流量的监控和访问策略管理

用例

相关任务

开始之前

配置监控和访问策略

日志

利用路由进行访问控制

使用 Mixer 策略进行访问控制

使用 Mixer 策略进行访问控制（续）

Dashboard

和 HTTPS egress 控制的比较

结论

清理

为服务 `istio-egressgateway` 创建一个目标规则

创建 `ServiceEntry`