2023.11.25-istio安全

img

目录

image-20231125080337605

文章目录

    • 目录
    • 本节实战
    • 1、安全概述
    • 2、证书签发流程
      • 1.签发证书
      • 2.身份认证
    • 3、认证
      • 1.对等认证
        • a.默认的宽容模式
        • b.全局严格 mTLS 模式
        • c.命名空间级别策略
        • d.为每个工作负载启用双向 TLS
      • 2.请求认证
        • a.JWK 与 JWKS 概述
        • b.配置 JWT 终端用户认证
        • c.设置强制认证规则
    • 关于我
    • 最后

本节实战

实战名称
🚩 实战:对等认证(默认的宽容模式)-2023.11.24(测速成功)
🚩 实战:对等认证(全局严格 mTLS 模式)-2023.11.24(测速成功)
🚩 实战:对等认证(命名空间级别策略)-2023.11.24(测速成功)
🚩 实战:对等认证(为每个工作负载启用双向 TLS)-2023.11.24(测速成功)
🚩 实战:对等认证(为每个端口配置不同的对等认证策略)-2023.11.24(测速成功)
🚩 实战:请求认证-2023.11.25(测试成功)

1、安全概述

安全是一个非常重要的话题,但也是平时容易被忽略的一个话题,我们在开发应用的时候,往往会忽略安全,但是当应用上线后,安全问题就会暴露出来,这时候就会造成很大的损失。Istio 通过在服务之间注入 Sidecar 代理,来实现对服务之间的流量进行控制和监控,从而实现服务之间的安全通信。

接下来我们将从**证书管理、认证、授权**等几个方面来学习 Istio 的安全机制。

将单一应用程序拆分为微服务可提供各种好处,包括更好的灵活性、可伸缩性以及服务复用的能力。但是,微服务也有特殊的安全需求:

  • 为了抵御中间人攻击,需要流量加密。
  • 为了提供灵活的服务访问控制,需要双向 TLS 和细粒度的访问策略。
  • 要确定谁在什么时候做了什么,需要审计工具。

Istio 尝试提供全面的安全解决方案来解决所有这些问题,Istio 安全性可以减轻针对你的数据、端点、通信和平台的内外威胁。

img

Istio 为微服务提供了无侵入,可插拔的安全框架。应用不需要修改代码,就可以利用 Istio 提供的双向 TLS 认证实现服务身份认证,并基于服务身份信息提供细粒度的访问控制。Istio 安全的高层架构如下图所示:

img

上图展示了 Istio 中的服务认证授权两部分。服务认证是通过控制面和数据面一起实现的:

  • 控制面:Istiod 中实现了一个 CA (Certificate Authority,证书机构) 服务器。该 CA 服务器负责为网格中的各个服务签发证书,并将证书分发给数据面的各个服务的边车代理。
  • 数据面:在网格中的服务相互之间发起 plain(原始的,未加密的) HTTP/TCP 通信时,和服务同一个 pod 中的边车代理会拦截服务请求,采用证书和对端服务的边车代理进行双向 TLS 认证并建立一个 TLS 连接,使用该 TLS 连接来在网络中传输数据。

Istio 的授权功能为网格中的工作负载提供网格、命名空间和工作负载级别的访问控制,这种控制层级提供了许多优点:

  • 工作负载到工作负载以及最终用户到工作负载的授权。
  • 一个简单的 API:它包括一个单独的并且很容易使用和维护的 AuthorizationPolicy CRD。
  • 灵活的语义:运维人员可以在 Istio 属性上定义自定义条件,并使用 DENYALLOW 动作。
  • 高性能:Istio 授权是在 Envoy 本地强制执行的。
  • 高兼容性:原生支持 HTTP、HTTPS 和 HTTP2,以及任意普通 TCP 协议。

**授权策略对服务器端 Envoy 代理的入站流量实施访问控制。**每个 Envoy 代理都运行一个授权引擎,该引擎在运行时授权请求。当请求到达代理时,授权引擎根据当前授权策略评估请求上下文,并返回授权结果 ALLOWDENY。运维人员可以通过 YAML 资源清单文件来指定 Istio 授权策略。

2、证书签发流程

默认情况下,Istio CA 生成自签名根证书和密钥,并使用它们来签署工作负载证书。为了保护根 CA 密钥,我们应该使用在安全机器上离线运行的根 CA(比如使用 Hashicorp Vault 进行管理),并使用根 CA 向每个集群中运行的 Istio CA 颁发中间证书。Istio CA 可以使用管理员指定的证书和密钥对工作负载证书进行签名,并将管理员指定的根证书作为信任根分发给工作负载。

