Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cadcproxy.pem, cacerts should be expected somewhere other than /config #30

Open
brianmajor opened this issue Dec 3, 2020 · 2 comments
Labels
TBD To Be Discussed

Comments

@brianmajor
Copy link
Member

In kubernetes, these two config items should be configured as secrets so as to (somewhat) protect them. This means that they cannot go in /config because one is not allowed to mount secrets and config maps to the same location (or a subdir).

@pdowler
Copy link
Member

pdowler commented Feb 4, 2021

For cacerts, this is configuration of the system if you follow normal unix model: they ultimately go into /etc and are read and used by various system software. They are not credentials and they are not "secret" in any way: CA certs have to be publicly available to be useful.

@pdowler
Copy link
Member

pdowler commented Feb 4, 2021

For cadcproxy.pem : yes, this is a credential and noted "probably wrong" thing to do in the READMEs.

We have to design containers for how kubernetes works? I'm not saying it's bad to separate credentials from config, but it's always bad to make choices based on one deployment technology.

The complication is in how to pass the certificate to the application... currently we use the normal OpenCADC "well known location" of $HOME/.ssl/cadcproxy.pem but cadc-java and cadc-tomcat images don't advertise or guarantee a specific value of $HOME and there are good reasons to try to keep it like that.

Options, in no specific order:

  1. deployer puts a cert file however/wherever they want and applications have to be configured with the path to the file; change all application config parsing
  2. specify a known value for $HOME so deployer can put application config and credentials into $HOME however they like and keep /config for "system" config
  3. specify exactly 2 separate mount points - config and credentials - so k8s can be made to work and everyone else has more complexity

There are other use cases (besides k8s) that would be best satisfied by 1 or 2 (current won't work, 3 won't be any better)

A base container like this is an API and it's hard to keep it from being very brittle. Option 2 could be very brittle.

@pdowler pdowler added the TBD To Be Discussed label Feb 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TBD To Be Discussed
Projects
None yet
Development

No branches or pull requests

2 participants