dev - mid update #63

Merged
ofilter merged 14 commits from dev into main 2023-07-01 16:22:01 +02:00
33 changed files with 14 additions and 13 deletions
Showing only changes of commit b7de0f8205 - Show all commits

View File

@ -5,7 +5,7 @@ include_toc: true
# Based on
- [07-HTTPS-Gateway-Simple-TLS](../07-HTTPS-Gateway-Simple-TLS)
- [07-HTTPS-Gateway-Simple-TLS](../03-HTTPS-Gateway-Simple-TLS)
# Description

View File

@ -5,7 +5,7 @@ include_toc: true
# Based on
- [08a-HTTPS-min-TLS-version](../08a-HTTPS-min-TLS-version)
- [08a-HTTPS-min-TLS-version](../04a-HTTPS-min-TLS-version)
# Description

View File

@ -5,7 +5,7 @@ include_toc: true
# Based on
- [08a-HTTPS-min-TLS-version](../08a-HTTPS-min-TLS-version)
- [08a-HTTPS-min-TLS-version](../04a-HTTPS-min-TLS-version)
# Description

View File

@ -5,7 +5,7 @@ include_toc: true
# Based on
- [10-TCP-FORWARDING](../10-TCP-FORWARDING)
- [10-TCP-FORWARDING](../05-TCP-FORWARDING)
# Description

View File

@ -5,7 +5,7 @@ include_toc: true
# Based on
- [07-HTTPS-Gateway-Simple-TLS](../07-HTTPS-Gateway-Simple-TLS)
- [07-HTTPS-Gateway-Simple-TLS](../03-HTTPS-Gateway-Simple-TLS)
# Description

View File

@ -143,7 +143,7 @@ virtualservice.networking.istio.io/helloworld-vs created
### Get LB IP
```shell
$ kubectl get svc -l istio=ingressgateway -A
kubectl get svc -l istio=ingressgateway -A
```
```text
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
@ -177,14 +177,15 @@ curl 192.168.1.50/external
We don't receive any output.
This could be due, even if we resolve the destination IP for the URL `info.cern.ch`, the destination might have a Reverse Proxy or any other ingress resource that could condition handling this request.
Even if we resolve the destination IP for the URL `info.cern.ch`, the destination might have a **Reverse Proxy** or any other ingress resource that could condition handling this request.
Due to the `HOST` field not being modified after we set the request, it might not be able to pass the filtering set, weather it is security wise, for example, requiring such field to allow the request; or it being a routing condition, which due not having this field specified, it's not able to route the request towards the destination desired.
Due to the `HOST` field not being modified after we set the request, it might not be able to pass the filtering rules set on the destination server, on this scenario being the service responsible for receiving requests with the URL `info.cern.ch`.
```shell
curl 192.168.1.50/external-noh
```
```text
</pre></body></html>
```
## Cleanup

View File

@ -5,7 +5,7 @@ include_toc: true
# Based on
- [08a-HTTPS-min-TLS-version](../../03-Gateway_Ingress/08a-HTTPS-min-TLS-version)
- [08a-HTTPS-min-TLS-version](../../03-Gateway_Ingress/04a-HTTPS-min-TLS-version)
# Description

View File

@ -558,7 +558,7 @@ On this scenario, we met a fatal error, not allowing us to access the service, u
From my understanding, not only from this interaction, but from investigating through Istio forums (yet I don't have the link handy, so take this words with some grains of salt), **the traffic cannot be double terminated**, for such if we have an `HTTPS` backend, we might require to disable `mTLS` in order to communicate with it. We also would need to set a [Destination Rule like we did further above](#destination-rule), to specify that the traffic must be terminated with the backend (`tls.mode: STRICT`).
Yet this depends on which would be our architecture, due also being able to set up [TLS Passthrough](../../03-Gateway_Ingress/11-TLS-PASSTHROUGH), or use a [TCP Forwarding](../../03-Gateway_Ingress/10-TCP-FORWARDING).
Yet this depends on which would be our architecture, due also being able to set up [TLS Passthrough](../../03-Gateway_Ingress/06-TLS-PASSTHROUGH), or use a [TCP Forwarding](../../03-Gateway_Ingress/05-TCP-FORWARDING).
```shell
curl 192.168.1.50/https-mTLS

View File

@ -8,7 +8,7 @@ The page used as a destination is my own [GitHub page](https://github.com/).
# Based on
- [05-hello_world_1_Service_Entry](../../04-Backends/05-Service_Entry)
- [05-hello_world_1_Service_Entry](../../04-Backends/01-Service_Entry)
# Configuration
@ -75,7 +75,7 @@ The path `/external` will forward the request towards the destination URL `githu
Highlight that the destination is `github.com`, which is the same as the contents set on the field `host` from the [ServiceEntry resource configured above](#serviceentry).
As seen [in the previous example, where the host that didn't have the `HOST` header wasn't able to receive a response by the destination](../../04-Backends/05-Service_Entry/#external-noh), we configured the `HOST` header to match the URL from the external service.
As seen [in the previous example, where the host that didn't have the `HOST` header wasn't able to receive a response by the destination](../../04-Backends/01-Service_Entry/#external-noh), we configured the `HOST` header to match the URL from the external service.
```yaml
apiVersion: networking.istio.io/v1alpha3
@ -108,7 +108,7 @@ spec:
## DestinationRule
As seen in the example [02-Traffic_management/09-HTTPS-backend](../../04-Backends/09-HTTPS-backend), where we configure Istio to use an `HTTPS` backend, the same configuration is applied on this case (yes, I am aware that a `ServiceEntry` is also a backend).
As seen in the example [02-Traffic_management/09-HTTPS-backend](../../04-Backends/02-HTTPS-backend), where we configure Istio to use an `HTTPS` backend, the same configuration is applied on this case (yes, I am aware that a `ServiceEntry` is also a backend).
For such, we deploy a `DestinationRule` setting to expect to terminate the TLS traffic, for the traffic with resource destination `github.com`, and port `8443`, which matches the settings set in our [ServiceEntry](#serviceentry) deployed.