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

Update the health check section with mTLS for 1.1 (#3738) 

* Update the health check section with mTLS

* Update k8s-health-checks.md

* Fix lint

* Update content/help/faq/security/k8s-health-checks.md
This commit is contained in:
Tao Li 2019-03-19 10:34:21 -07:00 committed by Martin Taillefer
parent 2ed74c33f8
commit 493c1ff1df
1 changed files with 8 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
content/help/faq/security/k8s-health-checks.md
View File

@ -2,24 +2,18 @@
title: How can I use Kubernetes liveness and readiness for pod health checks when mutual TLS is enabled? title: How can I use Kubernetes liveness and readiness for pod health checks when mutual TLS is enabled?
weight: 50 weight: 50
--- ---
If mutual TLS is enabled, http and tcp health checks from the kubelet will
not work since the kubelet does not have Istio-issued certificates.
As of the Istio 1.0 release, we support the [`PERMISSIVE` mode](/docs/tasks/security/mtls-migration) If mutual TLS is enabled, HTTP and TCP health checks from the kubelet will not work without modification, since the kubelet does not have Istio-issued certificates.
for Istio services so they can accept both http and mutual TLS traffic
when this mode is turned on. This can solve the health checking issue.
Please keep in mind that mutual TLS is not enforced since others can
communicate with the service with http traffic.
You can use a separate port for health checks and enable mutual TLS only As of Istio 1.1, we have several options to solve this issue.
on the regular service port. Refer to [Health Checking of Istio Services](/help/ops/setup/app-health-check/)
for more information.
Due to the risk of a new feature, we do not turn on above feature by default. The future rollout 1. Using probe rewrite to rewrite the liveness/readiness probe such that the probe request will be redirected to the workload directly. Please refer to [Probe Rewrite](/help/ops/setup/app-health-check/#probe-rewrite) for more information.
plan is tracked on [GitHub issue](https://github.com/istio/istio/issues/10357).
To mitigate the risk, another workaround is to use a [liveness command](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command) 1. Using a separate port for health checks and enabling mutual TLS only on the regular service port. Please refer to [Health Checking of Istio Services](/help/ops/setup/app-health-check/#separate-port) for more information.
for health checks, e.g., one can install `curl` in the service pod and
1. Using the [`PERMISSIVE` mode](/docs/tasks/security/mtls-migration) for Istio services so they can accept both HTTP and mutual TLS traffic. Please keep in mind that mutual TLS is not enforced since others can communicate with the service with HTTP traffic.
1. Using a [liveness command](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command) for health checks, e.g., one can install `curl` in the service pod and
`curl` itself within the pod. `curl` itself within the pod.
An example of a readiness probe: An example of a readiness probe: