tls安全设置(tls安全设置未设置为默认)

tls安全设置

今天去客户现场帮忙排查一个网络问题。
该问题现象是客户访问某个事业单位网站，然后无法访问该网站，提示“无法安全地连接到此网页”，可能是过期或者不安全的TLS安全设置有问题。
经过排查，发现在客户网络中有深信服AC。
然后在深信服AC的系统管理-系统配置-全局排除地址里面添加排除地址后，网页就可以正常打开了。
希望分享该经验，能够帮助到大家解决企业网络问题。
欢迎大家点个免费的关注。

istio 1.10学习笔记13: 使用认证策略设置双向TLS和终端用户认证

前面3~12节学习了istio的流量管理功能，包括如何配置请求路由、故障注入、流量转移、流量镜像、设置请求超时和熔断、将服务网格外部流量接入到集群内、控制服务网格的出口流量等。
从本节开始学习istio的安全管理功能，看istio是如何保护服务网格内的微服务的。
本节将根据istio官方文档https://istio.io/latest/zh/docs/tasks/security/authentication/authn-policy/中的内容，学习使用istio的认证策略来设置双向TLS和基本的终端用户认证。

环境准备

创建foo, bar两个命名空间，并开启istio sidecar代理自动注入:

kubectl create ns fookubectl label namespace foo istio-injection=enabledkubectl create ns barkubectl label namespace bar istio-injection=enabled

分别在foo, bar两个命名空间内部署httpbin服务和启动一个radial/busyboxplus:curl容器的pod。
httpbin和curl都将被自动注入isito envoy sidecar代理。

kubectl apply -f samples/httpbin/httpbin.yaml -n fookubectl run curl --image=radial/busyboxplus:curl -it -n fookubectl apply -f samples/httpbin/httpbin.yaml -n barkubectl run curl --image=radial/busyboxplus:curl -it -n bar

创建一个legacy命名空间，不开启isito sidecar自动注入，在该命名空间内部署部署httpbin服务和curl服务，它们将不会有sidecar代理。

kubectl create ns legacykubectl apply -f samples/httpbin/httpbin.yaml -n legacykubectl run curl --image=radial/busyboxplus:curl -it -n legacy

测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求，都成功返回200。

for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec curl -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}
"; done; donecurl.foo to httpbin.foo: 200curl.foo to httpbin.bar: 200curl.foo to httpbin.legacy: 200curl.bar to httpbin.foo: 200curl.bar to httpbin.bar: 200curl.bar to httpbin.legacy: 200curl.legacy to httpbin.foo: 200curl.legacy to httpbin.bar: 200curl.legacy to httpbin.legacy: 200

使用以下命令确认系统中没有对等身份验证(peerauthentication)策略：

kubectl get peerauthentication --all-namespacesNo resources found

默认的"自动双向TLS认证"

默认情况下，Istio会跟踪迁移到Istio代理的服务器工作负载并配置客户端代理，将双向TLS流量自动发送到这些工作负载，并将plain-text流量发送到没有sidecar的工作负载。

也就是说，在默认情况下，无需做额外配置，具有sidecar代理的工作负载(如命名空间foo中的curl和httpbin)之间的所有流量都将自动开启双向TLS。
可以检查httpbin/header的响应。
自动开启了双向TLS时，代理会将X-Forwarded-Client-Cert请求头注入到后端的upstream请求。
即有X-Forwarded-Client-Cert这个请求头，则说明开启了双向TLS。

kubectl exec curl -c curl -n foo -- curl -s http://httpbin.foo:8000/headers -s | grep X-Forwarded-Client-Cert | sed &39;s/Hash=a-z0-9;/Hash=<redacted>;/&39;    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=<redacted>;Subject="";URI=spiffe://cluster.local/ns/foo/sa/default"

当服务端工作负载没有sidecar代理时(如命名空间legacy中的httbin)，则客户端到此工作负载的请求将会是plain-text的，X-Forwarded-Client-Cert请求头将不会存在。

kubectl exec curl -c curl -n foo -- curl -s http://httpbin.legacy:8000/headers -s | grep X-Forwarded-Client-Cert | sed &39;s/Hash=a-z0-9;/Hash=<redacted>;/&39;

配置全局严格模式启用istio双向TLS

前面学习了具有sidecar代理的工作负载之间将自动启用双向TLS认证，但工作负载仍然可以接收plain-text流量。
可以通过将整个服务网格的对等认证策略(PeerAuthentication)设置为STRICT模式，以阻止整个网格的服务以非双向TLS通信。
如下所示，全局的对等认证策略是没有selector的，且它必须位于安装istio的根命名空间内(如istio-system)。

