Service Mesh · Istio · 以实践入门

所有namespace里的容器出流量(egress)只能访问自己的namespace或namespace=istio-system 中提供的 services 。

egress

我们先测试一下外网连通性， Sidecar 的出流量被称作 egress 流量。

恢复：这时，我们将需要访问的域名注册到 ServiceEntry 中，并且增加一个 Sidecar 的 egress 规则，例如：

ingress

egress 配置覆盖的域名访问规则没必要在 ingress 中重复，所以 ingress 配置主要用于配置代理流量的规则。例如，我们可以将所有的入口流量传入 sidecar 中的监听进程（做一些定制开发的权限检查等），然后再传给下游微服务。

egress 的配置更多的是关注在服务网格对外访问的能力，服务内部如果限制了，应用自身访问都会需要大量的 ServiceEntry 注册，所以微服务之间东西流量的信任访问，需要靠安全机制来解决。

概述

图片来源于Istio官网

Istio 提供包含了南北流量和东西流量两部分的防御机制：

1、Security by default：微服务应用不需要提供任何代码或引入三方库来保证自身安全。

2、Defense in depth：能够与已有的安全体系融合，深度定制安全能力。

3、Zero-trust Network：提供安全的方案都是假定服务网格的内部和外部都是0信任（不安全）网络。

下图是 Istio 中每个组件的角色：

图片来源于Istio官网

1、Citadel，证书（CA）管理

2、Sidecar等Envoy Proxy，提供TLS保障

3、Pilot，策略（Policy）和身份信息下发

4、Mixer，认证和审计

策略（Policy）

Istio 支持在运行时实时地配置策略（Policy），支持：

1、服务入流量速率控制。

2、服务访问控制，黑白名单规则等。

3、Header重写，重定向。

也可以自己定制 Policy Adapter 来定义业务逻辑。

TLS

在介绍安全机制之前，有必要先科普一下 TLS 。

