[fftls] Allow for In-Memory or Inlined TLS Certificates

[onelapahead]

Useful for configs which want to inline the certs as large PEM blocks in their config files, or when constructing TLS configs from in-memory certificates (such as certificates downloaded from a Kubernetes Secret).

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.96%. Comparing base (a54fd73) to head (0a735f3).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #132   +/-   ##
=======================================
  Coverage   99.96%   99.96%           
=======================================
  Files          79       79           
  Lines        6490     6507   +17     
=======================================
+ Hits         6488     6505   +17     
  Misses          1        1           
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[onelapahead]

Small example that provides some context:

cfg := &ffresty.Config{}
secretName := "mtls-config"
secret := &corev1.Secret{}
err := ctrlClient.Get(context, types.NamespacedName{Namespace: "default", Name: secretName}, secret)
if err != nil {
  return nil, err
}

tls, err := fftls.NewTLSConfig(context, &fftls.Config{
  Enabled: true,
  CA:      string(secret.Data["ca.crt"]),
  Cert:    string(secret.Data["tls.crt"]),
  Key:     string(secret.Data["tls.key"]),
}, fftls.ClientType)
if err != nil {
  return nil, err
}
cfg.TLSClientConfig = tls
// proceed to use ffresty config to make a client

[nguyer]

Is there a specific reason to pull in require here, as opposed to assert? I think for unit tests we typically have stuck with assert, though I am noticing that is not as true in this particular repo

[onelapahead]

So require fails the test immediately whereas assert keep runs the test if it doesn't pass. So I always use require for anything involve setup, where if it errors / is not successful, the entire things fails.

It's just syntactic sugar for:

if err != nil {
  t.Fatal(err)
}

I believe

[nguyer]

Just a couple of minor suggestions but otherwise looks good.

[nguyer]

I think we should document (probably in this comment so it's visible to the developer) that if these are set they will take precedence over the "file" fields.

[onelapahead]

Well its the opposite in that the file fields take precedence over these fields for backwards compatibility's sake.

That could be the wrong approach, but I'm updating the comments now to reflect the current behavior.

[onelapahead]

Comments updated

[nguyer]

You're right sorry. Had the switch statement backwards in my head.