Setting dynamic certificates for Upstream mTLS

Support
,
1

Is there a way to dynamically set the upsteam certs for mTLS? Even though the documents state that KV Store strings (env://, vault://, consul://) can use used in tyk.conf, the security.certificates.upstream doesn’t seem to parse those values. The value seems to only support file paths and certificate ids. However, if this field doesn’t support dynamic values, you’re left hard-coded values.

My use case is that I’d like the option to use different certificates in different environments (QA, Production, etc.).

Hence, as far as I can tell, in order to have different certs per environment, the only option I can really see is to hardcode a filename and mount different file contents per environment. Is that correct or am I missing options?

Here is an example of the configuration I’m attempting to use:

{
  "log_level": "info" ,
  "listen_port": 8080,
  "template_path": "/opt/tyk-gateway/templates",
  "app_path": "/opt/tyk-gateway/apps",
  "storage": {
    "type": "redis",
    "host": "redis",
    "port": 6379
  },
  "security": {
    "certificates": {
      "upstream": {
        "*": "vault://secret/tyk.cert"
      }
    }
  },
  "kv": {
    "vault": {
      "address": "http://vault:8200",
      "token": "root-token",
      "kv_version": 2
    }
  }
}

This generates the error message: “Can’t retrieve certificate:vault://secret/tyk.combinedopen vault://secret/tyk.combined: no such file or directory”. I know that vault is configured correctly as I can read secrets as target_urls in APIs.
I put in a issue for the KV setting, but right now I’m open to other alternatives if that’s not supported.

Thanks!

1 Like
2

I don’t think we mention it supports certs. Can you share the documentation page that mentions this?

I believe this is correct.

The security.certificates.upstream is looking for a path to the certificate on the file system. We don’t have a specific key word to retrieve a vault or secret value when referencing certs.

3

It doesn’t directly mention supporting certs, but it also doesn’t state any limits to its usage in tyk.conf.

Usage information

The KV system can be used in the following places:

  1. Configuration file - tyk.conf
  2. Environment variables - .env which supersedes the configuration file.
  3. API Definition - currently, only the listen path and target URL
  4. Body transforms and URL rewrites

Honestly, I’m not sure where in tyk.conf it can be used. So far I haven’t found a spot where it does definitively works. If it’s not globally usable in that file, could the docs please spell out which fields do accept it? As it’s written, I think it’s easy to interpret it as meaning that any string value in that file can pull from KV.

4

Hi @matthewdickinson,

Sorry for the delay getting back to you on the related Github query.

You are right that the docs are not explicit on this - I’m actively working on improving the content for that page to make it clear.

I can confirm that, for the Tyk Gateway config file (tyk.conf) you are currently limited to these fields that can be accessed from a KV store:

  • secret
  • node_secret
  • storage.password
  • cache_storage.password
  • security.private_certificate_encoding_secret
  • db_app_conf_options.connection_string
  • policies.policy_connection_string

The upcoming release will not extend this list, but I want to acknowledge your request here and we will look at making improvements here at some point. The roadmap is very full at the moment, so I can’t currently give you an estimate when this will be implemented.

Thanks again for pointing out this limitation in the docs.

1 Like