SSL ( Security Socket Layer ，安全 Socket 层），是一个解决 4 层 TCP 和 7 层HTTPS 中间的协议层，解决安全传输的问题。

TLS ( Transport Layer Security ，传输层安全协议)，是基于 SSL v3 的后续升级版本，可以理解为相当于 SSL v3.1 。

主要提供：

1、认证（Transport Authentication），用户、服务器的身份，确保数据发送到正确的目的地。

2、加密数据，防止数据明文泄露。

3、数据一致性，传输过程不被串改。

Istio 中的安全传输机制都是建立在 TLS 之上的。

更多信息可以查看官方概念，详情参考：

https://istio.io/docs/concepts/security

认证（Authentication）与鉴权（Authorization）

这两个词很相近，甚至缩写 auth 都是相同的，所以有时候很容混淆。

在 istioctl 中有两个命令 authn 和 authz ，这样就可以区分它们。

认证和鉴权分别做什么，在后文两节会具体介绍。这里先说一下它们的关系。

认证实际上是鉴权的必要条件

为什么？

1、认证是识别身份（Identification）。

2、鉴权是检查特定身份（Identity）的权限。

这样就很好理解了。二者时常相随，我们常说的比如登录，就是：

1、基于登录机制的cookie来识别访问来源的身份——认证。

2、然后判断来源的身份是否具备登录系统的权限（或者是访问某一个页面的具体细节的权限）——鉴权。

那么在 Istio 体系中，Authentication 是基于 mTLS 机制来做的，那么开启mTLS之后，就可以设置一些 AuthorizationPolicy 来做访问控制。细节可以看下文。

认证（Authentication）

Istio 中的认证包含两种：

1、Transport Authentication ，传输层认证。基于 mTLS ( Mutual TLS )，检查东西流量的合法性。

2、Origin Authentication ，客户端认证。基于 JWT 等校验南北流量的登录身份。

示例：配置Policy

这次我们跟着 Task: Authentication Policy 例子走，这里简化一下过程不做全程搬运，只分析关键点。

准备环境：

这个例子中，创建了 3 个 namespace ，其中两个 foo 和 bar 注入了Sidecar， legacy 不注入用于对比。

#!/bin/bash 
kubectl create ns foo
kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
kubectl create ns bar
kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n bar
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n bar
kubectl create ns legacy
kubectl apply -f samples/httpbin/httpbin.yaml -n legacy
kubectl apply -f samples/sleep/sleep.yaml -n legacy

默认情况下，容器之间是互通的（mTLS运行在PRESSIVE_MODE）。

这里通过一个 check.sh 脚本检查连通性：

#!/bin/bash
for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done$ ./check.sh
sleep.foo to httpbin.foo: 200
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 200
sleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200

打开TLS：

通过全局的 MeshPolicy 配置打开mTLS：

$ kubectl apply -f - <

 
    这时，原本互通的容器访问不通了 
    执行： 
    $ ./check.sh
sleep.foo to httpbin.foo: 503
sleep.foo to httpbin.bar: 503
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 503
sleep.bar to httpbin.bar: 503
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 000
command terminated with exit code 56
sleep.legacy to httpbin.legacy: 200
 
    Sidecar 注入的 namespace 中，会返回 503.  而没有注入的 ns 上，连接会直接被重置(connection reset)。 
    配置托管的 mTLS 能力 
    接着，通过 DestinationRule ，重新对注入Sidecar的微服务增加 mTLS 能力： 
    kubectl apply -f - <
 
    1、*.local 配置的含义是，对所有 K8s 集群内任意 namespace 之间的东西流量有效 
    2、tls.mode=ISTIO_MUTUAL ：查看文档，表示完全由 Istio 托管 mTLS 的实现，其它选项失效。具体配置后面再涉及。 
    重新运行 check.sh ： 
    $ ./check.sh
sleep.foo to httpbin.foo: 200
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 503
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 503
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 000
command terminated with exit code 56
sleep.legacy to httpbin.legacy: 200
 
    注意，如果走了前面的例子会有全局 default 的 Sidecar Egress 配置，限制了只能访问同 namespace 的服务，那么跨 namespace 的调用仍然会 503 ： 
    sleep.foo to httpbin.bar: 503
 
    可以自己试验一下，回顾一下配置： 
    apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: istio-system
spec:
  egress:
  - hosts:
    - ./*   # <--
    - istio-system/*
 
    分析 
    对比之前的结果，有两点变化： 
    1、同样注入Sidecar的微服务互相可以访问了（200）。 
    2、没有注入Sidecar（ns=legacy）的微服务不能被已注入Sidecar的微服务访问（503）。 
     
     ns=legacy中的行为仍然不变 
     
    变化1：说明微服务之间的 TLS 已经由 Istio 托管，这个期间我们没有修改任何服务的代码，很魔性。 
    变化2：说明服务网格对外部容器也要求具备 TLS 能力，因为 legacy 中的服务没有注入 Sidecar ，因此访问失败。 
    鉴权（Authorization） 
    Istio 的鉴权机制的前提就是打开 mTLS 认证，让每一个或特定的微服务的 sidecar 互相访问都基于 mTLS 机制。 
     
     不是必要前提 
     有一部分鉴权规则是不依赖mTLS的，但是很少。 
     
    鉴权基于 istio CRD ：AuthorizationPolicy 
    例如，默认拒绝所有微服务互相访问： 
    apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: deny-all
 namespace: foo
spec:
 
    需要留意的是，如果默认全部拒绝，那么甚至 istio-system 中的 istio-ingressgateway 流量访问 foo 这个namespace的服务也都会被拒绝。就无法从外部访问所有 foo 的服务了。所以我们可以改为： 
    apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: foo
spec:
  rules:
  - from:
    - source:
        namespaces:
        - "istio-system"
 
    AuthorizationPolicy 的规则文档里都已经很详细了，这里就不再赘述。 
    应用配置之后，在任意一个微服务中访问另外一个微服务，就都会遇到 403 错误，消息为 RBAC access denied 。 
    其它 
     
    Istio 能力本文仅覆盖了流量控制（Traffic Management）、安全机制（Security）中比较浅显的部分，有关高级的 Policy 设置（限流、路由的干预等）、服务观测（Telemetry）等能力没有涉及。 
    此外，如何地高效运维管理（比如升级 istio 版本、管理不同集群的配置等），0 信任基础下的安全访问策略配置，基于istio做二次开发扩展，等等问题都是在生产实践当中需要关注的点，以后有机会再分享整理。 
    参考文档 
     
     Istio官方文档
https://istio.io/docs/ 
     Istio Handbook
https://www.servicemesher.com/istio-handbook/concepts-and-principle/what-is-service-mesh.html 
     Pattern Service Mesh
https://philcalcado.com/2017/08/03/pattern_service_mesh.html

Service Mesh · Istio · 以实践入门

概念

服务网格

历史

Istio 和 Envoy

Sidecar注入

小结

实践

准备工作

安装Istio

示例：Hello World

注入

分析

深入探索

流量控制 - 切流

Gateway

VirtualService

DestinationRule

示例：Bookinfo

注入

部署

流量控制 - 网络可见性

Sidecar

egress

ingress

概述

策略（Policy）

TLS

认证（Authentication）与鉴权（Authorization）

认证（Authentication）

示例：配置Policy

准备环境：

打开TLS：

配置托管的 mTLS 能力

分析

鉴权（Authorization）

其它

参考文档

你可能感兴趣的:(Service Mesh · Istio · 以实践入门)