Reliably set TLS options with the docker provider

Traefik Traefik v2
1

Hello.

I know this topic has been discussed previously:

I think I understand that TLS options cannot be defined through the docker provider (they can only be set to something defined elsewhere).

I also know how to configure mTLS on my service container by properly referencing an existing set of TLS options already defined in the traefik container's dynamic configuration.

The actual problem:

My question is about the actual reliability of setting the TLS options through docker labels.

Take the following docker-compose labels:

someservice:
  labels:
    - "traefik.http.routers.gatekeeper_whoamisecure.tls=true"
    - "traefik.http.routers.gatekeeper_whoamisecure.tls.certresolver=someresolver"
    - "traefik.http.routers.gatekeeper_whoamisecure.tls.options=someoptions@file"

If for some reason "someoptions@file" does not exist anywhere. Treafik only seems to report it as a debug message:

time="2022-04-03T12:47:28Z" level=debug msg="unknown TLS options: someoptions@file" entryPointName=websecure routerName=someservice@docker

Then the service starts and is served through TLS (hopefully) but it will NOT be configured as expected.

Why is it a problem ?

Let say that "someoptions@file" used to be a very strong mTLS configuration with client authentication... but it got reworked / renamed in the traefik container configuration...
... and we forgot to update each and every service container that depend on it. Shame on us but unfortunately I believe it is a quite common situation.

  • The service is exposed no matter what even though it is not properly configured.
  • Depending on the default configuration then the service gets exposed to every one while we expected it to be only available to mutually authenticated clients !
  • Last but not least: We do not get notified that the mTLS options were not found (and merely ignored).
    Indeed: The "DEBUG" log level is not really reflecting that we face a major problem here...

What would I expect ?

Well clearly, I'd expect that either:

  1. The service is not served at all when a configuration is wrong.
    This would be equivalent as re-configuring this service container as if it had defined "traefik.enable=false"

  2. Clearly and loudly log this ERROR in a proper log with an apropriate* log level.
    *appropriate = ERROR _(or WARNING at a bare minimum).

Discussion:

Can someone help me find out the rationale behind the current Traefik behaviour ?
Why is it behaving like this ?
Is it worth submitting a bug/feature request or is it me who is completely out of line here ?

Thanx for you help !

2

Just a simple reply/note to myself and other people who'd be interested:

Possible Mitigation

As a possible mitigation to avoid deception of the service container, you can define a default TLS policy that will never accept any client:

tls:
  options:
    #   Define a dummy CA which is a mere self-signed certificate whose
    # private key was properly shredded before it can sign anything else.
    #   This way, if for some reason Traefik does not find or implements
    # your docker labels properly, then you just won't be able to connect.
    default:
      maxVersion: VersionTLS13
      clientAuth:
        caFiles:
          - /home/traefik/pki/Dummy/RootCA/certs/ca.pem
        clientAuthType: RequireAndVerifyClientCert
    # Then you can define meaningful TLS configurations
    someConfig-mTls:
      clientAuth:
        # This is an actual CA:
          - /home/traefik/pki/Users/RootCA/certs/ca.pem
        clientAuthType: RequireAndVerifyClientCert
    someOtherConfig-mTls:
      clientAuth:
        # This is an other actual CA:
          - /home/traefik/pki/Admins/RootCA/certs/ca.pem
        clientAuthType: RequireAndVerifyClientCert
    no-mTls:
      clientAuth:
        clientAuthType: NoClientCert

Hence when you fail to properly refer to an existing TLS options-set in your service containers labels, TLS will default to a dummy configuration that requires client authentication against a CA that never issued any clients (and that will never be able to do so because you threw the private key away).

1 Like