安全是一个非常重要的话题，但也是平时容易被忽略的一个话题，我们在开发应用的时候，往往会忽略安全，但是当应用上线后，安全问题就会暴露出来，这时候就会造成很大的损失。Istio 通过在服务之间注入 Sidecar 代理，来实现对服务之间的流量进行控制和监控，从而实现服务之间的安全通信。
接下来我们将从证书管理、认证、授权等几个方面来学习 Istio 的安全机制。
将单一应用程序拆分为微服务可提供各种好处，包括更好的灵活性、可伸缩性以及服务复用的能力。但是，微服务也有特殊的安全需求：
Istio 尝试提供全面的安全解决方案来解决所有这些问题，Istio 安全性可以减轻针对你的数据、端点、通信和平台的内外威胁。
安全概述
Istio 为微服务提供了无侵入，可插拔的安全框架。应用不需要修改代码，就可以利用 Istio 提供的双向 TLS 认证实现服务身份认证，并基于服务身份信息提供细粒度的访问控制。Istio 安全的高层架构如下图所示：
安全架构
上图展示了 Istio 中的服务认证和授权两部分。服务认证是通过控制面和数据面一起实现的：
Istio 的授权功能为网格中的工作负载提供网格、命名空间和工作负载级别的访问控制，这种控制层级提供了许多优点：
AuthorizationPolicy CRD。DENY 和 ALLOW 动作。授权策略对服务器端 Envoy 代理的入站流量实施访问控制。每个 Envoy 代理都运行一个授权引擎，该引擎在运行时授权请求。当请求到达代理时，授权引擎根据当前授权策略评估请求上下文，并返回授权结果 ALLOW 或 DENY。运维人员可以通过 YAML 资源清单文件来指定 Istio 授权策略。
授权策略
默认情况下，Istio CA 生成自签名根证书和密钥，并使用它们来签署工作负载证书。为了保护根 CA 密钥，我们应该使用在安全机器上离线运行的根 CA（比如使用 Hashicorp Vault 进行管理），并使用根 CA 向每个集群中运行的 Istio CA 颁发中间证书。Istio CA 可以使用管理员指定的证书和密钥对工作负载证书进行签名，并将管理员指定的根证书作为信任根分发给工作负载。
CA
签发证书
当我们有了 Istio CA 根证书后就可以使用它来签发工作负载证书了，那么整个的证书签发流程又是怎样的呢？如下图所示：
证书签发流程
pilot-agent 发起一个 SDS (Secret Discovery Service) 请求（启动的时候），要求获取自己的证书和私钥。pilot-agent 生成私钥和 CSR 证书签名请求，向 Istiod 发送证书签发请求，请求中包含 CSR 和该 Pod 中服务的身份信息。pilot-agent。pilot-agent 将证书和私钥通过 SDS 接口返回给 Envoy。pilot-agent 还会监控工作负载证书的过期时间，上述过程会定期重复进行证书和密钥轮换。这个流程和我们自己用手动方式去进行证书签发是一样的，所以我们需要先了解下证书签发的流程。Istio CA 根证书就是一个证书颁发机构，平时如果要为我们自己的网站申请 HTTPS 证书我们也是去一些正规的 CA 机构进行申请，而这个申请的信息就是生成的 CSR 证书签名请求，然后我们将这个 CSR 和身份信息提交给 CA 机构，CA 机构根据这些信息为我们签发证书，然后我们就可以使用这个证书了，只是我们这里在不同的组件上来执行这些操作，整体流程是一样的。
身份认证
另外要通过服务证书来实现网格中服务的身份认证，必须首先确保服务从控制面获取自身证书的流程是安全的。Istio 通过 Istiod 和 pilog-agent 之间的 gRPC 通道传递 CSR 和证书，因此在这两个组件进行通信时，双方需要先验证对方的身份，以避免恶意第三方伪造 CSR 请求或者假冒 Istiod CA 服务器。Istio 中主要包含下面两种认证方式：
Istiod 身份认证
istio-ca-root-cert 的 ConfigMap 对象， 在该 ConfigMap 中放入了 Istiod 的 CA 根证书。istio-proxy 容器中，被 pilot-agent 用于验证 Istiod 的服务器证书。pilot-agent 和 Istiod 建立 gRPC 连接时，pilot-agent 采用标准的 TLS 服务器认证流程对 Istiod 的服务器证书进行认证。pilot-agent 身份认证
pilot-agent 在向 Istiod 发送 CSR 时，将其所在 Pod 的 service account token 也随请求发送给 Istiod。这里需要注意的是不同版本的 Kubernetes 集群下面的 ServiceAccount Token 生成方式并不一样，但最终都是通过改 Token 来进行身份认证的。
Istio 提供两种类型的认证用于管控网格服务间的双向 TLS 和终端用户的身份认证。：
对等认证：用于服务到服务的认证，以验证建立连接的客户端。Istio 提供双向 TLS 作为传输认证的全栈解决方案，无需更改服务代码就可以启用它。这个解决方案：
请求认证：用于终端用户认证，以验证附加到请求的凭据。Istio 使用 JSON Web Token（JWT）验证启用请求级认证，并使用自定义认证实现或任何 OpenID Connect 的认证实现来简化的开发人员体验。
下面我们来创建几个示例服务来对认证配置进行测试。这里我们将在 foo 和 bar 命名空间下各自创建带有 Envoy 代理（Sidecar）的 httpbin 和 sleep 服务。还将在 legacy 命名空间下创建不带 Envoy 代理（Sidecar）的 httpbin 和 sleep 服务：
$ 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
现在可以在 foo、bar 或 legacy 三个命名空间下的任意 sleep Pod 中使用 curl 向 httpbin.foo、httpbin.bar 或 httpbin.legacy 发送 HTTP 请求来验证部署结果，所有请求都应该成功并返回 HTTP 200。
例如验证 sleep.bar 到 httpbin.foo 可达性如下：
$ kubectl exec "$(kubectl get pod -l app=sleep -n bar -o jsonpath={.items..metadata.name})" -c sleep -n bar -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
200
也可以使用一行指令检查所有可能的组合：
$ 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 -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
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
这样保证了我们的服务之间是可以互相访问的，接下来我们就来看下如何对服务进行认证。
默认情况下，在 Istio 网格内部的服务之间的所有流量都是通过双向 TLS 进行加密的，不需要做额外的操作，当使用双向 TLS 时，代理会将 X-Forwarded-Client-Cert 这个 Header 头注入到后端的上游请求，这个头信息的存在就是启用双向 TLS 的证据。例如：
$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl -s http://httpbin.foo:8000/headers -s
{
"headers": {
"Accept": "*/*",
"Host": "httpbin.foo:8000",
"User-Agent": "curl/7.81.0-DEV",
"X-B3-Parentspanid": "a59be7609a15c41f",
"X-B3-Sampled": "1",
"X-B3-Spanid": "034af52cfc2286b4",
"X-B3-Traceid": "eb07847c5c14c17fa59be7609a15c41f",
"X-Envoy-Attempt-Count": "1",
"X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=bb907e90c93bc3f1dd22763f952746e7d2b8c5ad7903ecbcc64324f3b5e55179;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"
}
}
可以看到上面我们的请求中包含了 X-Forwarded-Client-Cert 这个 Header 头，这就是启用双向 TLS 的证据，得到的这个值是一个 spiffe:// 开头的字符串，这个字符串就是 SPIFFE ID，这个 SPIFFE ID 就是用来表示服务的身份的，后面我们会详细介绍 SPIFFE。
零信任架构下，需要严格区分工作负载的识别和信任，而签发 X.509 证书是推荐的一种认证方式，在 Kubernetes 集群中，服务间是通过 DNS 名称互相访问的，而网络流量可能被 DNS 欺骗、BGP/路由劫持、ARP 欺骗等手段劫持，为了将服务名称（DNS 名称）与服务身份强关联起来，Istio 使用置于 X.509 证书中的安全命名（Secure naming）机制。
SPIFFE 是 Istio 所采用的安全命名的规范，它也是云原生定义的一种标准化的、可移植的工作负载身份规范。Secure Production Identity Framework For Everyone (SPIFFE) 是一套服务之间相互进行身份识别的标准，主要包含以下内容：
SPIFFE ID 规定了形如 spiffe://<trust domain>/<workload identifier> 的 URI 格式，作为工作负载（Workload）的唯一标识。Istio 使用形如 spiffe://<trust_domain>/ns/<namespace>/sa/<service_account> 格式的 SPIFFE ID 作为安全命名，注入到 X.509 证书的 subjectAltName 扩展中。其中的 trust domain 参数通过 Istiod 环境变量 TRUST_DOMAIN 注入，用于在多集群环境中交互，比如我们这里就是 cluster.local，所以其实最终在 Envoy 的配置中可以看到匹配证书的 subjectAltName 值也是这个格式：
{
"combined_validation_context": {
"default_validation_context": {
"match_subject_alt_names": [
{
"exact": "spiffe://cluster.local/ns/istio-system/sa/istiod"
}
]
},
"validation_context_sds_secret_config": {
"name": "ROOTCA",
"sds_config": {
"api_config_source": {
"api_type": "GRPC",
"grpc_services": [
{
"envoy_grpc": {
"cluster_name": "sds-grpc"
}
}
],
"set_node_on_first_message_only": true,
"transport_api_version": "V3"
},
"initial_fetch_timeout": "0s",
"resource_api_version": "V3"
}
}
}
}
当服务器没有 Sidecar 时，X-Forwarded-Client-Cert 这个 Header 头将不会存在，这意味着请求是明文的，比如我们请求 httpbin.legacy 服务：
kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.legacy:8000/headers -s | grep X-Forwarded-Client-Cert
全局严格 mTLS 模式
事实上当 Istio 自动将代理和工作负载之间的所有流量升级到双向 TLS 时，工作负载仍然可以接收明文流量，如果想要禁用非 mTLS 的通信流量，我们可以使用一个 PeerAuthentication 资源对象来进行配置，只需要将整个网格的对等认证策略设置为 STRICT 模式，作用域为整个网格范围的对等认证策略不设置 selector 即可，这种认证策略必须应用于根命名空间（istiod 所在的命名空间），例如：
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication # 对等认证策略
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICT # STRICT 模式表示只允许 mTLS
对等认证策略指定 Istio 对目标工作负载实施的双向 TLS 模式。支持以下模式：
PERMISSIVE：工作负载接受双向 TLS 和纯文本流量，也就是所谓的宽容模式。此模式在迁移因为没有 Sidecar 而无法使用双向 TLS 的工作负载的过程中非常有用。一旦工作负载完成 Sidecar 注入的迁移，应将模式切换为 STRICT。STRICT：工作负载仅接收双向 TLS 流量。DISABLE：禁用双向 TLS。从安全角度来看，除非提供自己的安全解决方案，否则请勿使用此模式。这个对等认证策略将工作负载配置为仅接受 mTLS 加密的请求。由于未对 selector 字段指定值，因此该策略适用于网格中的所有工作负载。
直接应用上面这个对等认证策略后，我们再次发送请求来进行测试：
$ 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 -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
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: 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
我们可以发现从 sleep.legacy 到 httpbin.foo 和 httpbin.bar 的请求都失败了，其他依然是成功的，这是因为我们现在配置了 STRICT 严格要求使用 mTLS，由于 sleep.legacy 没有 Envoy Sidecar，所以无法满足这一要求，所以要访问网格内部的工作负载是不被允许的。那为什么可以访问 httpbin.legacy 呢？这是因为我们在 legacy 命名空间下的 httpbin 服务没有 Envoy Sidecar，所以它不会被 Istio 管理，也就不会被强制要求使用 mTLS 了，所以我们可以直接访问它。
命名空间级别策略
上面我们是在根命名空间（istiod 所在的命名空间）下配置的对等认证策略，这样会影响到整个网格，如果我们只想对某个命名空间下的服务进行配置，那么我们可以使用命名空间级别的对等认证策略，该策略的规范与整个网格级别的规范相同，但是可以在 metadata 字段指定具体的命名空间的名称。比如我们要在 foo 命名空间上启用严格的双向 TLS 对等策略，可以创建如下所示的资源对象：
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: foo # 命名空间级别
spec:
mtls:
mode: STRICT
直接应用上面的资源对象，然后再次发送请求来进行测试：
# 首先删除上面创建的全局对等认证策略
$ kubectl delete peerauthentication -n istio-system default
$ 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
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: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200
由于这些策略只应用于命名空间 foo 中的服务，正常我们会看到只有从没有 Sidecar 的客户端（sleep.legacy）到有 Sidecar 的客户端（httpbin.foo）的请求会失败，其余都是成功的。
为每个工作负载启用双向 TLS
要为特定工作负载设置对等认证策略，我们就必须配置 selector 字段指定与所需工作负载匹配的标签。比如我们只想要为 httpbin.bar 服务启用严格模式的 mTLS，则可以创建如下所示的资源对象：
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: "httpbin"
namespace: "bar"
spec:
selector:
matchLabels:
app: httpbin # 匹配 httpbin 应用的标签
mtls:
mode: STRICT
上面的资源对象将为 bar 命名空间中的 httpbin 应用启用严格模式的 mTLS，其他工作负载不受影响。直接应用上面的资源对象，然后再次发送请求来进行测试：
$ 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
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: 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
跟预期一样，从 sleep.legacy 到 httpbin.bar 的请求因为同样的原因失败。
除此之外我们还可以为每个端口配置不同的对等认证策略，例如，以下对等认证策略要求在除 80 端口以外的所有端口上都使用双向 TLS：
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: "httpbin"
namespace: "bar"
spec:
selector:
matchLabels:
app: httpbin
mtls:
mode: STRICT
portLevelMtls:
80:
mode: DISABLE
上面的资源对象中我们配置了一个 portLevelMtls 字段，该字段用于配置端口级别的对等认证策略，这里我们配置了 80 端口的对等认证策略为 DISABLE，即禁用双向 TLS，其他端口的对等认证策略为 STRICT，即启用双向 TLS，也就是说我们只允许 httpbin 应用的 80 端口接收明文流量，其他端口都必须使用双向 TLS。直接应用上面的资源对象，然后再次发送请求来进行测试：
$ 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
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: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200
可以看到现在我们从 sleep.legacy 到 httpbin.bar 的请求成功了，因为我们禁用了 80 端口的双向 TLS，所以 sleep.legacy 可以访问到 httpbin.bar 的服务了。
测试完成后记得删除上面创建的对等认证策略：
$ kubectl delete peerauthentication default -n foo
$ kubectl delete peerauthentication httpbin -n bar
Istio 的请求认证用于终端用户认证，以验证附加到请求的凭据。Istio 使用 JWT 验证启用请求级认证，并使用自定义认证实现或任何 OpenID Connect 的认证实现来进行认证简化。
要在 Istio 中进行请求认证，可以通过一个 RequestAuthentication 资源对象来进行配置，如果请求包含无效的认证信息，它将根据配置的认证规则拒绝该请求。不包含任何认证凭证的请求将被接受，但不会有任何认证的身份。
JWK 与 JWKS 概述
Istio 使用 JWT 对终端用户进行身份验证，Istio 要求提供 JWKS 格式的信息，用于 JWT 签名验证。因此这里得先介绍一下 JWK 和 JWKS。
JWK 即 JSON Web Key，是 JWT 的秘钥，它描述了一个加密密钥（公钥或私钥）的值及其各项属性。JWKS 描述一组 JWK 密钥，JWKS 的 JSON 文件格式如下:
{
"keys": [
<jwk-1>,
<jwk-2>,
...
]}
Istio 使用 JWK 描述验证 JWT 签名所需要的信息。在使用 RSA 签名算法时，JWK 描述的应该是用于验证的 RSA 公钥。一个 RSA 公钥的 JWK 描述如下：
{
"alg": "RS256", # 算法「可选参数」
"kty": "RSA", # 密钥类型
"use": "sig", # 被用于签名「可选参数」
"kid": "DHFxxxxx_-envvQ", # key 的唯一 id
"n": "xAExxxxMQ", 公钥的指数(exponent)
"e": "AQAB" # 公钥的模数(modulus)
}
那么需要如何生成 JWK 呢？我们可以使用 https://github.com/lestrrat-go/jwx 这个命令行工具，这是一个用 Go 语言开发的命令行工具，内置了对各种 JWx(JWT, JWK, JWA, JWS, JWE) 的支持。
我们可以使用下面的命令来安装 jwx 命令行工具:
$ export GOPROXY="https://goproxy.io"
$ git clone https://github.com/lestrrat-go/jwx.git
$ cd jwx
$ make jwx
go: downloading github.com/lestrrat-go/jwx/v2 v2.0.11
go: downloading github.com/urfave/cli/v2 v2.24.4
# ......
go: downloading github.com/russross/blackfriday/v2 v2.1.0
go: downloading golang.org/x/sys v0.8.0
Installed jwx in /root/go/bin/jwx
下面我们使用 jwx 命令行工具生成一个 JWK，通过模板指定 kid 为 youdianzhishi-key:
$ jwx jwk generate --keysize 4096 --type RSA --template '{"kid":"youdianzhishi-key"}' -o rsa.jwk
$ cat rsa.jwk
{
"d": "AxxxwBw6Jok",
"dp": "j3xxxuvQ",
"dq": "zzxxxqQ",
"e": "AQAB",
"kid": "youdianzhishi-key",
"kty": "RSA",
"n": "5sxxxwV8",
"p": "-yxxxQ",
"q": "6zkC_xxxxKw",
"qi": "LExxxTw"
}
然后从 rsa.jwk 中提取 JWK 公钥:
$ jwx jwk fmt --public-key -o rsa-public.jwk rsa.jwk
$ cat rsa-public.jwk
{
"e": "AQAB",
"kid": "youdianzhishi-key",
"kty": "RSA",
"n": "5sxxxV8"
}
上面生成的 JWK 其实就是 RSA 公钥私钥换了一种存储格式而已，我们可以使用下面的命令将它们转换成 PEM 格式的公钥和私钥:
$ jwx jwk fmt -I json -O pem rsa.jwk
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQCym3O0Ik5QGZ8i
......
-----END PRIVATE KEY-----
$ jwx jwk fmt -I json -O pem rsa-public.jwk
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAsptztCJOUBmfIqSE8LR5
......
-----END PUBLIC KEY-----
接下来我们就可以使用 jwx 命令行签发 JWT Token 并验证其有效性了：
jwx jws sign --key rsa.jwk --alg RS256 --header '{"typ":"JWT"}' -o token.txt - <<EOF
{
"iss": "testing@secure.istio.io",
"sub": "cnych001",
"iat": 1700648397,
"exp": 1700656042,
"name": "Yang Ming"
}
EOF
然后查看生成的 Token 文件内容：
$ cat token.txt
eyJhbGciOiJSUzI1NiIsImtpZCI6InlvdWRpYW56aGlzaGkta2V5In0......
上面生成 JWT Token 实际上是由下面的算法生成的:
base64url_encode(Header) + '.' + base64url_encode(Claims) + '.' + base64url_encode(Signature)
我们可以将该 Token 粘贴到 jwt.io 网站上来解析：
jwt
先看一下 Headers 部分，包含了一些元数据:
alg: 所使用的签名算法，这里是 RSA256kid: JWK 的 kid然后是 Payload(Claims) 部分，payload 包含了这个 token 的数据信息，JWT 标准规定了一些字段，另外还可以加入一些承载额外信息的字段。
iss: issuer，token 是谁签发的sub: token 的主体信息，一般设置为 token 代表用户身份的唯一 id 或唯一用户名exp: token 过期时间，Unix 时间戳格式iat: token 创建时间， Unix 时间戳格式最后看一下签名 Signature 信息，签名是基于 JSON Web Signature (JWS) 标准来生成的，签名主要用于验证 token 是否有效，是否被篡改。签名支持很多种算法，这里使用的是 RSASHA256，具体的签名算法如下:
RSASHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
<rsa-public-key>,
<rsa-private-key>
最后可以使用 RSA Public Key 验证 JWT Token 的有效性:
$ jwx jws verify --alg RS256 --key rsa-public.jwk token.txt
{
"iss": "testing@secure.istio.io",
"sub": "cnych001",
"iat": 1700648397,
"exp": 1700656042,
"name": "Yang Ming"
}
配置 JWT 终端用户认证
上面我们了解了 JWT、JWK、JWKS 这些概念，接下来我们来配置 Istio 的认证策略使用我们自己创建的 JWKS。
为了方便访问，我们这里通过 Ingress 网关来暴露 httpbin.foo 服务，为其创建一个 Gateway 对象：
kubectl apply -f samples/httpbin/httpbin-gateway.yaml -n foo
可以通过如下命令获取 HTTP 的访问端口：
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
然后获取集群中任意一个节点的 IP 地址：
export INGRESS_HOST=$(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].status.hostIP}')
然后可以通过下面的命令来测试 httpbin.foo 服务是否可以正常访问：
curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
如果上面命令返回 200，则表示 httpbin.foo 服务可以正常访问。
接下来我们就可以添加一个请求认证策略对象，该策略要求 Ingress 网关指定终端用户的 JWT。
apiVersion: "security.istio.io/v1"
kind: RequestAuthentication
metadata:
name: jwt-example
namespace: istio-system
spec:
selector:
matchLabels:
istio: ingressgateway
jwtRules:
- issuer: "testing@secure.istio.io" # 签发者，需要和 JWT payload 中的 iss 属性完全一致。
# forwardOriginalToken: true
jwks: |
{
"keys": [
{
"e": "AQAB",
"kid": "youdianzhishi-key",
"kty": "RSA",
"n": "5sbkUCkQDuM3hiw9UTxmxO2wUYOT69IZje7M6O_R-ApJ3KkrhQS1C2SJelBTLgbaWhAsO4jBYOmFfWGLBA-XxrhoB9KxWCGA4EXf6fukp0ljGTYE6Th6r393jIJGDFUt8vQCjj5ivmBAQHLjwmnWiG6I93mrTQhoNHQWAde21O7yYNpg6fvjVJgRFqeAtpieA-5f2sQ8fBkefM0RFgQTqWPGfLHse5nqRWY4hG_gb23GzCo_Ti2h9wJZNuTfdK8hitahOq3eLlDVVvCu8hx-8BEs5APCj54gtqePswHeRXZi_03ccNii5CnW7Y1rHiL8LHKNHhY5tD2iZByh4YrnhkUWD-CXNqyUKx90de0R9H1ON6pqsmdEx4iAMx2xvnZ0S9NbKlk3glw_AvudjJUHa41xx7qy9OZ7QV6cB_ntwLtw513lk5Tfm-RDlVgyU-EO2jKXbOeiDpnb8kgRNBMKDqY9mgLfISW54N-LBjyVwVVHOvICWo0oPJypRgPRWD8f25wHqzjlsB8nIqJkj_e9p2c5WnAGiZWuZjm6t94IfFq9lWYUsSn-JtJvh3ATsv7ptDKFz2Ko82r1uD3446mr4I0J56C-7WOHGchlSOrDWKErwkIGxyrQ_3GEkUhkSxfArAv0bajmcMCu1_j8Eekqk7Fnm5QqytCFmFevzIJkwV8"
}
]
}
在上面的资源对象中我们通过 selector 匹配了 istio-ingressgateway 服务，因为我们要为 Ingress 网关添加请求认证，具体的请求认证规则通过 jwtRules 来进行配置，这里我们配置了一个 issuer 字段，该字段用于指定 JWT 的 Issuer 发行人，然后配置了一个 jwks 字段，该字段用于指定 JWT 的公钥集数据，我们也可以通过 jwksUri 来指向一个公钥集地址。对同一个 issuers（jwt 签发者），可以设置多个公钥，以实现 JWT 签名密钥的轮转。JWT 的验证规则是：
payload 中有 issuer 属性，首先通过 issuer 匹配到对应的 istio 中配置的 jwks。header 中有 kid 属性，第二步在 jwks 的公钥列表中，中找到 kid 相同的公钥。配置中的 spec.selector 可以省略，这样会直接在整个命名空间中生效，比如在 istio-system 命名空间，该配置将在全集群的所有 sidecar/ingressgateway 上生效！
默认情况下，Istio 在完成了身份验证之后，会去掉 Authorization 请求头再进行转发。这将导致我们的后端服务获取不到对应的 Payload，无法判断终端用户的身份。因此我们需要启用 Istio 的 Authorization 请求头的转发功能，只需要在上面的资源对象中添加一个 forwardOriginalToken: true 字段即可。
直接应用上面的资源对象，然后再次发送请求来进行测试：
$ curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200
可以看到现在依然可以正常访问，但是如果我们请求的时候带上一个无效的 JWT Token，则会返回 401 错误：
$ curl --header "Authorization: Bearer abcdef" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
401
要想正常访问，我们需要使用上面生成的 JWT Token 来进行访问：
$ TOKEN=$(cat token.txt)
$ curl --header "Authorization: Bearer $TOKEN" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200
可以看到就可以正常访问了。
设置强制认证规则
从上面的测试可以看出 Istio 的 JWT 验证规则，默认情况下会直接忽略不带 Authorization 请求头（即 JWT）的流量，因此这类流量能直接进入网格内部。通常这是没问题的，因为没有 Authorization 的流量即使进入到内部，也会因为无法通过 payload 判别身份而被拒绝操作。但是如果我们需要禁止不带 JWT 的流量，那么可以通过一个 AuthorizationPolicy 对象来进行配置了。
比如拒绝任何 JWT 无效的请求，则可以创建如下 d 资源对象：
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: deny-requests-without-authorization
namespace: istio-system
spec:
selector:
matchLabels:
istio: ingressgateway
action: DENY # 拒绝
rules:
- from:
- source:
notRequestPrincipals: ["*"] # 不存在任何请求身份（Principal）的 requests
上面的资源对象中我们配置的 action: DENY 表示拒绝，然后通过 rules 字段来配置拒绝的规则，这里我们配置了一个 from 字段，该字段用于指定请求的来源，这里我们配置了一个 notRequestPrincipals 字段，该字段用于指定请求的身份，这里我们配置为 *，表示任何请求身份都不允许。
应用上面的资源对象后，重新发送没有令牌的请求，请求失败并返回错误码 403：
$ curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
403
如果仅希望强制要求对部分 path 的请求必须带有 Authorization Header，可以这样设置：
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-requests-without-authorization
namespace: istio-system
spec:
selector:
matchLabels:
istio: ingressgateway
action: DENY # 拒绝
rules:
- from:
- source:
notRequestPrincipals: ["*"] # 不存在任何请求身份的 requests
# 仅强制要求如下 host/path 相关的请求，必须带上 JWT token
to:
- operation:
hosts: ["another-host.com"]
paths: ["/headers"]
需要注意的是 RequestsAuthentication 和 AuthorizationPolicy 这两个对象返回的错误码是不同的：
RequestsAuthentication 验证失败的请求，Istio 会返回 401 状态码。AuthorizationPolicy 验证失败的请求，Istio 会返回 403 状态码。到这里我们就实现了对 JWT 的验证，当然除了验证之外，我们还需要授权，这个我们在下面的章节中来实现。
文章转载自k8s技术圈。
Linux基金会开源软件学园 Copyright © 2019-2024 linuxfoundation.cn, ICP license, no. 京ICP备17074266号-2
