istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add IST0161 message description (#13068) 

* add IST0161 message description

* fix lint

* fix lint

* Update content/en/docs/reference/config/analysis/ist0161/index.md

Co-authored-by: Eric Van Norman <ericvn@us.ibm.com>

---------

Co-authored-by: Eric Van Norman <ericvn@us.ibm.com>
This commit is contained in:
Xiaopeng Han 2023-05-12 05:05:57 +08:00 committed by GitHub
parent 01f098ddc8
commit 6656933a5f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 28 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
content/en/docs/reference/config/analysis/ist0161/index.md Normal file
View File

@ -0,0 +1,28 @@
---
title: InvalidGatewayCredential
layout: analysis-message
owner: istio/wg-user-experience-maintainers
test: n/a
---
The `InvalidGatewayCredential` message occurs when a Gateway resource references a secret for its TLS configuration, but the secret is either not found or contains an invalid TLS certificate. This message helps identify issues with the TLS configuration of a Gateway resource, which may lead to insecure or non-functional connections.
This message is generated when the following conditions are met:
1. A Gateway resource has a server with a TLS configuration.
1. The TLS configuration references a `credentialName`.
1. The secret with the specified `credentialName` is either not found, or the secret is found but the TLS certificate is invalid.
To resolve this issue, ensure that the secret with the specified `credentialName` exists in the same namespace as the Gateway workload, and that the secret contains a valid TLS certificate. You may need to create or update the secret to fix the problem.
If the secret is missing, create a new secret with the correct TLS certificate and private key. For example, using `kubectl`:
{{< text bash >}}
$ kubectl create secret tls my-tls-secret --cert=path/to/cert.pem --key=path/to/key.pem -n <namespace>
{{< /text >}}
Make sure to replace `<namespace>` with the actual namespace where the Gateway workload is running, and update the file paths to point to the correct certificate and key files.
If the secret is found but the TLS certificate is invalid, update the secret with the correct TLS certificate and private key.