Tls using additionalVolumes of pr736 #918
Conversation
…to be mounter or not
Check that there are no volume mount path clashes or "all" vs ["a", "b"] mixtures. Also change the default behaviour to mount to "postgres" container.
ReSearchITEng
requested review from
CyberDem0n,
FxKu,
Jan-M,
RafiaSabih,
avaczi,
erthalion and
sdudoladov
as code owners
|
Thanks @ReSearchITEng for following up on my suggestion from #736 😃 |
| * **caSecretName** | ||
| By setting the `caSecretName` value, the ca certificate file defined by the | ||
| `caFile` will be fetched from this secret instead of `secretName` above. | ||
| This secret has to hold a file with that name in its root. |
There was a problem hiding this comment.
This is not strictly necessary as the user can provide an absolute path to caFile and point into the additional volume directly. The caFile only gets expanded with the /tls prefix if the path is relative.
There was a problem hiding this comment.
right, it could be done separately using the new additionalVolumeMounts capability and point to it (which is actually used in background).
Still, following the patterns for tls in similar projects, (therefore align), having a ca secret is might be more intuitive.
FYI, your nice ensurePath function has been reused, this time on top of /tlsca path.
btw, if the ca secret is not provided, the rest of functionality remains as is.
There was a problem hiding this comment.
Right, the extra code complexity might be worth it if it makes things easier for the user. I am not in a position to judge that.
|
superseded by pr #920 |
5 participants
make tls(pr798 of @zimbatm ) use additionalVolumes capability from pr736 (of @seuf @Thierry )
(as suggested by @frittentheke and @FxKu )
in
#736 (comment)
It also adds capability to hold ca.crt in a different secret.