kubectl apply -f - <<EOFapiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata:  name: "default"  namespace: "istio-system"spec:  mtls:    mode: STRICTEOF

再次测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求：

for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec curl -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}
"; done; donecurl.foo to httpbin.foo: 200curl.foo to httpbin.bar: 200curl.foo to httpbin.legacy: 200curl.bar to httpbin.foo: 200curl.bar to httpbin.bar: 200curl.bar to httpbin.legacy: 200curl.legacy to httpbin.foo: 000command terminated with exit code 56curl.legacy to httpbin.bar: 000command terminated with exit code 56curl.legacy to httpbin.legacy: 200

会发现没有sidecar代理的curl.legacy到有sidecar代理的httpbin.foo和httpbin.bar的请求将会失败，因为全局的对等认证策略是严格模式，要求客户端与httpbin.foo和httpbin.bar之间的流量必须是双向TLS的。

命名空间级别的双向TLS和工作负载级别的双向TLS

如果你觉得全局开启双向TLS太严格了，还可以为每个命名空间或者工作负载启用双向TLS。

在测试前先删除前面创建的全局对等认证策略:

kubectl delete peerauthentication -n istio-system default

创建命名空间级别的对等认证策略，只需要在metadata字段中指定具体的命名空间即可:

kubectl apply -f - <<EOFapiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata:  name: "default"  namespace: "foo"spec:  mtls:    mode: STRICTEOF

因为上面创建的这个策略只应用于命名空间foo中的服务，再次测试在foo, bar, legacy三个命名空间中的curl pod内都可以使用curl向httpbin.foo, httpbin.bar, httpbin.legacy发送http请求。
会发现只有从没有sidecar代理的(curl.legacy)到有sidecar的代理的httpbin.foo的请求会失败。

for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec curl -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}
"; done; donecurl.foo to httpbin.foo: 200curl.foo to httpbin.bar: 200curl.foo to httpbin.legacy: 200curl.bar to httpbin.foo: 200curl.bar to httpbin.bar: 200curl.bar to httpbin.legacy: 200curl.legacy to httpbin.foo: 000command terminated with exit code 56curl.legacy to httpbin.bar: 200curl.legacy to httpbin.legacy: 200

下面演示为特定工作负载启用双向TLS。
要为特定工作负载设置对等身份验证策略，必须配置selector字段并指定与所需工作负载匹配的标签。
然而Istio不能将出站双向TLS流量的工作负载策略聚合到服务。
应该通过配置目标规则destinationrule来管理该行为。

在测试之前，先删除前面创建的命名空间级别的认证策略:

kubectl delete PeerAuthentication default -n foo

下面创建对等认证策略，并使用selector将策略应用于httpbin.bar:

cat <<EOF | kubectl apply -n bar -f -apiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata:  name: "httpbin"  namespace: "bar"spec:  selector:    matchLabels:      app: httpbin  mtls:    mode: STRICTEOF

添加一个目标规则:

cat <<EOF | kubectl apply -n bar -f -apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:  name: "httpbin"spec:  host: "httpbin.bar.svc.cluster.local"  trafficPolicy:    tls:      mode: ISTIO_MUTUALEOF

此时再次测试从sleep.legacy到httpbin.bar的请求因为同样的原因失败。

for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec curl -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}
"; done; donecurl.foo to httpbin.foo: 200curl.foo to httpbin.bar: 200curl.foo to httpbin.legacy: 200curl.bar to httpbin.foo: 200curl.bar to httpbin.bar: 200curl.bar to httpbin.legacy: 200curl.legacy to httpbin.foo: 200curl.legacy to httpbin.bar: 000command terminated with exit code 56curl.legacy to httpbin.legacy: 200

关于策略的优先级，特定服务策略比命名空间范围的策略优先级高，这里不再进行测试。

终端用户认证

使用ingressgateway将httbin.foo服务暴露到集群外部:

kubectl apply -f - <<EOFapiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata:  name: httpbin-gateway  namespace: foospec:  selector:    istio: ingressgateway  use istio default controller  servers:  - port:      number: 80      name: http      protocol: HTTP    hosts:    - httpbin.example.com    tls:      httpsRedirect: true  - port:      number: 443      name: https      protocol: HTTPS    tls:      mode: SIMPLE      credentialName: bookinfo-credential  must be the same as secret    hosts:    - httpbin.example.com---apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: httpbin  namespace: foospec:  hosts:  - "httpbin.example.com"  gateways:  - httpbin-gateway  http:  - route:    - destination:        port:          number: 8000        host: httpbin.foo.svc.cluster.localEOF

