Better modeling of a "virtual host"

[bowei]

This has come up in discussions about the split in functionality between Gateway and the set of Routes attached to a Gateway. See the meeting notes starting here:

The purpose of the split resource is model different permissions and delegation regarding assembly of a LB vs the application author (see "resource model" here: https://kubernetes-sigs.github.io/service-apis/concepts).

As currently sketched, we have virtualhost definitions in the Route while protocol e.g. TLS termination settings are determined in the Gateway. This presents an interesting twist regarding TLS certificates: it is part of a lower-level protocol layer that ties into higher layer HTTPx protocols. Also there are use cases such as support for TLS byte streams or TLS-based opaque routing.

At the same time, we need to be careful about allowing the admin persona control over security related policies, e.g. which certificates can/cannot be attached to a given gateway.

• If TLS settings are specified at the Gateway level and virtualhost routing at the Route level, can we reduce the verbosity associated with this setup? This is information that needs to be consistent split between two resources.
• Should the owner of a application (e.g. Route) be able to specific their own certificates and TLS policies? If this is allowed, how will this ability be controlled in a safe and effect way? OR does this just mean we should give the application developer access to the Gateway resource, as they are going to be introducing certificates anyway.

Proposal to get clarity:

• Sketch out permissions models regarding what each permissions we see giving the different personas in each case.
• Sketch out model with TLS stream and HTTPS models.

[danehans]

API implementation example for adding tls config in routes: #35

[ironcladlou]

/cc @smarterclayton

[danehans]

Sketch out permissions models regarding what each permissions we see giving the different personas in each case.

@bowei I've started working on this. PTAL at this drawing, which models TLS Config in HTTPRoute for the "Developer" persona. Let me know if I'm heading in the right direction. If so, I will expand to cover the different scenarios.

[danehans]

OR does this just mean we should give the application developer access to the Gateway resource, as they are going to be introducing certificates anyway.

If we give the Developer persona access to a Gateway, I question whether a separate resource (i.e. HTTPRoute should still exist.

[danehans]

xref tls termination policy: #52

[jpeach]

I've started working on this. PTAL at this drawing, which models TLS Config in HTTPRoute for the "Developer" persona

@danehans That diagram doesn't mention TLS config, so maybe I am missing some context?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[hbagdi]

/remove-lifecycle stale

[hbagdi]

#193 addresses some concerns in this issue.

[costinm]

I think it's a great change ! AllowedHostname[] is reasonable - it allows the domain owner to create a Gateway, set the cert and restrict which namespaces can use the domain. Assuming #197 is addressed ( i.e. allow using the namespace name ) - it seems viable.

I'm not very sure the usability of having port 443 and port 80 is great - it is extremely common to have the same hostname on both http and https ( with http doing redirect usually ). In this model, user will have to type every hostname 2x - once for the port 80 and once for port 443.
Instead the list of hostnames (hostname match or allowedhostnames) could be in Gateway at the top level, and can optionally include a port.

example:

Gateway:
   allowedHostnames:
     - www.example.com
     - admin.eample.com:443
     - *.test.example.com

   listeners:
     - port: 80
     - port: 443
        tls: 
          ....

[hbagdi]

In this model, user will have to type every hostname 2x - once for the port 80 and once for port 443.

Providing hostnames at the gateway layer implies that if you are mixing L4 and L7 listeners, and if there is no way to decide filter hostnames at a per listener level, that would lead to users configuring multiple Gateways. YAML's referencing (* and &) capabilities could help somewhat to avoid the duplication?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[hbagdi]

@bowei @jpeach @robscott It seems we have settled on this one, can we close this one?

[jpeach]

Yup, I'm happy yo close this out.

[hbagdi]

Closing this since we have consensus on this. If you disagree, please feel free to re-open.
/close

[k8s-ci-robot]

@hbagdi: Closing this issue.

In response to this:

Closing this since we have consensus on this. If you disagree, please feel free to re-open.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.