img

1.签发证书

当我们有了 Istio CA 根证书后就可以使用它来签发工作负载证书了,那么整个的证书签发流程又是怎样的呢?如下图所示:

img

  • Envoy 向 pilot-agent 发起一个 SDS (Secret Discovery Service) 请求(启动的时候),要求获取自己的证书和私钥。
  • pilot-agent 生成私钥和 CSR 证书签名请求,向 Istiod 发送证书签发请求,请求中包含 CSR 和该 Pod 中服务的身份信息。
  • Istiod 提供 gRPC 服务以接受证书签名请求,根据请求中服务的身份信息(如果是 Kubernetes 则使用 Service Account)为其签发证书,将证书返回给 pilot-agent
  • pilot-agent 将证书和私钥通过 SDS 接口返回给 Envoy。
  • pilot-agent 还会监控工作负载证书的过期时间,上述过程会定期重复进行证书和密钥轮换。

这个流程和我们自己用手动方式去进行证书签发是一样的,所以我们需要先了解下证书签发的流程。Istio CA 根证书就是一个证书颁发机构,平时如果要为我们自己的网站申请 HTTPS 证书我们也是去一些正规的 CA 机构进行申请,而这个申请的信息就是生成的 CSR 证书签名请求,然后我们将这个 CSR 和身份信息提交给 CA 机构,CA 机构根据这些信息为我们签发证书,然后我们就可以使用这个证书了,只是我们这里在不同的组件上来执行这些操作,整体流程是一样的。

istio-ca-root-cert

[root@master1 ~]#kubectl get cm -nistio-system
NAME                                  DATA   AGE
……
istio-ca-root-cert                    1      15d
……
[root@master1 ~]#[root@master1 ~]#kubectl get po istiod-644f5d55fc-gs96f -nistio-system -oyaml
……- mountPath: /var/run/secrets/istiod/caname: istio-csr-ca-configmapreadOnly: true……- configMap:defaultMode: 420name: istio-ca-root-certoptional: truename: istio-csr-ca-configmap

image-20231123122545714

2.身份认证

另外要通过服务证书来实现网格中服务的身份认证,必须首先确保服务从控制面获取自身证书的流程是安全的。Istio 通过 Istiod 和 pilog-agent 之间的 gRPC 通道传递 CSR 和证书,因此在这两个组件进行通信时,双方需要先验证对方的身份,以避免恶意第三方伪造 CSR 请求或者假冒 Istiod CA 服务器。Istio 中主要包含下面两种认证方式:

  • Istiod 身份认证

  • Istiod 采用其内置的 CA 服务器为自身签发一个服务器证书,并采用该服务器证书对外提供基于 TLS 的 gPRC 服务。

  • Istiod 调用 Kubernetes APIServer 生成一个名为 istio-ca-root-cert 的 ConfigMap 对象, 在该 ConfigMap 中放入了 Istiod 的 CA 根证书。

  • 该 ConfigMap 被 Mount 到 istio-proxy 容器中,被 pilot-agent 用于验证 Istiod 的服务器证书。

  • pilot-agent 和 Istiod 建立 gRPC 连接时,pilot-agent 采用标准的 TLS 服务器认证流程对 Istiod 的服务器证书进行认证。

  • pilot-agent 身份认证

  • 在 Kubernetes 中可以为每一个 Pod 关联一个 ServiceAccount,以表明该 Pod 中运行的服务的身份信息。

  • Kubernetes 会为该 ServiceAccount 生成一个 jwt token,并将该 token 通过 secret 加载到 pod 中的一个文件。

  • pilot-agent 在向 Istiod 发送 CSR 时,将其所在 Pod 的 service account token 也随请求发送给 Istiod。

  • Istiod 调用 Kube-apiserver 接口验证请求中附带的 service account token,以确认请求证书的服务身份是否合法。

