update for istio users why gloo (#7206)

* update for istio users why gloo

* Copy edits and implement Jed's suggestions

Co-authored-by: Adam Miller <1402860+adammil2000@users.noreply.github.com>
This commit is contained in:
Christian Posta 2020-05-15 11:47:45 -07:00 committed by GitHub
parent 5b20fc424c
commit 17ca874313
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions

View File

@ -7,7 +7,7 @@ attribution: "Christian Posta (Solo.io)"
keywords: [istio, sds, mTLS, edge, ingress, gloo, solo.io]
---
[Gloo is an open-source API Gateway](https://docs.solo.io/gloo/latest/) built on Envoy Proxy that highly complements a service mesh like Istio with edge capabilities like [request/response transformations](https://docs.solo.io/gloo/latest/guides/traffic_management/request_processing/transformations/), [direct-response actions](https://docs.solo.io/gloo/latest/guides/traffic_management/request_processing/direct_response_action/), and [Open API Spec/Swagger and gRPC discovery](https://docs.solo.io/gloo/latest/installation/advanced_configuration/fds_mode/). [Gloo Enterprise](https://www.solo.io/products/gloo/) supports more sophisticated security edge requirements like [OIDC authentication](https://docs.solo.io/gloo/latest/guides/security/auth/oauth/), [OPA authorization](https://docs.solo.io/gloo/latest/guides/security/auth/opa/), [Web Application Fire walling (WAF)](https://docs.solo.io/gloo/latest/guides/security/waf/), rate limiting and others. A lot of Gloo users put Gloo at the edge and [integrate with Istio for east-west traffic management](https://www.solo.io/blog/using-gloo-as-an-ingress-gateway-with-istio-and-mtls-updated-for-istio-1-1/).
[Gloo is an open-source API Gateway](https://docs.solo.io/gloo/latest/) built on Envoy Proxy that highly complements a service mesh like Istio with edge capabilities, such as [request/response transformations](https://docs.solo.io/gloo/latest/guides/traffic_management/request_processing/transformations/), [direct-response actions](https://docs.solo.io/gloo/latest/guides/traffic_management/request_processing/direct_response_action/), and [Open API Spec/Swagger and gRPC discovery](https://docs.solo.io/gloo/latest/installation/advanced_configuration/fds_mode/). This benefits you by having API Gateway capabilities at the edge of your mesh (or multiple clusters of a mesh) without manually adding support for this into the Istio ingress gateway using Lua, etc. [Gloo Enterprise](https://www.solo.io/products/gloo/) supports more sophisticated security edge requirements, such as [OIDC authentication](https://docs.solo.io/gloo/latest/guides/security/auth/oauth/), [OPA authorization](https://docs.solo.io/gloo/latest/guides/security/auth/opa/), [Web Application Fire walling (WAF)](https://docs.solo.io/gloo/latest/guides/security/waf/), rate limiting and others. There is also a custom-auth framework for building your own edge security protocols (common ones like non-standard security handshakes, HMAC, etc) into the ext-auth server that Gloo uses. A lot of Gloo users put Gloo at the edge for North/South concerns and [integrate with Istio for East-West traffic management](https://www.solo.io/blog/using-gloo-as-an-ingress-gateway-with-istio-and-mtls-updated-for-istio-1-1/).
In the [Istio 1.5 release](/news/releases/1.5.x/announcing-1.5/), many architectural considerations have changed with how folks deploy and manage Istio. The way mTLS is implemented in Istio has also changed a bit. For example, In the past, Istio would create secrets for each service account and mount those in for the workloads to assume their identity. That has now changed. Istio uses [Envoys SDS](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret) to [distribute workload identity/certificates by default with Istio 1.5 now](/docs/concepts/security/#pki).