Host security policies are affecting other Hosts.
See original GitHub issueSummary
When using more than one Host
, the spec.requestPolicy.insecure.action
value on one host can affect the actions of another host. Selecting either Route or Redirect on client1.myhost.net
would cause client2.myhost.net
to follow the same behavior, regardless of what is set on the client2.myhost.net
Host
. This is particularly relevant for host-based routing as, for example, a Host
that requires insecure routing (but is somehow secured in some other fashion), could potentially overwrite the behavior of a more exposed Host
, resulting in cleartext routing on what is expected to be a secure gateway.
Issue/Request
Ambassador should explicitly follow the Host
insecure behavior specified to the exact host that is being applied.
Replicator
-
Kubernetes cluster info
- Server Version: version.Info{Major:“1”, Minor:“18”, GitVersion:“v1.18.3”, GitCommit:“2e7996e3e2712684bc73f0dec0200d64eec7fe40”, GitTreeState:“clean”, BuildDate:“2020-05-20T12:43:34Z”, GoVersion:“go1.13.9”, Compiler:“gc”, Platform:“linux/amd64”}
- DigitalOcean
-
Ambassador install info
- Ambassador Edge Stack v1.6.1
-
Ambassador configuration
-
Repro:
-
Apply the following hosts:
```yaml
---
apiVersion: getambassador.io/v2
kind: Host
metadata:
name: client1-host
namespace: ambassador
spec:
hostname: client1.example.net
acmeProvider:
authority: https://acme-v02.api.letsencrypt.org/directory
email: example@datawire.io
privateKeySecret:
name: client1-host-secret
tlsSecret:
name: client1-example-net
requestPolicy:
insecure:
action: "Redirect"
---
apiVersion: getambassador.io/v2
kind: Host
metadata:
name: client2-host
namespace: ambassador
spec:
hostname: client2.example.net
acmeProvider:
authority: https://acme-v02.api.letsencrypt.org/directory
email: example@datawire.io
privateKeySecret:
name: client2-host-secret
tlsSecret:
name: client2-example-net
requestPolicy:
insecure:
action: "Route"
```
- Apply the
QotM
backend. curl -Lv http://client2.example.net/backend/
- Returns the following:
* Trying REDACTED...
* TCP_NODELAY set
* Connected to client2.example.net (REDACTED) port 80 (#0)
> GET /backend/ HTTP/1.1
> Host: client2.example.net
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< location: https://client2.example.net/backend/
< date: Mon, 27 Jul 2020 14:12:21 GMT
< server: envoy
< content-length: 0
<
* Connection #0 to host client2.example.net left intact
* Issue another request to this URL: 'https://client2.example.net/backend/'
* Trying 164.90.252.90...
* TCP_NODELAY set
* Connected to client2.example.net (REDACTED) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=client2.example.net
* start date: Jul 27 12:46:50 2020 GMT
* expire date: Oct 25 12:46:50 2020 GMT
* subjectAltName: host "client2.example.net" matched cert's "client2.example.net"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET /backend/ HTTP/1.1
> Host: client2.example.net
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: application/json
< date: Mon, 27 Jul 2020 14:12:21 GMT
< content-length: 141
< x-envoy-upstream-service-time: 0
< server: envoy
<
{
"server": "trim-coconut-zcln5siq",
"quote": "A late night does not make any sense.",
"time": "2020-07-27T14:12:22.204571703Z"
* Connection #1 to host client2.example.net left intact
}* Closing connection 0
* Closing connection 1
Notes
It appears as though it operates alphanumerically. Adding application.example.net
overwrites client1.example.net
and client2.example.net
, for example.
I have not tested if it affects other Ambassador deployments, however I suspect it does not.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
Assuming its not fixed, this is actively blocking us from enabling http to https redirection.
This was addressed in the 2.0.0 EA release. The subsequent 2.0.4 release that shipped earlier this week is now Generally Available.