这里需要注意的是不同版本的 Kubernetes 集群下面的 ServiceAccount Token 生成方式并不一样,但最终都是通过改 Token 来进行身份认证的。

  • 1.20(含 1.20)之前的版本,在创建 sa 时会自动创建一个 secret,然后这个会把这个 secret 通过投射卷挂载到 pod 里,该 secret 里面包含的 token 是永久有效的。
  • 1.21~1.23 版本,在创建 sa 时也会自动创建 secret,但是在 pod 里并不会使用 secret 里的 token,而是由 kubelet 到 TokenRequest API 去申请一个 token,该 token 默认有效期为一年,但是 pod 每一个小时会更新一次 token。
  • 1.24 版本及以上,在创建 sa 时不再自动创建 secret 了,只保留由 kubelet 到 TokenRequest API 去申请 token。

3、认证

Istio 提供两种类型的认证用于管控网格服务间的双向 TLS 和终端用户的身份认证。:

  • 对等认证:用于服务到服务的认证,以验证建立连接的客户端。Istio 提供双向 TLS 作为传输认证的全栈解决方案,无需更改服务代码就可以启用它。这个解决方案:

  • 为每个服务提供代表其角色的强大身份,以实现跨集群和云的互操作性。

  • 确保服务间通信的安全。

  • 提供密钥管理系统,以自动进行密钥和证书的生成、分发和轮换。

  • 请求认证:用于终端用户认证,以验证附加到请求的凭据。Istio 使用 JSON Web Token(JWT)验证启用请求级认证,并使用自定义认证实现或任何 OpenID Connect 的认证实现来简化的开发人员体验。

1.对等认证

a.默认的宽容模式

🚩 实战:对等认证(默认的宽容模式)-2023.11.24(测速成功)

实验环境:

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(测试成功)

image-20231105111842627

  • 下面我们来创建几个示例服务来对认证配置进行测试。

这里我们将在 foobar 命名空间下各自创建带有 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 barkubectl create ns legacy
kubectl apply -f samples/httpbin/httpbin.yaml -n legacy
kubectl apply -f samples/sleep/sleep.yaml -n legacy

查看:

[root@master1 istio-1.19.3]#kubectl get po -nfoo
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-5c44d89fd9-pmzkk   2/2     Running   0          3m43s
sleep-844db44b8c-49br9     2/2     Running   0          3m42s
[root@master1 istio-1.19.3]#kubectl get po -nbar
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-5c44d89fd9-zpdww   2/2     Running   0          3m43s
sleep-844db44b8c-q688w     2/2     Running   0          3m42s
[root@master1 istio-1.19.3]#kubectl get po -nlegacy
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-86869bccff-2cmj2   1/1     Running   0          3m47s
sleep-9454cc476-vvr4q      1/1     Running   0          3m44s

现在可以在 foobarlegacy 三个命名空间下的任意 sleep Pod 中使用 curl 向 httpbin.foohttpbin.barhttpbin.legacy 发送 HTTP 请求来验证部署结果,所有请求都应该成功并返回 HTTP 200。

  • 例如验证 sleep.barhttpbin.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 ID 是服务的唯一标识,具体实现使用 URI 资源标识符。
  • SPIFFE Verifiable Identity Document (SVID) 标准,将 SPIFFE ID 编码到一个加密的可验证的数据格式中。
  • 颁发与撤销 SVID 的 API 标准。

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 服务:
[root@master1 istio-1.19.3]#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
{"headers": {"Accept": "*/*", "Host": "httpbin.legacy:8000", "User-Agent": "curl/7.81.0-DEV", "X-B3-Sampled": "1", "X-B3-Spanid": "1385a68dd52bc759", "X-B3-Traceid": "94d64875182fd6101385a68dd52bc759", "X-Envoy-Attempt-Count": "1", "X-Envoy-Decorator-Operation": "httpbin.legacy.svc.cluster.local:8000/*", "X-Envoy-Peer-Metadata": "ChkKDkFQUF9DT05UQUlORVJTEgcaBXNsZWVwChoKCkNMVVNURVJfSUQSDBoKS3ViZXJuZXRlcwodCgxJTlNUQU5DRV9JUFMSDRoLMTAuMjQ0LjIuMjIKGQoNSVNUSU9fVkVSU0lPThIIGgYxLjE5LjMKoQEKBkxBQkVMUxKWASqTAQoOCgNhcHASBxoFc2xlZXAKJAoZc2VjdXJpdHkuaXN0aW8uaW8vdGxzTW9kZRIHGgVpc3RpbwoqCh9zZXJ2aWNlLmlzdGlvLmlvL2Nhbm9uaWNhbC1uYW1lEgcaBXNsZWVwCi8KI3NlcnZpY2UuaXN0aW8uaW8vY2Fub25pY2FsLXJldmlzaW9uEggaBmxhdGVzdAoaCgdNRVNIX0lEEg8aDWNsdXN0ZXIubG9jYWwKIAoETkFNRRIYGhZzbGVlcC04NDRkYjQ0YjhjLTQ5YnI5ChIKCU5BTUVTUEFDRRIFGgNmb28=", "X-Envoy-Peer-Metadata-Id": "sidecar~10.244.2.22~sleep-844db44b8c-49br9.foo~foo.svc.cluster.local"}
}[root@master1 istio-1.19.3]#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
b.全局严格 mTLS 模式

🚩 实战:对等认证(全局严格 mTLS 模式)-2023.11.24(测速成功)

实验环境:

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(测试成功)

image-20231105111842627

事实上当 Istio 自动将代理和工作负载之间的所有流量升级到双向 TLS 时,工作负载仍然可以接收明文流量,如果想要禁用非 mTLS 的通信流量,我们可以使用一个 PeerAuthentication 资源对象来进行配置,只需要将整个网格的对等认证策略设置为 STRICT 模式,作用域为整个网格范围的对等认证策略不设置 selector 即可,这种认证策略必须应用于根命名空间(istiod 所在的命名空间),例如:

  • 创建下资源
#peer-strict-global.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication # 对等认证策略
metadata:name: defaultnamespace: istio-system
spec:mtls:mode: STRICT # STRICT 模式表示只允许 mTLS

对等认证策略指定 Istio 对目标工作负载实施的双向 TLS 模式。支持以下模式:

  • PERMISSIVE:工作负载接受双向 TLS 和纯文本流量,也就是所谓的宽容模式此模式在迁移因为没有 Sidecar 而无法使用双向 TLS 的工作负载的过程中非常有用。一旦工作负载完成 Sidecar 注入的迁移,应将模式切换为 STRICT
  • STRICT:工作负载仅接收双向 TLS 流量。
  • DISABLE:禁用双向 TLS。从安全角度来看,除非提供自己的安全解决方案,否则请勿使用此模式。

这个对等认证策略将工作负载配置为仅接受 mTLS 加密的请求。由于未对 selector 字段指定值,因此该策略适用于网格中的所有工作负载。

  • 直接应用上面这个对等认证策略后,我们再次发送请求来进行测试:
[root@master1 istio-1.19.3]#kubectl apply -f peer-strict-global.yaml 
peerauthentication.security.istio.io/default created
[root@master1 istio-1.19.3]#kubectl get PeerAuthentication -nistio-system
NAME      MODE     AGE
default   STRICT   14s
$ 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.legacyhttpbin.foohttpbin.bar 的请求都失败了,其他依然是成功的,这是因为我们现在配置了 STRICT 严格要求使用 mTLS,由于 sleep.legacy 没有 Envoy Sidecar,所以无法满足这一要求,所以要访问网格内部的工作负载是不被允许的。**那为什么可以访问 httpbin.legacy 呢?**这是因为我们在 legacy 命名空间下的 httpbin 服务没有 Envoy Sidecar,所以它不会被 Istio 管理,也就不会被强制要求使用 mTLS 了,所以我们可以直接访问它。

c.命名空间级别策略

🚩 实战:对等认证(命名空间级别策略)-2023.11.24(测速成功)

实验环境:

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(测试成功)

image-20231105111842627

  • 上面我们是在根命名空间(istiod 所在的命名空间)下配置的对等认证策略,这样会影响到整个网格,如果我们只想对某个命名空间下的服务进行配置,那么我们可以使用命名空间级别的对等认证策略,该策略的规范与整个网格级别的规范相同,但是可以在 metadata 字段指定具体的命名空间的名称。比如我们要在 foo 命名空间上启用严格的双向 TLS 对等策略,可以创建如下所示的资源对象:
#peer-strict-ns.yaml 
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: defaultnamespace: foo # 命名空间级别
spec:mtls:mode: STRICT
  • 直接应用上面的资源对象,然后再次发送请求来进行测试:
# 首先删除上面创建的全局对等认证策略
[root@master1 istio-1.19.3]#kubectl delete  -f peer-strict-global.yaml #部署:
[root@master1 istio-1.19.3]#kubectl apply -f peer-strict-ns.yaml$ 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)的请求会失败,其余都是成功的。

测试结束。😘

d.为每个工作负载启用双向 TLS

🚩 实战:对等认证(为每个工作负载启用双向 TLS)-2023.11.24(测速成功)

