Anthos Service Mesh 1.8 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

利用可能なバージョン

Anthos Service Mesh でのセキュリティの問題の解決

このセクションでは、Anthos Service Mesh の一般的な問題とその解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。

Anthos Service Mesh では、Mesh CA または Istiod がメッシュ内のすべてのクラスタのワークロードに証明書を発行します。認証（例: mTLS）と認可ポリシー（例: allow/deny）が各クラスタに push されます。これらのポリシーにより、通信可能なワークロードとその方法が決まります。

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

また、サイドカーで 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 handshake bad certificate エラーが記録されている場合、Istiod がサービスへの TLS 接続を確立に失敗していることを示している可能性があります。

ログ内の正規表現文字列 TLS handshake error.*bad certificate を使用して、これらのエラーを見つけることができます。

通常、こうしたエラーは情報提供を目的としたもので、一時的なものです。エラーの出現が続く場合は、システムに問題があることを示している可能性があります。

istio-sidecar-injector MutatingWebhookConfiguration に CA バンドルがあることを確認してください。

自動サイドカーインジェクションに使用されるサイドカーインジェクタ Webhook には、API サーバーと Istiod との安全な接続を確立するために CA バンドルが必要です。この CA バンドルは istiod によって構成にパッチが適用されていますが、上書きされる（Webhook 構成を再適用した場合など）可能性があります。
CA バンドルが存在することを確認します。
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
```
出力が空でない場合、CA バンドルが構成されます。CA バンドルがない場合は、Webhook を再スキャンし、CA バンドルを再インストールできるように istiod を再起動します。

認証ポリシーの拒否ロギング

ポリシーによってリクエストが許可されていない場合、認証ポリシーがリクエストを拒否します。HTTP（gRPC を含む）プロトコルの場合、リクエストはステータスコード 403 で拒否されます。HTTP 以外のプロトコルの場合は、接続は直接終了します。認証ポリシーの詳細については、Istio の認証をご覧ください。

Google Cloud Observability アクセスログには、認証ポリシーによってリクエストが拒否された場合に必要な情報が含まれています。この情報は、状況によって役立つ場合があります。たとえば、このログは認証ポリシーによって拒否されたリクエストの数を示します。これにより、バックエンドアプリケーションからの拒否の原因となったポリシールールを特定できます。

Google Cloud Observability アクセスログには、認証拒否に関する次のラベルが含まれます。

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 の Deployment に適切な 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 が適切な Kubernetes サービスアカウントに対して RBAC ルールを接続していることを確認します。また、istiod デプロイメントが指定されたサービスアカウントを使用していることも確認してください。

Istiod ログの `serverca` プロセスエラー