[zh] sync /egress/egress-control/ (#13421)

This commit is contained in:
Michael 2023-06-22 20:56:06 +08:00 committed by GitHub
parent 252b9fe252
commit 6660ea2665
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 81 additions and 70 deletions

View File

@ -15,20 +15,20 @@ test: yes
代理配置为允许传递未知服务的请求。尽管这为入门 Istio 带来了方便,但是,通常情况下,
配置更严格的控制是更可取的。
这个任务向展示了三种访问外部服务的方法:
这个任务向展示了三种访问外部服务的方法:
1. 允许 Envoy 代理将请求传递到未在网格内配置过的服务。
1. 配置 [service entry](/zh/docs/reference/config/networking/service-entry/) 以提供对外部服务的受控访问。
1. 配置 [Service Entry](/zh/docs/reference/config/networking/service-entry/) 以提供对外部服务的受控访问。
1. 对于特定范围的 IP完全绕过 Envoy 代理。
## 开始之前 {#before-you-begin}
* 根据[安装指南](/zh/docs/setup/)中的命令设置 Istio。
使用 `demo` [configuration profile](/zh/docs/setup/additional-setup/config-profiles/)或者
使用 `demo` [安装配置文件](/zh/docs/setup/additional-setup/config-profiles/)或者
[启用 Envoy 的访问记录](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)。
* 部署 [sleep]({{< github_tree >}}/samples/sleep) 这个示例应用,用作发送请求的测试源。
如果你启用了[自动注入 sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection),使用以下的命令来部署示例应用:
如果您启用了[自动注入 Sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection),使用以下的命令来部署示例应用:
{{< text bash >}}
$ kubectl apply -f @samples/sleep/sleep.yaml@
@ -44,10 +44,10 @@ test: yes
您可以使用任何安装了 `curl` 的 Pod 作为测试源。
{{< /tip >}}
* 设置环境变量 `SOURCE_POD`,值为的源 Pod 的名称:
* 设置环境变量 `SOURCE_POD`,值为的源 Pod 的名称:
{{< text bash >}}
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath='{.items..metadata.name}')
{{< /text >}}
## Envoy 转发流量到外部服务{#envoy-passthrough-to-external-services}
@ -56,12 +56,12 @@ Istio 有一个[安装选项](/zh/docs/reference/config/installation-options/)
`global.outboundTrafficPolicy.mode`,它配置 Sidecar 对外部服务(那些没有在
Istio 的内部服务注册中定义的服务)的处理方式。如果这个选项设置为 `ALLOW_ANY`
Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_ONLY`,那么 Istio
代理会阻止任何没有在网格中定义的 HTTP 服务或 service entry 的主机。`ALLOW_ANY`
是默认值,不控制对外部服务的访问,方便快速地评估 Istio。
可以稍后再[配置对外部服务的访问](#controlled-access-to-external-services)。
代理会阻止任何没有在网格中定义的 HTTP 服务或 Service Entry 的主机。`ALLOW_ANY`
是默认值,不控制对外部服务的访问,方便快速地评估 Istio。
可以稍后再[配置对外部服务的访问](#controlled-access-to-external-services)。
1. 要查看这种方法的实际效果,需要确保 Istio 的安装配置了 `meshConfig.outboundTrafficPolicy.mode`
选项为 `ALLOW_ANY`。它在默认情况下是开启的,除非在安装 Istio 时显式地将它设置为 `REGISTRY_ONLY`
1. 要查看这种方法的实际效果,需要确保 Istio 的安装配置了 `meshConfig.outboundTrafficPolicy.mode`
选项为 `ALLOW_ANY`。它在默认情况下是开启的,除非在安装 Istio 时显式地将它设置为 `REGISTRY_ONLY`
运行以下命令以确认 `meshConfig.outboundTrafficPolicy.mode` 设置为 `ALLOW_ANY` 或被省略:
@ -70,10 +70,10 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
ALLOW_ANY
{{< /text >}}
您应该看到 `ALLOW_ANY` 或没有任何输出(默认为 `ALLOW_ANY`
您应该看到 `ALLOW_ANY` 或没有任何输出(默认为 `ALLOW_ANY`
{{< tip >}}
如果显式地设置了 `REGISTRY_ONLY` 模式,例如,通过使用更改后的设置重新运行原始的
如果显式地设置了 `REGISTRY_ONLY` 模式,例如,通过使用更改后的设置重新运行原始的
`istioctl install` 命令:
{{< text syntax=bash snip_id=none >}}
@ -81,6 +81,7 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
{{< /text >}}
{{< /tip >}}
1. 从 `SOURCE_POD` 向外部 HTTPS 服务发出两个请求,确保能够得到状态码为 `200` 的响应:
{{< text bash >}}
@ -89,27 +90,27 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
HTTP/2 200
{{< /text >}}
恭喜!你已经成功地从网格中发送了 egress 流量。
恭喜!您已经成功地从网格中发送了 Egress 流量。
这种访问外部服务的简单方法有一个缺点,即丢失了对外部服务流量的 Istio 监控和控制;
比如,外部服务的调用没有记录到 Mixer 的日志中。下一节将介绍如何监控和控制网格对外部服务的访问。
## 控制对外部服务的访问 {#controlled-access-to-external-services}
使用 Istio `ServiceEntry` 配置,可以从 Istio 集群中访问任何公开的服务。
本节将向展示如何在不丢失 Istio 的流量监控和控制特性的情况下,配置对外部 HTTP
服务([httpbin.org](http://httpbin.org)) 和外部 HTTPS 服务([www.google.com](https://www.google.com)
使用 Istio `ServiceEntry` 配置,可以从 Istio 集群中访问任何公开的服务。
本节将向展示如何在不丢失 Istio 的流量监控和控制特性的情况下,配置对外部 HTTP
服务[httpbin.org](http://httpbin.org)和外部 HTTPS 服务([www.google.com](https://www.google.com)
的访问。
### 更改为默认的封锁策略{#change-to-the-blocking-by-default-policy}
### 更改为默认的封锁策略 {#change-to-the-blocking-by-default-policy}
为了演示如何控制对外部服务的访问,需要将 `global.outboundTrafficPolicy.mode`
为了演示如何控制对外部服务的访问,需要将 `global.outboundTrafficPolicy.mode`
选项,从 `ALLOW_ANY` 模式改为 `REGISTRY_ONLY` 模式。
{{< tip >}}
可以向已经在 `ALLOW_ANY` 模式下的可访问服务添加访问控制。
通过这种方式,可以在一些外部服务上使用 Istio 的特性,而不会阻止其他服务。
一旦配置了所有服务,就可以将模式切换到 `REGISTRY_ONLY` 来阻止任何其他无意的访问。
可以向已经在 `ALLOW_ANY` 模式下的可访问服务添加访问控制。
通过这种方式,可以在一些外部服务上使用 Istio 的特性,而不会阻止其他服务。
一旦配置了所有服务,就可以将模式切换到 `REGISTRY_ONLY` 来阻止任何其他无意的访问。
{{< /tip >}}
1. 执行以下命令来将 `global.outboundTrafficPolicy.mode` 选项改为 `REGISTRY_ONLY`
@ -133,22 +134,22 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
1. 从 `SOURCE_POD` 向外部 HTTPS 服务发出几个请求,验证它们现在是否被阻止:
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://www.google.com | grep "HTTP/"; kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://edition.cnn.com | grep "HTTP/"
$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sI https://www.google.com | grep "HTTP/"; kubectl exec "$SOURCE_POD" -c sleep -- curl -sI https://edition.cnn.com | grep "HTTP/"
command terminated with exit code 35
command terminated with exit code 35
{{< /text >}}
{{< warning >}}
配置更改后肯需要一小段时间才能生效,所以你可能仍然可以得到成功地响应。等待若干秒后再重新执行上面的命令。
配置更改后肯定需要一小段时间才能生效,所以您可能仍然可以得到成功的响应。等待若干秒后再重新执行上面的命令。
{{< /warning >}}
### 访问一个外部的 HTTP 服务{#access-an-external-http-service}
### 访问一个外部的 HTTP 服务 {#access-an-external-http-service}
1. 创建一个 `ServiceEntry`,以允许访问一个外部的 HTTP 服务:
{{< warning >}}
`DNS` 解析在下面的服务条目中用作安全措施。将解析设置为 `NONE`开启了攻击的可能。
恶意客户端在真正连接到其他IP时可能会伪装设置 `HOST` 头信息为 `httpbin.org`
`DNS` 解析在下面的服务条目中用作安全措施。将解析设置为 `NONE`出现受到攻击的可能。
恶意客户端在真正连接到其他 IP 时,可能会伪装设置 `HOST` 头信息为 `httpbin.org`
(与 `httpbin.org` 不相关。Istio Sidecar 代理将信任 HOST 头信息,并错误地允许通信,
甚至将其传递到其他主机的 IP 地址。
@ -179,30 +180,30 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
1. 从 `SOURCE_POD` 向外部的 HTTP 服务发出一个请求:
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl http://httpbin.org/headers
$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS http://httpbin.org/headers
{
"headers": {
"Accept": "*/*",
"Connection": "close",
"Host": "httpbin.org",
...
"X-Envoy-Decorator-Operation": "httpbin.org:80/*",
"Accept": "*/*",
"Host": "httpbin.org",
...
"X-Envoy-Decorator-Operation": "httpbin.org:80/*",
...
}
}
{{< /text >}}
注意由 Istio sidecar 代理添加的 headers: `X-Envoy-Decorator-Operation`
注意由 Istio Sidecar 代理添加的头信息:`X-Envoy-Decorator-Operation`
1. 检查 `SOURCE_POD` 的 Sidecar 代理的日志:
{{< text bash >}}
$ kubectl logs $SOURCE_POD -c istio-proxy | tail
$ kubectl logs "$SOURCE_POD" -c istio-proxy | tail
[2019-01-24T12:17:11.640Z] "GET /headers HTTP/1.1" 200 - 0 599 214 214 "-" "curl/7.60.0" "17fde8f7-fa62-9b39-8999-302324e6def2" "httpbin.org" "35.173.6.94:80" outbound|80||httpbin.org - 35.173.6.94:80 172.30.109.82:55314 -
{{< /text >}}
注意与 HTTP 请求相关的 `httpbin.org/headers`.
注意与 HTTP 请求相关的 `httpbin.org/headers`
### 访问外部 HTTPS 服务{#access-an-external-https-service}
### 访问外部 HTTPS 服务 {#access-an-external-https-service}
1. 创建一个 `ServiceEntry`,允许对外部服务的访问。
@ -227,14 +228,14 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
1. 从 `SOURCE_POD` 往外部 HTTPS 服务发送请求:
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://www.google.com | grep "HTTP/"
$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSI https://www.google.com | grep "HTTP/"
HTTP/2 200
{{< /text >}}
1. 检查 `SOURCE_POD` 的 Sidecar 代理的日志:
{{< text bash >}}
$ kubectl logs $SOURCE_POD -c istio-proxy | tail
$ kubectl logs "$SOURCE_POD" -c istio-proxy | tail
[2019-01-24T12:48:54.977Z] "- - -" 0 - 601 17766 1289 - "-" "-" "-" "-" "172.217.161.36:443" outbound|443||www.google.com 172.30.109.82:59480 172.217.161.36:443 172.30.109.82:59478 www.google.com
{{< /text >}}
@ -244,7 +245,7 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
与集群内的请求相似,也可以为使用 `ServiceEntry` 配置访问的外部服务设置
[Istio 路由规则](/zh/docs/concepts/traffic-management/#routing-rules)。
在本示例中,将设置对 `httpbin.org` 服务访问的超时规则。
在本示例中,将设置对 `httpbin.org` 服务访问的超时规则。
1. 从用作测试源的 Pod 内部,向外部服务 `httpbin.org``/delay`
endpoint 发出 **curl** 请求:
@ -252,7 +253,6 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
{{< text bash >}}
$ kubectl exec "$SOURCE_POD" -c sleep -- time curl -o /dev/null -sS -w "%{http_code}\n" http://httpbin.org/delay/5
200
real 0m5.024s
user 0m0.003s
sys 0m0.003s
@ -283,10 +283,8 @@ Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_
1. 几秒后,重新发出 **curl** 请求:
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep sh
$ time curl -o /dev/null -s -w "%{http_code}\n" http://httpbin.org/delay/5
$ kubectl exec "$SOURCE_POD" -c sleep -- time curl -o /dev/null -sS -w "%{http_code}\n" http://httpbin.org/delay/5
504
real 0m3.149s
user 0m0.004s
sys 0m0.004s
@ -304,7 +302,7 @@ $ kubectl delete virtualservice httpbin-ext --ignore-not-found=true
## 直接访问外部服务 {#direct-access-to-external-services}
如果要让特定范围的 IP 完全绕过 Istio则可以配置 Envoy Sidecars
如果要让特定范围的 IP 完全绕过 Istio则可以配置 Envoy Sidecar
以防止它们[拦截](/zh/docs/concepts/traffic-management/)外部请求。要设置绕过
Istio请更改 `global.proxy.includeIPRanges``global.proxy.excludeIPRanges`
[配置参数](https://archive.istio.io/v1.4/docs/reference/config/installation-options/)
@ -315,9 +313,9 @@ Istio请更改 `global.proxy.includeIPRanges` 或 `global.proxy.excludeIPRang
{{< warning >}}
与 [Envoy 转发流量到外部服务](#envoy-passthrough-to-external-services)不同,
后者使用 `ALLOW_ANY` 流量策略来让 Istio sidecar 代理将调用传递给未知服务,
该方法完全绕过了 Sidecar从而实质上禁用了指定 IP 的所有 Istio 功能。不能像
`ALLOW_ANY` 方法那样为特定的目标增量添加 service entry。
后者使用 `ALLOW_ANY` 流量策略来让 Istio Sidecar 代理将调用传递给未知服务,
该方法完全绕过了 Sidecar从而实质上禁用了指定 IP 的所有 Istio 功能。不能像
`ALLOW_ANY` 方法那样为特定的目标增量添加 Service Entry。
因此,仅当出于性能或其他原因无法使用边车配置外部访问时,才建议使用此配置方法。
{{< /warning >}}
@ -326,12 +324,12 @@ Istio请更改 `global.proxy.includeIPRanges` 或 `global.proxy.excludeIPRang
### 确定平台内部的 IP 范围 {#determine-the-internal-IP-ranges-for-your-platform}
根据的集群的提供者,设置参数 `global.proxy.includeIPRanges`
根据的集群的提供者,设置参数 `global.proxy.includeIPRanges`
#### IBM Cloud Private
1. 从 `IBM Cloud Private` 的配置文件 `cluster/config.yaml` 中获取
`service_cluster_ip_range`:
1. 从 `IBM Cloud Private` 的配置文件 `cluster/config.yaml` 中获取
`service_cluster_ip_range`
{{< text bash >}}
$ grep service_cluster_ip_range cluster/config.yaml
@ -347,11 +345,24 @@ Istio请更改 `global.proxy.includeIPRanges` 或 `global.proxy.excludeIPRang
#### IBM Cloud Kubernetes Service
使用 `--set global.proxy.includeIPRanges="172.30.0.0/16\,172.21.0.0/16\,10.10.10.0/24"`
若要查看集群中使用了哪个 CIDR可以使用 `ibmcloud ks cluster get -c <CLUSTER-NAME>` 并查看 `Service Subnet`
{{< text bash >}}
$ ibmcloud ks cluster get -c my-cluster | grep "Service Subnet"
Service Subnet: 172.21.0.0/16
{{< /text >}}
然后使用 `--set values.global.proxy.includeIPRanges="172.21.0.0/16"`
{{< warning >}}
在非常旧的集群上,这可能无法正常工作,因此您可以使用
`--set values.global.proxy.includeIPRanges="172.30.0.0/16,172.21.0.0/16,10.10.10.0/24"`
或使用 `kubectl get svc -o wide -A` 进一步缩小设置的 CIDR 值。
{{< /warning >}}
#### Google Kubernetes Engine (GKE)
范围是不固定的,你需要运行 `gcloud container clusters describe` 命令来确定要使用的范围。
范围是不固定的,需要运行 `gcloud container clusters describe` 命令来确定要使用的范围。
举个例子:
{{< text bash >}}
@ -380,7 +391,7 @@ $ kubectl describe pod kube-apiserver -n kube-system | grep 'service-cluster-ip-
### 配置代理绕行 {#configuring-the-proxy-bypass}
{{< warning >}}
删除本指南中先前部署的 service entry 和 virtual service。
删除本指南中先前部署的 Service Entry 和 Virtual Service。
{{< /warning >}}
使用平台的 IP 范围更新 `istio-sidecar-injector` 的配置。比如,如果 IP 范围是
@ -390,15 +401,15 @@ $ kubectl describe pod kube-apiserver -n kube-system | grep 'service-cluster-ip-
$ istioctl install <flags-you-used-to-install-Istio> --set values.global.proxy.includeIPRanges="10.0.0.1/24"
{{< /text >}}
[安装 Istio](/zh/docs/setup/install/istioctl) 命令的基础上增加
`--set values.global.proxy.includeIPRanges="10.0.0.1/24"`
在[安装 Istio](/zh/docs/setup/install/istioctl) 命令的基础上增加
`--set values.global.proxy.includeIPRanges="10.0.0.1/24"`
### 访问外部服务 {#access-the-external-services}
由于绕行配置仅影响新的部署,因此您需要按照[开始之前](#before-you-begin)部分中的说明重新部署 `sleep` 程序。
在更新 `istio-sidecar-injector` configmap 和重新部署 `sleep` 程序后,
Istio sidecar 将仅拦截和管理集群中的内部请求。任何外部请求都会绕过 Sidecar
Istio Sidecar 将仅拦截和管理集群中的内部请求。任何外部请求都会绕过 Sidecar
并直接到达其预期的目的地。举个例子:
{{< text bash >}}
@ -412,13 +423,13 @@ $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS http://httpbin.org/headers
}
{{< /text >}}
与通过 HTTP 和 HTTPS 访问外部服务不同,不会看到任何与 Istio Sidecar 有关的请求头,
与通过 HTTP 和 HTTPS 访问外部服务不同,不会看到任何与 Istio Sidecar 有关的请求头,
并且发送到外部服务的请求既不会出现在 Sidecar 的日志中,也不会出现在 Mixer 日志中。
绕过 Istio Sidecar 意味着不能再监视对外部服务的访问。
绕过 Istio Sidecar 意味着不能再监视对外部服务的访问。
### 清除对外部服务的直接访问{#cleanup-the-direct-access-to-external-services}
### 清除对外部服务的直接访问 {#cleanup-the-direct-access-to-external-services}
更新配置,以针对各种 IP 停止绕过 sidecar 代理:
更新配置,以针对各种 IP 停止绕过 Sidecar 代理:
{{< text syntax=bash snip_id=none >}}
$ istioctl install <flags-you-used-to-install-Istio>
@ -430,21 +441,21 @@ $ istioctl install <flags-you-used-to-install-Istio>
1. 配置 Envoy 以允许访问任何外部服务。
1. 使用 service entry 将一个可访问的外部服务注册到网格中。这是推荐的方法。
1. 使用 Service Entry 将一个可访问的外部服务注册到网格中。这是推荐的方法。
1. 配置 Istio Sidecar 以从其重新映射的 IP 表中排除外部 IP。
第一种方法通过 Istio Sidecar 代理来引导流量,包括对网格内部未知服务的调用。使用这种方法时,
将无法监控对外部服务的访问或无法利用 Istio 的流量控制功能。
要轻松为特定的服务切换到第二种方法,只需为那些外部服务创建 service entry 即可。
此过程使可以先访问任何外部服务,然后再根据需要决定是否启用控制访问、流量监控、流量控制等功能。
将无法监控对外部服务的访问或无法利用 Istio 的流量控制功能。
要轻松为特定的服务切换到第二种方法,只需为那些外部服务创建 Service Entry 即可。
此过程使可以先访问任何外部服务,然后再根据需要决定是否启用控制访问、流量监控、流量控制等功能。
第二种方法可以让使用 Istio 服务网格所有的功能区调用集群内或集群外的服务。
在此任务中,学习了如何监控对外部服务的访问并设置对外部服务的调用的超时规则。
第二种方法可以让使用 Istio 服务网格所有的功能区调用集群内或集群外的服务。
在此任务中,学习了如何监控对外部服务的访问并设置对外部服务的调用的超时规则。
第三种方法绕过了 Istio Sidecar 代理,使的服务可以直接访问任意的外部服务。
第三种方法绕过了 Istio Sidecar 代理,使的服务可以直接访问任意的外部服务。
但是,以这种方式配置代理需要了解集群提供商相关知识和配置。
与第一种方法类似,也将失去对外部服务访问的监控,并且无法将 Istio 功能应用于外部服务的流量。
与第一种方法类似,也将失去对外部服务访问的监控,并且无法将 Istio 功能应用于外部服务的流量。
## 安全说明 {#security-note}
@ -453,7 +464,7 @@ $ istioctl install <flags-you-used-to-install-Istio>
恶意程序可以绕过 Istio Sidecar 代理并在没有 Istio 控制的情况下访问任何外部服务。
{{< /warning >}}
为了以更安全的方式实施出口流量控制,你必须[通过 egress gateway 引导出口流量](/zh/docs/tasks/traffic-management/egress/egress-gateway/)
为了以更安全的方式实施出口流量控制,您必须[通过 Egress Gateway 引导出口流量](/zh/docs/tasks/traffic-management/egress/egress-gateway/)
并查看[其他安全注意事项](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)部分中描述的安全问题。
## 清理 {#cleanup}