实验环境:

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(测试成功)

image-20231105111842627

  • 要为特定工作负载设置对等认证策略,我们就必须配置 selector 字段指定与所需工作负载匹配的标签。比如我们只想要为 httpbin.bar 服务启用严格模式的 mTLS,则可以创建如下所示的资源对象:
#peer-strict-pod.yaml 
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: "httpbin"namespace: "bar"
spec:selector:matchLabels:app: httpbin # 匹配 httpbin 应用的标签mtls:mode: STRICT
  • 上面的资源对象将为 bar 命名空间中的 httpbin 应用启用严格模式的 mTLS,其他工作负载不受影响。直接应用上面的资源对象,然后再次发送请求来进行测试:
#部署
[root@master1 istio-1.19.3]#kubectl apply -f peer-strict-pod.yaml$ 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.legacyhttpbin.bar 的请求因为同样的原因失败。

测试结束。😘


为每个端口配置不同的对等认证策略

🚩 实战:对等认证(为每个端口配置不同的对等认证策略)-2023.11.24(测速成功)

实验环境:

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(测试成功)

image-20231105111842627

  • 除此之外我们还可以为每个端口配置不同的对等认证策略,例如,以下对等认证策略要求在除 80 端口以外的所有端口上都使用双向 TLS:
#peer-strict-pod-port.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: "httpbin"namespace: "bar"
spec:selector:matchLabels:app: httpbinmtls:mode: STRICTportLevelMtls:80:mode: DISABLE

上面的资源对象中我们配置了一个 portLevelMtls 字段,该字段用于配置端口级别的对等认证策略,这里我们配置了 80 端口的对等认证策略为 DISABLE,即禁用双向 TLS,其他端口的对等认证策略为 STRICT,即启用双向 TLS,也就是说我们只允许 httpbin 应用的 80 端口接收明文流量,其他端口都必须使用双向 TLS。

  • 直接应用上面的资源对象,然后再次发送请求来进行测试:
#[root@master1 istio-1.19.3]#kubectl apply -f peer-strict-pod-port.yaml$ 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.legacyhttpbin.bar 的请求成功了,因为我们禁用了 80 端口的双向 TLS,所以 sleep.legacy 可以访问到 httpbin.bar 的服务了。

  • 测试完成后记得删除上面创建的对等认证策略:
kubectl delete peerauthentication default -n foo
kubectl delete peerauthentication httpbin -n bar

测试结束。😘

2.请求认证

Istio 的请求认证用于终端用户认证,以验证附加到请求的凭据。Istio 使用 JWT 验证启用请求级认证,并使用自定义认证实现或任何 OpenID Connect 的认证实现来进行认证简化。

要在 Istio 中进行请求认证,可以通过一个 RequestAuthentication 资源对象来进行配置,如果请求包含无效的认证信息,它将根据配置的认证规则拒绝该请求。不包含任何认证凭证的请求将被接受,但不会有任何认证的身份。

🚩 实战:请求认证-2023.11.25(测试成功)

a.JWK 与 JWKS 概述

Istio 使用 JWT 对终端用户进行身份验证,Istio 要求提供 JWKS 格式的信息,用于 JWT 签名验证。因此这里得先介绍一下 JWKJWKS

JWKJSON 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"   #"https://goproxy.io" 或者 "https://goproxy.cn"都行的。
$ 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

注意:这里是要具有Go环境的:

image-20231124074547767

image-20231124074724282

[root@master1 ~]#cp /opt/goDir/bin/jwx /usr/local/bin/
[root@master1 ~]#cd /tmp/
[root@master1 tmp]#jwx 
NAME:jwx - Tools for various JWE/JWK/JWS/JWT operationsUSAGE:jwx [global options] command [command options] [arguments...]COMMANDS:jwa      List available algorithms and typesjwe      Work with JWE messagesjwk      Work with JWK and JWK setsjws      Work with JWS messageshelp, h  Shows a list of commands or help for one commandGLOBAL OPTIONS:--help, -h  show help
[root@master1 tmp]#

报错

/opt/goDir/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.11/cert/cert.go:9:2: //go:build comment without // +build comment
/opt/goDir/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.11/x25519/x25519.go:10:2: //go:build comment without // +build comment
make: *** [jwx] Error 1

image-20231125065257703

/opt/goDir/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.11/cert/cert.go:9:2: //go:build comment without // +build comment /opt/goDir/pkg/mod/github.com/lestrrat-go/jwx/v2@v2.0.11/x25519/x25519.go:10:2: //go:build comment without // +build comment make: *** [jwx] Error 1

