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)" 的輸出內容：
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["# Resolving security issues in Cloud Service Mesh\n===============================================\n\n| **Note:** This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nThis section explains common Cloud Service Mesh with Istio APIs problems and\nhow to resolve them. If you need additional assistance, see\n[Getting support](/service-mesh/v1.23/docs/getting-support).\n\nIn Cloud Service Mesh, Cloud Service Mesh certificate authority or Istiod issues certificates to\nworkloads across all clusters in the mesh. Authentication (mTLS for example) and\nAuthorization policies (allow/deny for example) are pushed to each cluster.\nThese policies determine which workloads can communicate and how.\n\nTLS Issues\n----------\n\nThe following sections explain how to resolve TLS-related problems in\nCloud Service Mesh.\n\nThe examples in this section use the variable `${CTX}`, which is the context\nname in the\n[default Kubernetes configuration file](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)\nthat you use to access the cluster. Set the `${CTX}` variable like the following example: \n\n```\nexport CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME\n```\n\n### Verify TLS enforcement\n\nVerify that plain-text requests are disallowed for a service, when the service\nrequires TLS connections: \n\n```\nkubectl exec SOURCE_POD -n SOURCE_NAMESPACE -c \\\n SOURCE_CONTAINER -- curl -v DESTINATION_URL\n```\n\nAssuming the service requires TLS connections, the preceding plain-text request\nshould fail, resulting in output similar to the following: \n\n```\ncurl: (56) Recv failure: Connection reset by peer command terminated with exit code 56\n```\n\n### Check mTLS certificates\n\nWhen mTLS is enabled, check the workload's mTLS certificate by viewing\nthe `X-Forwarded-Client-Cert` header. To do this, use the following steps:\n\n1. Deploy the `httpbin` sample service, which can display the headers that it\n receives.\n\n2. Use `curl` to view the `X-Forwarded-Client-Cert` header:\n\n ```\n kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c \\\n SOURCE_CONTAINER -- curl http://httpbin.sample:8000/headers -s | \\\n grep X-Forwarded-Client-Cert\n ```\n\n The `X-Forwarded-Client-Cert` header shows the mTLS certificates information, like the following example: \n\n ```\n 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\n ```\n3. Alternatively, use `openssl` on the sidecar to view the entire certificate chain:\n\n ```\n kubectl debug --image istio/base --target istio-proxy -it --context=${CTX} SOURCE_POD \\\n -n SOURCE_NAMESPACE -- openssl s_client -alpn istio -showcerts -connect httpbin.sample:8000\n ```\n\n The output will display the certificate chain. If you are using Mesh CA, verify\n the root certificate CN contains `istio_v1_cloud_workload_root-signer-...`. If\n you are using Istiod as the certificate authority, verify that the root\n certificate is set with `O = \u003cvar\u003eYOUR_TRUST_DOMAIN\u003c/var\u003e`.\n\n### TLS `bad certificate` errors in the Istiod logs\n\nIf you see TLS handshake `bad certificate` errors in the logs, it might indicate\nthat Istiod is failing to establish a TLS connection to a service.\n\nYou can use the regular expression string `TLS handshake error.*bad certificate`\nto find these errors in the logs.\n\nThese errors are usually informational and transient. However, if they persist,\nthey might indicate a problem in your system.\n\n1. Verify that your `istio-sidecar-injector` `MutatingWebhookConfiguration` has a CA bundle.\n\n The sidecar injector webhook (which is used for automatic sidecar injection)\n requires a CA bundle to establish secure connections with the API server and\n Istiod. This CA bundle is patched into the configuration by istiod, but can\n sometimes be overwritten (for example, if you reapply the webhook\n configuration).\n2. Verify the presence of the CA bundle:\n\n **Note:** If you have installed more than one control plane, then specify a specific revision. \n\n ```\n kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'\n ```\n\n If the output is not empty, the CA bundle is configured. If the CA bundle is\n missing, restart `istiod` to cause it to rescan the webhook and reinstall\n the CA bundle.\n\nAuthorization policy denial logging\n-----------------------------------\n\nFor information about authorization policy denial logging, see\n[Denial logging](/service-mesh/v1.23/docs/security/authorization-advanced-features#denial_logging).\n\nAuthorization policies are not enforced\n---------------------------------------\n\nIf you observe symptoms of authorization policies not being enforced, use the\nfollowing command to verify them: \n\n```\nkubectl exec --context=${CTX} -it SOURCE_POD -n SOURCE_NAMESPACE \\\n -c SOURCE_CONTAINER -- curl DESTINATION_URL\n```\n\nIn the output, `access denied` messages indicate that authorization policies are\nproperly enforced, like the following: \n\n```\nRBAC: access denied\n```\n\nIf you confirm that authorization policies are not enforced, deny access to the\nnamespace. The following example denies access to the namespace named `authz-ns`: \n\n```\nkubectl apply --context=${CTX} -f - \u003c\u003cEOF\napiVersion: security.istio.io/v1beta1\nkind: AuthorizationPolicy\nmetadata:\n name: deny-authz-ns\n namespace: authz-ns\nspec:\n {}\nEOF\n```\n\n'customresourcedefinitions.apiextensions.k8s.io is forbidden' error in Istiod logs\n----------------------------------------------------------------------------------\n\nYou might see errors similar to the following:\n\n\u003cbr /\u003e\n\n```\nerror 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\n```\n\n\u003cbr /\u003e\n\nYou can use the regular expression string `/error.*cannot list resource/` to\nfind these errors in the logs.\n\nThis error can occur when your Istiod deployment lacks the correct IAM binding\nor has insufficient RBAC permissions to read a custom resource.\n\n1. Check if you are missing an IAM binding in your account. First, ensure you\n have correctly\n [set credentials and permissions](/service-mesh/v1.23/docs/unified-install/install-dependent-tools#grant_cluster_admin_permissions).\n Then, check that the IAM binding is present using the following command. In\n this example, PROJECT_ID is the output of `gcloud config get-value project` and\n PROJECT_NUMBER is the output of `gcloud projects list --filter=\"project_id=${PROJECT_ID}\" --format=\"value(project_number)\"`:\n\n ```\n gcloud projects add-iam-policy-binding ${PROJECT_ID} --member \"serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-meshdataplane.iam.gserviceaccount.com\" --role \"roles/meshdataplane.serviceAgent\"\n ```\n2. Check that your RBAC rules are installed correctly.\n\n3. If the RBAC rules are missing, rerun\n [`asmcli install`](/service-mesh/v1.23/docs/unified-install/install-anthos-service-mesh)\n to recreate them.\n\n4. If the RBAC rules are present and the errors persist, check that the\n `ClusterRoleBindings` and `RoleBindings` are attaching the RBAC rules to the\n correct kubernetes Service Account. Also, verify that your istiod deployment is\n using the specified service account.\n\n`serverca` process errors in Istiod logs\n----------------------------------------\n\nYou might see errors similar to the following: \n\n```\nAuthentication failed: Authenticator ClientCertAuthenticator at index 0 got error\n```\n\nYou can use the regular expression string `/serverca.*Authentication failed:.*JWT/` to\nfind these errors in the logs.\n\nThis error can occur when the JWT issuer is misconfigured, a client is using an\nexpired token, or some other security issue is preventing a connection from\nauthenticating to istiod correctly."]]
