实战名称 |
---|
实战:Egress TLS Origination-2023.11.19(failed) |
实战:通过 egress 网关发起双向 TLS 连接-2023.11.19(测试成功) |
接下来我们将学习如何通过配置 Istio 去实现对发往外部服务的流量的 TLS Origination(TLS 发起)。 若此时原始的流量为 HTTP,则 Istio 会将其转换为 HTTPS 连接。TLS Origination 的概念前面我们也已经介绍过了。
假设有一个传统应用正在使用 HTTP 和外部服务进行通信,如果有一天突然有一个新的需求,要求必须对所有外部的流量进行加密。此时,使用 Istio 便可通过修改配置实现此需求,而无需更改应用中的任何代码。该应用可以发送未加密的 HTTP 请求,由 Istio 为请求进行加密。
从应用源头发起未加密的 HTTP 请求,并让 Istio 执行 TLS 升级的另一个好处是可以产生更好的遥测并为未加密的请求提供更多的路由控制。
下面我们就来学习下如何配置 Istio 实现 TLS Origination。
实战:Egress TLS Origination-2023.11.19(failed)
实验环境:
k8s v1.27.6(containerd://1.6.20)(cni:flannel:v0.22.2)
istio v1.19.3(--set profile=demo)
应用程序在以下链接里:
链接:https://pan.baidu.com/s/1pMnJxgL63oTlGFlhrfnXsA?pwd=7yqb
提取码:7yqb
2023.11.5-实战:BookInfo 示例应用-2023.11.5(测试成功)
本次yaml内容直接在文档里拷贝就好。
准备测试客户端
kubectl apply -f samples/sleep/sleep.yaml
否则在部署 sleep 应用之前,必须手动注入 Sidecar:
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
echo $SOURCE_POD
配置对外部服务的访问
我们之前已经默认配置了.spec.meshConfig.outboundTrafficPolicy.mode
=REGISTRY_ONLY
了,因此开始创建如下 ServiceEntry
[root@master1 istio-1.19.3]#kubectl get istiooperator installed-state -n istio-system -o jsonpath='{.spec.meshConfig.outboundTrafficPolicy.mode}'
REGISTRY_ONLY
ServiceEntry
对象来配置对外部服务 edition.cnn.com
的访问。这里我们将使用单个 ServiceEntry
来启用对服务的 HTTP 和 HTTPS 访问。创建一个如下所示的 ServiceEntry
对象:#tls-ori.yaml
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: edition-cnn-com
spec:
hosts:
- edition.cnn.com
ports:
- number: 80
name: http-port
protocol: HTTP
- number: 443
name: https-port
protocol: HTTPS
resolution: DNS
上面的 ServiceEntry
对象中我们指定了 edition.cnn.com
服务的主机名,然后在 ports
中指定了需要暴露的端口及其属性,表示该 ServiceEntry
对象代表对 edition.cnn.com
的访问,这里我们定义了 80
和 443
两个端口,分别对应 http
和 https
服务,resolution: DNS
定义了如何解析指定的 hosts
,这里我们使用 DNS 来解析。
[root@master1 istio-1.19.3]#kubectl apply -f tls-ori.yaml
serviceentry.networking.istio.io/edition-cnn-com created
$ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
# 输出如下结果
HTTP/1.1 301 Moved Permanently
# ......
location: https://edition.cnn.com/politics
HTTP/2 200
content-type: text/html; charset=utf-8
# ......
上面我们在使用 curl
命令的时候添加了一个 -L
标志,该标志指示 curl
将遵循重定向。 在这种情况下,服务器将对到 http://edition.cnn.com/politics
的 HTTP 请求进行重定向响应,而重定向响应将指示客户端使用 HTTPS 向 https://edition.cnn.com/politics
重新发送请求,对于第二个请求,服务器则返回了请求的内容和 200 状态码。
尽管 curl
命令简明地处理了重定向,但是这里有两个问题。第一个问题是请求冗余,它使获取 http://edition.cnn.com/politics
内容的延迟加倍。第二个问题是 URL 中的路径(在本例中为 politics
)被以明文的形式发送。如果有人嗅探你的应用与 edition.cnn.com
之间的通信,他将会知晓该应用获取了此网站中哪些特定的内容。出于隐私的原因,我们可能希望阻止这些内容被嗅探到。通过配置 Istio 执行 TLS 发起,则可以解决这两个问题。
用于 egress 流量的 TLS 发起
edition.cnn.com
创建一个出口网关,端口为 80,接收 HTTP 流量,如下所示:---
#tls-ori.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: istio-egressgateway
spec:
selector:
istio: egressgateway
servers:
- port:
number: 80
name: tls-origination-port
protocol: HTTP
hosts:
- edition.cnn.com
istio-egressgateway
创建一个 DestinationRule
对象,如下所示:---
#tls-ori.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: egressgateway-for-cnn
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: cnn
VirtualService
对象,将流量从 Sidecar 引导至 Egress Gateway,再从 Egress Gateway 引导至外部服务,如下所示:---
#tls-ori.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-cnn-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway # Egress Gateway
- mesh # 网格内部的流量
http:
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: cnn
port:
number: 80
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 80
route:
- destination:
host: edition.cnn.com
port:
number: 443 # 443 端口
weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: originate-tls-for-edition-cnn-com
spec:
host: edition.cnn.com
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE # initiates HTTPS for connections to edition.cnn.com
需要注意的是上面最后针对 edition.cnn.com
的 DestinationRule
对象,在 trafficPolicy
中指定了 portLevelSettings
用于对不同的端口定义不同的流量策略,这里我们定义了 443
端口的 tls
模式为 SIMPLE
,表示当访问 edition.cnn.com
的 HTTP 请求时执行 TLS 发起。
http://edition.cnn.com/politics
发送 HTTP 请求:[root@master1 istio-1.19.3]#kubectl apply -f tls-ori.yaml
serviceentry.networking.istio.io/edition-cnn-com unchanged
destinationrule.networking.istio.io/egressgateway-for-cnn created
virtualservice.networking.istio.io/direct-cnn-through-egress-gateway created
destinationrule.networking.istio.io/originate-tls-for-edition-cnn-com created
$ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
# 直接输出200状态码
HTTP/1.1 200 OK
content-length: 2474958
content-type: text/html; charset=utf-8
# ......
这次将会收到唯一的 200 OK 响应,因为 Istio 为 curl 执行了 TLS 发起,原始的 HTTP 被升级为 HTTPS 并转发到 edition.cnn.com
。服务器直接返回内容而无需重定向,这消除了客户端与服务器之间的请求冗余,使网格保持加密状态,隐藏了你的应用获取 edition.cnn.com
中 politics
端点的信息。
⚠️ 注意:
自己测试后,这里一直报503
错误,服务不可用。
服务不可用(503)。
看下istio-egressgateway-556f6f58f4-7kcjc
日志:(无输出)
看下sleep-9454cc476-5v8hb
istio-proxy日志:
自己删除后续的用于 egress 流量的 TLS 发起部分,再次测试,还是可以正常访问目的网站的呀,但是一配置后,就不行了,老师的是可以的,奇怪。。。
先这样吧,搁置。。。
[root@master1 istio-1.19.3]#kubectl delete -f tls-ori.yaml
serviceentry.networking.istio.io "edition-cnn-com" deleted
destinationrule.networking.istio.io "egressgateway-for-cnn" deleted
virtualservice.networking.istio.io "direct-cnn-through-egress-gateway" deleted
destinationrule.networking.istio.io "originate-tls-for-edition-cnn-com" deleted
如果我们在代码中有去访问外部服务,那么我们就可以不用修改代码了,只需要通过配置 Istio 来获得 TLS 发起即可,而无需更改一行代码。
到这里我们就学习了如何通过配置 Istio 实现对外部服务的 TLS 发起。
TLS 与 mTLS 基本概念
前面我们学习了如何通过配置 Istio 实现对外部服务的 TLS 发起,这里其实还有一个 mTLS 的概念呢,由于 TLS 本身就比较复杂,对于双向 TLS(mTLS)就更复杂了。
CA:证书颁发机构
TLS 是一个连接层协议,旨在为 TCP 连接提供安全保障。TLS 在连接层工作,可以与任何使用 TCP 的应用层协议结合使用。例如,HTTPS 是 HTTP 与 TLS 的结合(HTTPS 中的 S 指的是 SSL,即 TLS 的前身),TLS 认证的流程大致如下所示:
Verisign
、Digicert
等,这些证书在发布时被打包在一起,当我们下载浏览器时,就经把正确的证书放进了浏览器,如果 CA 不被信任,则找不到对应 CA 的证书,证书也会被判定非法。当然 HTTPS 的工作流程和这个过程基本就一致了:
当然双向 TLS 就更为复杂了,Mutual TLS(双向 TLS),或称 mTLS,对于常规的 TLS,只需要服务端认证,mTLS 相对来说有一个额外的规定:客户端也要经过认证。在 mTLS 中,客户端和服务器都有一个证书,并且双方都使用它们的公钥/私钥对进行身份验证。
TLS 保证了真实性,但默认情况下,这只发生在一个方向上:客户端对服务器进行认证,但服务器并不对客户端进行认证。为什么 TLS 的默认只在一个方向进行认证?因为客户端的身份往往是不相关的。例如我们在访问优点知识的时候,你的浏览器已经验证了要访问的网站服务端的身份,但服务端并没有验证你的浏览器的身份,它实际上并不关心你的浏览器的身份,这对于互联网上的 Web 项目来说足够了。但是在某些情况下,服务器确实需要验证客户端的身份,例如,当客户端需要访问某些敏感数据时,服务器可能需要验证客户端的身份,以确保客户端有权访问这些数据,这就是 mTLS 的用武之地,mTLS 是保证微服务之间跨服务通信安全的好方法。
接下来我们就来测试下如何通过 egress 网关发起双向 TLS 连接。
实战:通过 egress 网关发起双向 TLS 连接-2023.11.19(测试成功)
实验环境:
k8s v1.27.6(containerd://1.6.20)(cni:flannel:v0.22.2)
istio v1.19.3(--set profile=demo)
应用程序在以下链接里:
链接:https://pan.baidu.com/s/1pMnJxgL63oTlGFlhrfnXsA?pwd=7yqb
提取码:7yqb
2023.11.5-实战:BookInfo 示例应用-2023.11.5(测试成功)
本次yaml内容均在文档里。
是有点绕哦……
openssl
命令生成客户端和服务器的证书与密钥,为你的服务签名证书创建根证书和私钥:openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt
# 生成 CA 证书和私钥
my-nginx.mesh-external.svc.cluster.local
创建证书和私钥:# 为 my-nginx.mesh-external.svc.cluster.local 创建私钥和证书签名请求
$ openssl req -out my-nginx.mesh-external.svc.cluster.local.csr -newkey rsa:2048 -nodes -keyout my-nginx.mesh-external.svc.cluster.local.key -subj "/CN=my-nginx.mesh-external.svc.cluster.local/O=some organization"
# 使用 CA 公钥和私钥以及证书签名请求为 my-nginx.mesh-external.svc.cluster.local 创建证书
$ openssl x509 -req -sha256 -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in my-nginx.mesh-external.svc.cluster.local.csr -out my-nginx.mesh-external.svc.cluster.local.crt
# 为 client.example.com 创建私钥和证书签名请求
$ openssl req -out client.example.com.csr -newkey rsa:2048 -nodes -keyout client.example.com.key -subj "/CN=client.example.com/O=client organization"
# 使用相同的 CA 公钥和私钥以及证书签名请求为 client.example.com 创建证书
$ openssl x509 -req -sha256 -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 1 -in client.example.com.csr -out client.example.com.crt
接着我们来部署一个双向 TLS 服务器,为了模拟一个真实的支持双向 TLS 协议的外部服务,我们在 Kubernetes 集群中部署一个 NGINX 服务,该服务运行在 Istio 服务网格之外,比如运行在一个没有开启 Istio Sidecar proxy 注入的命名空间中。
nginx里默认是支持双向认证的。
mesh-external
表示 Istio 网格之外的服务,注意在这个命名空间中,Sidecar 自动注入是没有开启的,不会在 Pod 中自动注入 Sidecar proxy。kubectl create namespace mesh-external
$ kubectl create -n mesh-external secret tls nginx-server-certs --key my-nginx.mesh-external.svc.cluster.local.key --cert my-nginx.mesh-external.svc.cluster.local.crt
$ kubectl create -n mesh-external secret generic nginx-ca-certs --from-file=example.com.crt
$ cat <<\EOF > ./nginx.conf
events {
}
http {
log_format main '$remote_addr - $remote_user [$time_local] $status '
'"$request" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log;
server {
listen 443 ssl;
root /usr/share/nginx/html;
index index.html;
server_name my-nginx.mesh-external.svc.cluster.local;
ssl_certificate /etc/nginx-server-certs/tls.crt;
ssl_certificate_key /etc/nginx-server-certs/tls.key;
ssl_client_certificate /etc/nginx-ca-certs/example.com.crt;
ssl_verify_client on;
}
}
EOF
kubectl create configmap nginx-configmap -n mesh-external --from-file=nginx.conf=./nginx.conf
kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
name: my-nginx
namespace: mesh-external
labels:
run: my-nginx
spec:
ports:
- port: 443
protocol: TCP
selector:
run: my-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
namespace: mesh-external
spec:
selector:
matchLabels:
run: my-nginx
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 443
volumeMounts:
- name: nginx-config
mountPath: /etc/nginx
readOnly: true
- name: nginx-server-certs
mountPath: /etc/nginx-server-certs
readOnly: true
- name: nginx-ca-certs
mountPath: /etc/nginx-ca-certs
readOnly: true
volumes:
- name: nginx-config
configMap:
name: nginx-configmap
- name: nginx-server-certs
secret:
secretName: nginx-server-certs
- name: nginx-ca-certs
secret:
secretName: nginx-ca-certs
EOF
my-nginx
服务,是无法访问的。[root@master1 istio-1.19.3]#kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sS http://my-nginx.mesh-external.svc.cluster.local
[root@master1 istio-1.19.3]#kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sS https://my-nginx.mesh-external.svc.cluster.local
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
command terminated with exit code 60
[root@master1 istio-1.19.3]#kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -k -sS https://my-nginx.mesh-external.svc.cluster.local
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.21.5</center>
</body>
</html>
为 egress 流量配置双向 TLS
kubectl create secret -n istio-system generic client-credential --from-file=tls.key=client.example.com.key \
--from-file=tls.crt=client.example.com.crt --from-file=ca.crt=example.com.crt
Secret 所在的命名空间必须与出口网关部署的位置一致,我们这里是 istio-system
命名空间。
my-nginx.mesh-external.svc.cluster.local
创建一个端口为 443 的 Egress Gateway,以及目标规则和虚拟服务来引导流量流经 egress 网关并从 egress 网关流向外部服务。kubectl apply -f - <
上面我们定义的 Gateway
对象和前面的一样,只是将端口改为了 443,然后在 tls
中指定了 mode: ISTIO_MUTUAL
,表示该 Gateway
对象用于 TLS 双向认证协议的请求。
然后同样在后面的 DestinationRule
对象中配置了通过 istio-egressgateway
的流量的规则,这里我们定义了 443
端口的 tls
模式为 ISTIO_MUTUAL
,表示当访问 my-nginx.mesh-external.svc.cluster.local
的 TLS 请求时执行 TLS 双向认证。
VirtualService
对象来引导流量流经 egress 网关:kubectl apply -f - <apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-nginx-through-egress-gateway
spec:
hosts:
- my-nginx.mesh-external.svc.cluster.local
gateways:
- istio-egressgateway
- mesh # 网格内部的流量
http:
- match:
- gateways:
- mesh
port: 80
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: nginx
port:
number: 443
weight: 100
- match:
- gateways:
- istio-egressgateway
port: 443
route:
- destination:
host: my-nginx.mesh-external.svc.cluster.local
port:
number: 443
weight: 100
EOF
上面的 VirtualService
对象定义网格内部对 my-nginx.mesh-external.svc.cluster.local
服务的访问引导至 istio-egressgateway
,然后再由 istio-egressgateway
引导流量流向外部服务。
kubectl apply -n istio-system -f - <apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: originate-mtls-for-nginx
spec:
host: my-nginx.mesh-external.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: MUTUAL
credentialName: client-credential # 这必须与之前创建的用于保存客户端证书的 Secret 相匹配
sni: my-nginx.mesh-external.svc.cluster.local
EOF
http://my-nginx.mesh-external.svc.cluster.local
:$ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sS http://my-nginx.mesh-external.svc.cluster.local
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
kubectl logs -l istio=egressgateway -n istio-system | grep 'my-nginx.mesh-external.svc.cluster.local' | grep HTTP
将显示类似如下的一行:
[2023-11-17T08:23:51.203Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 17 16 "10.244.1.100" "curl/7.81.0-DEV" "434b5755-54da-9924-9e2a-a204b5a2124c" "my-nginx.mesh-external.svc.cluster.local" "10.244.1.106:443" outbound|443||my-nginx.mesh-external.svc.cluster.local 10.244.2.239:35198 10.244.2.239:8443 10.244.1.100:56448 my-nginx.mesh-external.svc.cluster.local -
即使我们直接在网格中访问的是 HTTP 的服务,但是通过配置 Istio,我们也可以实现对外部服务的双向 TLS 认证。
我的博客主旨:
微信二维码
x2675263825 (舍得), qq:2675263825。
微信公众号
《云原生架构师实战》
个人博客站点
http://onedayxyy.cn/
语雀
https://www.yuque.com/xyy-onlyone
csdn
https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421
知乎
https://www.zhihu.com/people/foryouone
好了,关于本次就到这里了,感谢大家阅读,最后祝大家生活快乐,每天都过的有意义哦,我们下期见!