[NET-8091] Add file-system-certificate config entry for API gateway

[nathancoleman]

Description

Today, inline-certificate is the only supported way of specifying a TLS certificate + private key for an api-gateway. As the name suggests, the certificate + private key values are "inlined" in the configuration entry.

This PR adds a new file-system-certificate configuration entry that instead accepts file paths to a certificate + private key that are accessible in the local file system of the api-gateway at runtime. This functions in the same way that terminating-gateway does today (docs) but adds support for rotation by watching the file system for changes to the referenced certificate + private key.

Ideally, we will be able to add this same support for rotation in terminating-gateway in the future as rotating the certificate and private key today require a restart of the terminating-gateway, which is not ideal (docs).

Testing & Reproduction steps

Testing on VMs

Check out this repo from @nathancoleman

1. Follow the directions in the README.
2. You can check the secret at http://localhost:19000/config_dump under dynamic_active_secrets.

3. echo secret_val | base64 -d and you should see the value of cert.crt

4. Replace the value of cert.crt with this certificate:

-----BEGIN CERTIFICATE-----
MIICnTCCAkOgAwIBAgIRALTzFaRsW70V2hhpw6XdmKEwCgYIKoZIzj0EAwIwgbkx
CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNj
bzEaMBgGA1UECRMRMTAxIFNlY29uZCBTdHJlZXQxDjAMBgNVBBETBTk0MTA1MRcw
FQYDVQQKEw5IYXNoaUNvcnAgSW5jLjFAMD4GA1UEAxM3Q29uc3VsIEFnZW50IENB
IDMwNzU0NzMzNjE5NTQ2OTU4MjIxMTI5MjE3NzM2MzUxMzM4MDc0NzAeFw0yNDA0
MDkxODIxNDNaFw0yNTA0MDkxODIxNDNaMBwxGjAYBgNVBAMTEXNlcnZlci5kYzEu
Y29uc3VsMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAESdiYfmA1LURAFLGt59hu
U3UgTMcSAIf3Hl+KYrDRWStjviB4ueemTI+8pXjd8gETXKxp+i5vxIBF9bW95zSb
2KOBxzCBxDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMAwGA1UdEwEB/wQCMAAwKQYDVR0OBCIEIJ32ryqpgyOlctlfqniwLBCt
HosjcftQwK1rjoI6LFnCMCsGA1UdIwQkMCKAICJ9E1X61c/+gkiHJmmiQkVx3g89
MkOYHfJlRoTQlpNpMC0GA1UdEQQmMCSCEXNlcnZlci5kYzEuY29uc3Vsgglsb2Nh
bGhvc3SHBH8AAAEwCgYIKoZIzj0EAwIDSAAwRQIhAKvSL4YDwQPMNgGMibtRTYRs
cHZzR4Vv1JN6D2FDmVYUAiBT+6ySH0bXK9/kFA+RkTbPUwDzfe+qlzs+frK5tqE+
Dw==
-----END CERTIFICATE--

5. Then check the value of the dynamic_active_secrets again, it should match the above cert.

Testing on K8S

You cannot do the same type of replacement for K8S, so if you would like to test K8S check out the K8S PR. You will mainly verify that the certificate is a file-system-certificate as opposed to an inline-certificate.

Links

PR Checklist

• updated test coverage
• external facing docs updated
• appropriate backport labels added
• not a security concern

[NiniOak]

Did you intentionally omit this check in both cases?

if !ok {
    continue
}

[missylbytes]

Yes because I think this would only be a programmer error, not something that people should run into.

[nathancoleman]

they're functionally the same unless I'm missing something.

if ok {
 // do something
}

vs.

if !ok {
  continue
}

// do something

[NiniOak]

I guess it just depends on the behaviour we want

if ok { 
    // do something 
}

using the above code, we successfully retrieve the certificate and move on to the next thing.

if !ok {
  continue
}
// do something

This code here indicates that what we'll like to do if the cert isn't found, we can skip the rest of the iteration and move onto the next thing. Just depends on how we want to handle it. I saw that we used if !ok { continue} in the previous implementation and was wondering why we didn't here.

[nathancoleman]

ohhhh I see what you're saying. I just went with the current flavor because it simplified the code and had the same outcome, no more reasoning that

[NiniOak]

Small error check comment but mostly looks good. The work done here is MASSIVE and IMPRESSIVE. Very well done 🚀

[missylbytes]

This will not be back-ported at this time.