这个错误看起来是与 Go 的构建标记(build tags)相关的问题。错误信息指出在两个文件(cert.gox25519.go)的第 9 行和第 10 行有 //go:build 注释,但是缺少了 // +build 注释。

// +build 注释是用于控制构建的,指示在何种条件下构建或不构建文件。如果这些文件是条件性地构建的,你需要确保这些注释的格式是正确的。

在这两个文件中,你可能需要添加 // +build 注释,例如:

go// +build some_tag

或者,如果这些文件是通用的,不受构建标记的影响,你可以直接删除这些 //go:build 注释。

请注意,如果你在使用某些构建工具,比如 make,确保你的构建脚本和构建过程正确处理了这些文件,并且使用了正确的构建标记。

🍀

排查过程:

image-20231125065644901

image-20231125065554371

image-20231125065718822

🍀

感觉是自己的go版本问题……

重新换装了go版本后,果然好了;

[root@master1 ~]#go version
go version go1.17.13 linux/amd64#原来自己go版本是:go1.16.2

image-20231125070247577

  • 下面我们使用 jwx 命令行工具生成一个 JWK,通过模板指定 kidyoudianzhishi-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": 1700686042,"name": "Yang Ming"
}
EOFjwx jws sign --key rsa.jwk --alg RS256 --header '{"typ":"JWT"}' -o token.txt - <<EOF
{"iss": "testing@secure.istio.io","sub": "cnych001","iat": 1700858397,"exp": 1700886042,"name": "Yang Ming"
}
EOF

image-20231125071635661

[root@master1 istio]#date +%s
1700867814
  • 然后查看生成的 Token 文件内容:
$ cat token.txt
eyJhbGciOiJSUzI1NiIsImtpZCI6InlvdWRpYW56aGlzaGkta2V5In0......
  • 上面生成 JWT Token 实际上是由下面的算法生成的:
base64url_encode(Header) + '.' + base64url_encode(Claims) + '.' + base64url_encode(Signature)
  • 我们可以将该 Token 粘贴到 jwt.io 网站上来解析:

img

先看一下 Headers 部分,包含了一些元数据:

  • alg: 所使用的签名算法,这里是 RSA256
  • kid: JWKkid

然后是 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"
}
b.配置 JWT 终端用户认证

上面我们了解了 JWT、JWK、JWKS 这些概念,接下来我们来配置 Istio 的认证策略使用我们自己创建的 JWKS

  • 为了方便访问,我们这里通过 Ingress 网关来暴露 httpbin.foo 服务,为其创建一个 Gateway 对象:
[root@master1 ~]#cd istio-1.19.3/
[root@master1 istio-1.19.3]#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 服务是否可以正常访问:
[root@master1 istio-1.19.3]#curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200

如果上面命令返回 200,则表示 httpbin.foo 服务可以正常访问。

  • 接下来我们就可以添加一个请求认证策略对象,该策略要求 Ingress 网关指定终端用户的 JWT。
#jwt-examplt.yaml
apiVersion: "security.istio.io/v1"
kind: RequestAuthentication
metadata:name: jwt-examplenamespace: istio-system
spec:selector:matchLabels:istio: ingressgateway #匹配我们的入口网关jwtRules:- issuer: "testing@secure.istio.io" # 签发者,需要和 JWT payload 中的 iss 属性完全一致。# forwardOriginalToken: truejwks: |{"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 的验证规则是:

  • JWT 的 payload 中有 issuer 属性,首先通过 issuer 匹配到对应的 istio 中配置的 jwks
  • JWT 的 header 中有 kid 属性,第二步在 jwks 的公钥列表中,中找到 kid 相同的公钥。
  • 使用找到的公钥进行 JWT 签名验证。

配置中的 spec.selector 可以省略,这样会直接在整个命名空间中生效,比如在 istio-system 命名空间,该配置将在全集群的所有 sidecar/ingressgateway 上生效!

默认情况下,Istio 在完成了身份验证之后,会去掉 Authorization 请求头再进行转发。这将导致我们的后端服务获取不到对应的 Payload,无法判断终端用户的身份。因此我们需要启用 Istio 的 Authorization 请求头的转发功能,只需要在上面的资源对象中添加一个 forwardOriginalToken: true 字段即可。

  • 直接应用上面的资源对象,然后再次发送请求来进行测试:
