fix: Use Opaque secret for TLS config #191
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a collection of final fixes for TLS:
feat: Document that TLS secret is Opaque type
We realised that using a
tls
secret type and adding on aca.crt
keywould be annoying for users. With the
tls.crt
andtls.key
fields,users have the options to supply the values without the
START
andEND
headers/footers, which are added back by the Secrets controller. For the
ca.crt
, we would require that the headers are present (adding the pemto the
CaPool
with fail otherwise) and we don't want to have toprocess the bytes ourselves.
Users can create the other fields with or without headers, but one rule for
part of the data, and another rule for the rest is an irritating thing to
document so this just makes it easier.
Certmanager creates all data values with the headers present, so this
will work for either users in either case.
ref: Save TLS config data as bytes
Loading the TLS certs and CaPool takes
[]byte
anyway, so there is noneed to
string()
and[]byte()
back and forth.And load 509X from bytes not files.
Also stop decoding the secret data: I did not realised that was done
magically when you
Get
the secret.Finally add a bit more logging to make TLS load failures clearer.
feat: RequireTransportSecurity when TLS is not nil
We only want to require this when TLS has actually been configured,
otherwise the client call will fail.
Tested with Flintlock: