Skip to content
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.

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

Document the TLS with ACME case #4654

Merged
merged 1 commit into from
Mar 26, 2019
Merged

Document the TLS with ACME case #4654

merged 1 commit into from
Mar 26, 2019

Commits on Mar 26, 2019

  1. kubernetes: document the TLS with ACME case

    When we did the kubernetes crd implementation, we forgot to test the
    case for when one wants TLS, but handled with Let's Encrypt, i.e.
    without having to provide a Kubernetes Secret. We assumed it would be
    enough to provide (in YAML) a tls object with no field set, which would
    get us a non-nil IngressRouteSpec.TLS, allowing us to use
    IngressRouteSpec.TLS as the sentinel for whether TLS should be enabled.
    
    However, as IngressRouteSpec.TLS is a pointer, a tls object with no
    fields set will actually result in IngressRouteSpec.TLS being nil. This
    means at least one of the fields of the YAML tls object must exist.
    Therefore, we now use the secretName field value (for now, as it is
    the only field anyway) as the sentinel for whether Let's Encrypt should
    be used.
    
    This PR documents the above behavior, and adds a unit test for it.
    
    In addition, this PR fixes a related bug in the ACME provider: when a
    router is not configured with TLS enabled, the ACME provider does not
    try anymore to generate a (useless) certificate for the corresponding
    domain.
    mpl authored and traefiker committed Mar 26, 2019
    Configuration menu
    Copy the full SHA
    b036a94 View commit details
    Browse the repository at this point in the history