#kubectl apply -f jwt-example.yaml[root@master1 istio]#curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200

可以看到现在依然可以正常访问,但是如果我们请求的时候带上一个无效的 JWT Token,则会返回 401 错误:

[root@master1 istio]#curl --header "Authorization: Bearer abcdef" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
401
  • 要想正常访问,我们需要使用上面生成的 JWT Token 来进行访问:
[root@master1 istio]#TOKEN=$(cat token.txt)
[root@master1 istio]#curl --header "Authorization: Bearer $TOKEN" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200

可以看到就可以正常访问了。

c.设置强制认证规则

从上面的测试可以看出 Istio 的 JWT 验证规则,默认情况下会直接忽略不带 Authorization 请求头(即 JWT)的流量,因此这类流量能直接进入网格内部。通常这是没问题的,因为没有 Authorization 的流量即使进入到内部,也会因为无法通过 payload 判别身份而被拒绝操作。但是如果我们需要禁止不带 JWT 的流量,那么可以通过一个 AuthorizationPolicy 对象来进行配置了。

  • 比如拒绝任何 JWT 无效的请求,则可以创建如下的资源对象:
#ap.yaml
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:name: deny-requests-without-authorizationnamespace: istio-system
spec:selector:matchLabels:istio: ingressgatewayaction: DENY # 拒绝rules:- from:- source:notRequestPrincipals: ["*"] # 不存在任何请求身份(Principal)的 requests

上面的资源对象中我们配置的 action: DENY 表示拒绝,然后通过 rules 字段来配置拒绝的规则,这里我们配置了一个 from 字段,该字段用于指定请求的来源,这里我们配置了一个 notRequestPrincipals 字段,该字段用于指定请求的身份,这里我们配置为 *,表示任何请求身份都不允许。

  • 应用上面的资源对象后,重新发送没有令牌的请求,请求失败并返回错误码 403:
#kubectl apply -f ap.yaml[root@master1 istio]#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-authorizationnamespace: istio-system
spec:selector:matchLabels:istio: ingressgatewayaction: DENY # 拒绝rules:- from:- source:notRequestPrincipals: ["*"] # 不存在任何请求身份的 requests# 仅强制要求如下 host/path 相关的请求,必须带上 JWT tokento:- operation:hosts: ["another-host.com"]paths: ["/headers"]

需要注意的是 RequestsAuthenticationAuthorizationPolicy 这两个对象返回的错误码是不同的:

  • RequestsAuthentication 验证失败的请求,Istio 会返回 401 状态码。
  • AuthorizationPolicy 验证失败的请求,Istio 会返回 403 状态码。

最后,记得删除刚创建的资源

测试结束。😘

到这里我们就实现了对 JWT 的验证,当然除了验证之外,我们还需要授权,这个我们在下面的章节中来实现。

关于我

我的博客主旨:

  • 排版美观,语言精炼;
  • 文档即手册,步骤明细,拒绝埋坑,提供源码;
  • 本人实战文档都是亲测成功的,各位小伙伴在实际操作过程中如有什么疑问,可随时联系本人帮您解决问题,让我们一起进步!

🍀 微信二维码
x2675263825 (舍得), qq:2675263825。

image-20230107215114763

🍀 微信公众号
《云原生架构师实战》

image-20230107215126971

🍀 个人博客站点

http://onedayxyy.cn/

image-20231113073017981

image-20231113073039083

🍀 语雀

https://www.yuque.com/xyy-onlyone

image-20231113073101271

🍀 csdn

https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

image-20230107215149885

🍀 知乎

https://www.zhihu.com/people/foryouone

image-20230107215203185

最后

好了,关于本次就到这里了,感谢大家阅读,最后祝大家生活快乐,每天都过的有意义哦,我们下期见!

image-20231125080418779

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/216312.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Ceph分布式存储系统的介绍及详细安装部署过程:详细实战版(保姆级)

Ceph简介 Ceph是一个统一的分布式存储系统&#xff0c;设计初衷是提供较好的性能、可靠性和可扩展性。 Ceph项目最早起源于Sage就读博士期间的工作&#xff08;最早的成果于2004年发表&#xff09;&#xff0c;并随后贡献给开源社区。 在经过了数年的发展之后&#xff0c;目前…

管理类联考——数学——汇总篇——知识点突破——代数——函数——记忆

