Anthos Service Mesh 1.8 已达到服务终止期限，不再受支持。请参阅从早期版本升级。

查看最新文档或选择其他可用版本：

可用版本

解决 Anthos Service Mesh 中的安全问题

本部分介绍常见的 Anthos Service Mesh 问题以及如何解决这些问题。如果您需要其他帮助，请参阅获取支持。

在 Anthos Service Mesh 中，Mesh CA 或 Istiod 向网格中所有集群的工作负载颁发证书。身份验证（例如 mTLS）和授权政策（例如允许/拒绝）将被推送到每个集群。这些政策决定了哪些工作负载可以通信以及如何通信。

TLS 问题

以下部分介绍了如何解决 Anthos Service Mesh 中与 TLS 相关的问题。

本部分中的示例使用变量 ${CTX}，此变量是用于访问集群的默认 Kubernetes 配置文件的上下文名称。设置 ${CTX} 变量，如下例所示：

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

验证传输层安全协议 (TLS) 是否强制执行

在服务需要使用 TLS 连接时，验证服务是否不允许使用纯文本请求：

kubectl exec SOURCE_POD -n SOURCE_NAMESPACE -c \
    SOURCE_CONTAINER -- curl -v DESTINATION_URL

假设服务需要 TLS 连接，则上述纯文本请求应失败，从而产生如下所示的输出：

curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56

检查 mTLS 证书

启用 mTLS 时，查看 X-Forwarded-Client-Cert 标头，检查工作负载的 mTLS 证书。为此，请执行以下步骤：

部署 httpbin 示例服务，它可以显示它收到的标头。

使用 curl 查看 X-Forwarded-Client-Cert 标头：

kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c \
SOURCE_CONTAINER -- curl http://httpbin.sample:8000/headers -s | \
grep X-Forwarded-Client-Cert

X-Forwarded-Client-Cert 标头显示 mTLS 证书信息，如以下示例所示：

X-Forwarded-Client-Cert": "By=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/httpbin;Hash=0781d68adfdab85b08b6758ed502f352464e81166f065cc6acde9433337b4494;Subject=\"OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US\";URI=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/sleep

您也可以在 Sidecar 上使用 openssl 来查看完整证书链：
```
kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c istio-proxy \
openssl s_client -alpn istio -showcerts -connect httpbin.sample:8000
```
输出将显示证书链。如果您使用的是 Mesh CA，请验证根证书 CN 是否包含 istio_v1_cloud_workload_root-signer-...。如果您将 Istiod 用作证书授权机构，请验证根证书是否设置为 O = <var>YOUR_TRUST_DOMAIN</var>。

Istiod 日志中的 TLS `bad certificate` 错误

如果您在日志中看到 TLS 握手 bad certificate 错误，则说明 Istiod 可能无法与服务建立 TLS 连接。

您可以使用正则表达式字符串 TLS handshake error.*bad certificate 在日志中查找这些错误。

这些错误通常用于显示信息并且是暂时性的。不过，如果它们持续存在，则说明您的系统可能存在问题。

验证您的 istio-sidecar-injector MutatingWebhookConfiguration 是否具有 CA 软件包。

Sidecar 注入器 Webhook（用于自动执行 Sidecar 注入）需要使用 CA 软件包，以便与 API 服务器和 Istiod 建立安全连接。此 CA 软件包由 Istiod 修补到配置中，但有时可能会被覆盖（例如，如果您重新应用 Webhook 配置）。
验证 CA 软件包是否存在：
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
```
如果输出不为空，则说明 CA 软件包已配置。如果缺少 CA 软件包，请重启 istiod 以使其重新扫描 Webhook 并重新安装 CA 软件包。

授权政策拒绝日志记录

如果政策不允许，则授权政策会拒绝请求。对于 HTTP（包括 gRPC）协议，请求将被拒绝并显示状态代码 403。对于非 HTTP 协议，连接将直接终止。如需详细了解授权政策，请参阅 Istio 授权。

当请求被授权政策拒绝时，Google Cloud 可观测性访问日志会包含必要的信息，这在某些情况下会很有用。例如，日志会指示授权政策所拒绝的请求数，这有助于您确定哪个政策规则导致了后端应用出现拒绝事件。

Google Cloud 可观测性访问日志包含以下表示授权遭拒的标签。

response_details：如果拒绝是由授权政策导致的，则将设置为 AuthzDenied。
policy_name：将包括导致拒绝的授权 DENY 政策的命名空间和名称。该值的格式为 <Namespace>.<Name>，例如 foo.deny-method-get 表示 foo 命名空间中的授权政策 deny-method-get。
policy_rule：将包括导致拒绝的授权政策内规则的索引，例如 0 表示政策中的第一条规则。

如需详细了解如何获取访问日志，请参阅访问 Cloud Logging 中的日志。

授权政策未强制执行

如果您发现授权政策未强制执行，请使用以下命令进行验证：

kubectl exec --context=${CTX} -it SOURCE_POD -n SOURCE_NAMESPACE \
    -c SOURCE_CONTAINER -- curl DESTINATION_URL

在输出中，access denied 消息表示授权政策已正确执行，如下所示：

RBAC: access denied

如果确认授权政策未强制执行，则系统会拒绝访问命名空间。以下示例拒绝访问名为 authz-ns 的命名空间：

kubectl apply --context=${CTX} -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-authz-ns
  namespace: authz-ns
spec:
  {}
EOF

Istiod 日志中的“customresourcedefinitions.apiextensions.k8s.io is forbidden”错误

您可能会看到类似于以下内容的错误：

error failed to list CRDs: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "system:serviceaccount:istio-system:istiod-service-account" cannot list resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope

您可以使用正则表达式字符串 /error.*cannot list resource/ 在日志中查找这些错误。

如果您的 Istiod 部署缺少正确的 IAM 绑定，或者 RBAC 权限不足，无法读取自定义资源，则可能会出现此错误。

检查您的账号中是否缺少 IAM 绑定。首先，请确保您已正确设置凭据和权限。然后，使用以下命令检查是否存在 IAM 绑定。在以下示例中，PROJECT_ID 是 gcloud config get-value project 的输出，PROJECT_NUMBER 是 gcloud projects list --filter="project_id=${PROJECT_ID}" --format="value(project_number)" 的输出：
```
gcloud projects add-iam-policy-binding ${PROJECT_ID} --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-meshdataplane.iam.gserviceaccount.com" --role "roles/meshdataplane.serviceAgent"
```
检查您的 RBAC 规则是否已正确安装。
如果缺少 RBAC 规则，请重新运行 istioctl install（或您用于安装 Anthos Service Mesh 的安装方法）以重新创建这些规则。
如果存在 RBAC 规则并且错误仍然存在，请检查 ClusterRoleBindings 和 RoleBindings 是否将 RBAC 规则附加到正确的 Kubernetes 服务账号。此外，请验证您的 Istiod 部署使用的是否是指定的服务账号。

Istiod 日志中的 `serverca` 进程错误