Skip to content

Clarifying TLS Spec on HTTPRoute, Moving to Extended Support #739

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Clarifying TLS Spec on HTTPRoute, Moving to Extended Support #739

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 17 additions & 12 deletions apis/v1alpha2/httproute_types.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,21 +113,26 @@ type HTTPRouteSpec struct {

// TLS defines the TLS certificate to use for Hostnames defined in this
// Route. This configuration only takes effect if the AllowRouteOverride
// field is set to true in the associated Gateway resource.
// field is set to true in the associated Gateway Listener.
//
// Collisions can happen if multiple HTTPRoutes define a TLS certificate
// for the same hostname. In such a case, conflict resolution guiding
// principles apply, specifically, if hostnames are same and two different
// certificates are specified then the certificate in the
// oldest resource wins.
// Attaching a TLS certificate to HTTPRoutes provides a way for HTTPRoute
// owners to effectively populate certificates on Gateway Listeners. Note
// that only one certificate may be attached to a Gateway Listener for a
Copy link
Contributor

@bowei bowei Jul 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to talk about how wildcards are handled?

// specified hostname. It is not possible to use different certificates for
Copy link
Contributor

@jpeach jpeach Aug 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only one secret can be attached to a listener, but we don't specify what is in that secret. You could have a whole pile of certificates if you want :)

// different HTTPRoutes for the same hostname on the same Gateway Listener.
//
// Please note that HTTP Route-selection takes place after the
// TLS Handshake (ClientHello). Due to this, TLS certificate defined
// here will take precedence even if the request has the potential to
// match multiple routes (in case multiple HTTPRoutes share the same
// hostname).
// If multiple HTTPRoutes define a TLS certificate for the same hostname and
// are bound to the same Gateway Listener, precedence MUST be determined in
Copy link
Contributor

@jpeach jpeach Aug 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you are referring to the precedence of the certificate here?

So in this case

  • all the routes are valid
  • only one of the matching certificates is configured on the proxy
  • there's no update to the route's status conditions

// order of the following criteria, continuing on ties:
//
// Support: Core
// * The oldest Route based on creation timestamp. For example, a Route with
// a creation timestamp of "2021-07-28 01:02:03" is given precedence over
// a Route with a creation timestamp of "2021-07-28 01:02:04".
Copy link
Contributor

@ccfishk ccfishk Aug 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we apply latest timestamp win previous timestamp, which is similar to overwrite.
Do I miss any restrict/rules somewhere ?

Copy link
Contributor

@jpeach jpeach Aug 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://gateway-api.sigs.k8s.io/concepts/guidelines/#conflicts

Oldest-wins is least likely to break existing configurations.

// * The Route appearing first in alphabetical order by
// "<namespace>/<name>". For example, foo/bar is given precedence over
// foo/baz.
//
// Support: Extended
//
// +optional
TLS *RouteTLSConfig `json:"tls,omitempty"`
Expand Down
24 changes: 15 additions & 9 deletions config/crd/bases/gateway.networking.k8s.io_httproutes.yaml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.