文章目录 整体文字提炼图像绘画 考点记忆/考点汇总——按大纲 本篇思路&#xff1a;根据各方的资料&#xff0c;比如名师的资料&#xff0c;按大纲或者其他方式&#xff0c;收集/汇总考点&#xff0c;即需记忆点&#xff0c;在通过整体的记忆法&#xff0c;比如整体信息很多&am…

VMware Workstation 17 虚拟机自启动失效 解决脚本

VMware Workstation17新增加了虚拟机自启配置 但是很奇怪在我的一台计算机上能够自启&#xff0c;在另一台计算机上就失效 编写脚本 以命令方式完成虚拟机开机自启 #虚拟机自启.batif "%1""hide" goto CmdBegin start mshta vbscript:createobject("w…

win10安装pytorch(py39)

cuda≤11.6&#xff0c;观察控制面板 观察torch对应cuda版本 https://download.pytorch.org/whl/torch/ 安装cuda11.6.0 CUDA Toolkit Archive | NVIDIA Developer cmd输入nvcc -V 编辑国内镜像源 .condarc anaconda prompt输入 查看环境 conda env list 安装py3.9…

某软件商店app抓包分析与sign加密算法实现

文章目录 1. 写在前面2. 抓包配置3. 抓包分析4. 接口测试5. sign加密算法6. 数据效果展示 【作者主页】&#xff1a;吴秋霖 【作者介绍】&#xff1a;Python领域优质创作者、阿里云博客专家、华为云享专家。长期致力于Python与爬虫领域研究与开发工作&#xff01; 【作者推荐】…

数据治理技术:研究现状与数据规范

随着信息技术的迅速发展,数据规模逐渐扩大&#xff0c;与此同时&#xff0c;劣质数据也随之而来&#xff0c;极大地降低了数据挖掘的质量&#xff0c;对信息社会造成了严重的困扰&#xff0c;劣质数据大量存在于很多领域和机构&#xff0c;国外权威机构的统计表明&#xff1a;美…

0001Java程序设计-springboot基于微信小程序批发零售业商品管理系统

文章目录 **摘 要****目录**系统实现开发环境 编程技术交流、源码分享、模板分享、网课分享 企鹅&#x1f427;裙&#xff1a;776871563 摘 要 本毕业设计的内容是设计并且实现一个基于微信小程序批发零售业商品管理系统。它是在Windows下&#xff0c;以MYSQL为数据库开发平台…

Redis-主从与哨兵架构

Jedis使用 Jedis连接代码示例&#xff1a; 1、引入依赖 <dependency><groupId>redis.clients</groupId><artifactId>jedis</artifactId><version>2.9.0</version> </dependency> 2、访问代码 public class JedisSingleTe…

Git仓库瘦身大作战:133M 到 4M 的实战

开局两张图 瘦身前瘦身后 目录 开局两张图前言下载 BFG克隆代码Git 仓库瘦身清理存储库储存库 GC推送仓库 Git 瘦身验证结语开源项目 前言 在进行项目开发的过程中&#xff0c;代码仓库的体积可能会逐渐增大&#xff0c;特别是在版本控制系统中保留了大量的历史提交记录和不必…

统计二叉树中的伪回文路径 : 用位运用来加速??

题目描述 这是 LeetCode 上的 「1457. 二叉树中的伪回文路径」 &#xff0c;难度为 「中等」。 Tag : 「DFS」、「位运算」 给你一棵二叉树&#xff0c;每个节点的值为 1 到 9 。 我们称二叉树中的一条路径是 「伪回文」的&#xff0c;当它满足&#xff1a;路径经过的所有节点值…

使用 STM32F7 和 TensorFlow Lite 开发低功耗人脸识别设备

本文旨在介绍如何使用 STM32F7 和 TensorFlow Lite框架开发低功耗的人脸识别设备。首先&#xff0c;我们将简要介绍 STM32F7 的特点和能力。接下来&#xff0c;我们将讨论如何使用 TensorFlow Lite 在 STM32F7 上实现人脸识别算法。然后&#xff0c;我们将重点关注如何优化系统…

网络数据结构skb_buff原理

skb_buff基本原理 内核中sk_buff结构体在各层协议之间传输不是用拷贝sk_buff结构体&#xff0c;而是通过增加协议头和移动指针来操作的。如果是从L4传输到L2&#xff0c;则是通过往sk_buff结构体中增加该层协议头来操作&#xff1b;如果是从L4到L2&#xff0c;则是通过移动sk_…