从集群外部访问入口网关https://httpbin.example.com/headers，确认可以正常访问:

curl https://httpbin.example.com/headers{  "headers": {    "Accept": "/",    "Host": "httpbin.example.com",    "User-Agent": "curl/7.64.1",    "X-B3-Parentspanid": "738289b8959bdc53",    "X-B3-Sampled": "1",    "X-B3-Spanid": "747cf3f440f92ed1",    "X-B3-Traceid": "d2f668d695ae4eca738289b8959bdc53",    "X-Envoy-Attempt-Count": "1",    "X-Envoy-Internal": "true",    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=47b94c19ba0586a6e9081f6449b8b7f18b2e3981e85591bbe988650be2ca16a8;Subject="";URI=spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"  }}

下面添加一个身份验证策略，该策略要求入口网关需要指定终端用户的JWT:

kubectl apply -f - <<EOFapiVersion: security.istio.io/v1beta1kind: RequestAuthenticationmetadata:  name: "jwt-example"  namespace: istio-systemspec:  selector:    matchLabels:      istio: ingressgateway  jwtRules:  - issuer: "testing@secure.istio.io"    jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.10/security/tools/jwt/samples/jwks.json"EOF

策略生效的命名空间是istio-system，生效的工作负载由selector字段决定，上面的配置值是带有istio:ingressgateway标签的工作负载。

如果在authorization header(默认情况)中提供了令牌，则Istio将使用public key set验证token，bearer token无效会被拒绝，而没有提供bearer token的请求会被接收。
因此要观察此行为，需要在没有token，无效token和有效token的情况下进行测试:

curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}
"200curl --header "Authorization: Bearer deadbeef" https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}
"401TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.10/security/tools/jwt/samples/demo.jwt -s) && curl --header "Authorization: Bearer $TOKEN" https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}
"200 

下面配置要求必须提供有效的token，这样没有token的请求也会被拒绝:

kubectl apply -f - <<EOFapiVersion: security.istio.io/v1beta1kind: AuthorizationPolicymetadata:  name: "frontend-ingress"  namespace: istio-systemspec:  selector:    matchLabels:      istio: ingressgateway  action: DENY  rules:  - from:    - source:        notRequestPrincipals: ""    to:    - operation:        hosts: "httpbin.example.com"EOF

此时再次不带token请求时会被拒绝:

curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}
"403

下面配置按路由提供有效token，路径指host、path、或者method:

kubectl apply -f - <<EOFapiVersion: security.istio.io/v1beta1kind: AuthorizationPolicymetadata:  name: "frontend-ingress"  namespace: istio-systemspec:  selector:    matchLabels:      istio: ingressgateway  action: DENY  rules:  - from:    - source:        notRequestPrincipals: ""    to:    - operation:        paths: "/headers"        hosts: "httpbin.example.com"EOF

上面的配置生效后，不提供token访问https://httpbin.example.com/headers将被拒绝，但可以访问其他路径。

curl https://httpbin.example.com/headers -s -o /dev/null -w "%{http_code}
"403curl https://httpbin.example.com/ip -s -o /dev/null -w "%{http_code}
"200

可以看到有点api网关的意思了。

参考

https://istio.io/latest/zh/docs/tasks/security/authentication/authn-policy/

https://istio.io/latest/docs/tasks/security/authentication/authn-policy/

istio 1.10学习笔记13: 使用认证策略设置双向TLS和终端用户认证

俄罗斯和白俄的https安全连接协议将会失效15日，乌克兰数字转型部部长米哈伊尔·费多罗夫称，向乌克兰宣战的两个国家俄罗斯和白俄罗斯的https协议将会失效。
GeoTrust、Sectigo、DigiCert、Thawte和Rapid将不再为俄罗斯和白俄罗斯网站发布证书并更新现有的证书。
这一切都得益于乌克兰数字转型部。
在它的倡议下，提供SSL和TLS安全证书的上述主要公司宣布停止对俄罗斯和白俄罗斯的服务。
这些公司将会自动对俄罗斯和白俄罗斯所有用户构成威胁，世界各地的浏览器会屏蔽它们。
“这实际上意味着俄罗斯https协议的死亡。”