apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
istio:
global:
mtls:
enabled: true
您正在查看 Red Hat OpenShift Service Mesh 版本的文档,该版本不再受支持。 Service Mesh 版本 1.0 和 1.1 控制平面不再受支持。有关升级服务网格控制平面的信息,请参阅 升级服务网格。 有关特定 Red Hat OpenShift Service Mesh 版本的支持状态信息,请参阅 产品生命周期页面。 |
如果您的服务网格应用程序由复杂的微服务数组构成,您可以使用 Red Hat OpenShift Service Mesh 来自定义这些服务之间通信的安全性。OpenShift Container Platform 的基础架构以及 Service Mesh 的流量管理功能可以帮助您管理应用程序的复杂性,并为微服务提供服务和身份安全性。
双向传输层安全 (mTLS) 是一种协议,其中双方相互验证身份。它是某些协议 (IKE、SSH) 中的默认身份验证模式,而在其他协议 (TLS) 中则为可选。
无需更改应用程序或服务代码即可使用 mTLS。TLS 完全由服务网格基础架构和两个 sidecar 代理之间处理。
默认情况下,Red Hat OpenShift Service Mesh 设置为宽松模式,其中 Service Mesh 中的 sidecar 既接受纯文本流量,也接受使用 mTLS 加密的连接。如果网格中的服务与网格外部的服务通信,则严格的 mTLS 可能会中断这些服务之间的通信。在将工作负载迁移到 Service Mesh 时,请使用宽松模式。
如果您的工作负载不与网格外部的服务通信,并且仅接受加密连接不会中断通信,则可以快速在网格中启用 mTLS。在您的 `ServiceMeshControlPlane` 资源中将 `spec.istio.global.mtls.enabled` 设置为 `true`。操作员将创建所需的资源。
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
istio:
global:
mtls:
enabled: true
创建一个目标规则以配置 Service Mesh 在向网格中的其他服务发送请求时使用 mTLS。
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "default"
namespace: <CONTROL_PLANE_NAMESPACE>>
spec:
host: "*.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
如果您的环境对服务网格中的加密流量有特定要求,您可以通过在 `ServiceMeshControlPlane` 资源中设置 `spec.security.controlPlane.tls.minProtocolVersion` 或 `spec.security.controlPlane.tls.maxProtocolVersion` 来控制允许的加密功能。在您的控制平面资源中配置的这些值定义了网格组件在通过 TLS 安全通信时使用的最小和最大 TLS 版本。
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
istio:
global:
tls:
minProtocolVersion: TLSv1_2
maxProtocolVersion: TLSv1_3
默认为 `TLS_AUTO`,并且未指定 TLS 版本。
值 | 描述 |
---|---|
|
默认 |
|
TLS 版本 1.0 |
|
TLS 版本 1.1 |
|
TLS 版本 1.2 |
|
TLS 版本 1.3 |
密码套件和椭圆曲线 Diffie-Hellman (ECDH 曲线) 可以帮助您保护服务网格的安全。您可以使用 `ServiceMeshControlPlane` 资源中的 `spec.istio.global.tls.cipherSuites` 定义密码套件的逗号分隔列表,并使用 `spec.istio.global.tls.ecdhCurves` 定义 ECDH 曲线。如果这两个属性为空,则使用默认值。
如果您的服务网格使用 TLS 1.2 或更早版本,则 `cipherSuites` 设置有效。在与 TLS 1.3 协商时,它无效。
按照优先级顺序,以逗号分隔列表的形式设置您的密码套件。例如,ecdhCurves: CurveP256, CurveP384
将 CurveP256
设置为比 CurveP384
更高的优先级。
配置密码套件时,必须包含 |
支持的密码套件为:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
支持的 ECDH 曲线为:
CurveP256
CurveP384
CurveP521
X25519
默认情况下,Red Hat OpenShift Service Mesh 生成自签名根证书和密钥,并使用它们来签署工作负载证书。您也可以使用用户定义的证书和密钥来签署工作负载证书,使用用户定义的根证书。此任务演示了一个将证书和密钥插入 Service Mesh 的示例。
您必须已安装启用双向 TLS 的 Red Hat OpenShift Service Mesh 才能配置证书。
此示例使用来自 Maistra 仓库 的证书。对于生产环境,请使用您自己的证书颁发机构的证书。
您必须部署 Bookinfo 示例应用程序才能使用这些说明验证结果。
要使用现有的签名 (CA) 证书和密钥,您必须创建一个信任链文件,其中包含 CA 证书、密钥和根证书。您必须为每个相应的证书使用以下确切的文件名。CA 证书称为 ca-cert.pem
,密钥为 ca-key.pem
,签署 ca-cert.pem
的根证书称为 root-cert.pem
。如果您的工作负载使用中间证书,则必须在 cert-chain.pem
文件中指定它们。
按照以下步骤将证书添加到 Service Mesh。将 Maistra 仓库 中的示例证书保存到本地,并将 <path>
替换为您证书的路径。
创建一个包含输入文件 ca-cert.pem
、ca-key.pem
、root-cert.pem
和 cert-chain.pem
的密钥 cacert
。
$ oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \
--from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \
--from-file=<path>/cert-chain.pem
在 ServiceMeshControlPlane
资源中,将 global.mtls.enabled
设置为 true
,并将 security.selfSigned
设置为 false
。Service Mesh 从密钥挂载文件读取证书和密钥。
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
istio:
global:
mtls:
enabled: true
security:
selfSigned: false
为了确保工作负载立即添加新证书,请删除 Service Mesh 生成的名为 istio.*
的密钥。在此示例中,为 istio.default
。Service Mesh 将为工作负载颁发新证书。
$ oc delete secret istio.default
使用 Bookinfo 示例应用程序验证您的证书是否已正确安装。首先,检索已安装的证书。然后,验证安装在 Pod 上的证书。
将 Pod 名称存储在变量 RATINGSPOD
中。
$ RATINGSPOD=`oc get pods -l app=ratings -o jsonpath='{.items[0].metadata.name}'`
运行以下命令以检索安装在代理上的证书。
$ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/root-cert.pem > /tmp/pod-root-cert.pem
/tmp/pod-root-cert.pem
文件包含传播到 Pod 的根证书。
$ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/cert-chain.pem > /tmp/pod-cert-chain.pem
/tmp/pod-cert-chain.pem
文件包含传播到 Pod 的工作负载证书和 CA 证书。
验证根证书与操作员指定的证书相同。将 <path>
替换为您证书的路径。
$ openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt
$ openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt
$ diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
预期输出为空。
验证 CA 证书与操作员指定的证书相同。将 <path>
替换为您证书的路径。
$ sed '0,/^-----END CERTIFICATE-----/d' /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-ca.pem
$ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
$ openssl x509 -in /tmp/pod-cert-chain-ca.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
$ diff /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt
预期输出为空。
验证从根证书到工作负载证书的证书链。将 <path>
替换为您证书的路径。
$ head -n 21 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-workload.pem
$ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) /tmp/pod-cert-chain-workload.pem
/tmp/pod-cert-chain-workload.pem: OK