Issue #238: Use the public image on quay.io to deploy internal WaiverDB instances - waiverdb

waiverdb

#238 Use the public image on quay.io to deploy internal WaiverDB instances

Closed: Fixed 6 years ago Opened 6 years ago by rayson.

Currently, 2 variants of WaiverDB images are used:
1. quay.io/factory2/waiverdb is the public variant.
2. docker-registry.engineering.redhat.com/factory2/waiverdb is the Red Hat internal variant with bundled Red Hat Intranet CA.

Because maintaining 2 variants of images adds complexity to C3I pipeline design, it's better to use a unified image for both internal and external uses.

Following is a potential solution to use the public image on Red Hat internal infrastructure:

Add options to settings.py for specifying CA certificates of dependency services. For example:
RESULTSDB_API_CA for the CA certificate to verify ResultsDB against. I think there has been an option for the CA to verify UMB, right?
Update the OpenShift manifests for dev/stage/prod developments: Add the internal CA certificate as a secret, mount it to WavierDB pods, and reference it in settings.py.

@csomh @ralph @lholecek Any comments?

csomh commented 6 years ago

@rayson: another solution would be to have an entrypoint script which checks if envvar is set, downloads the cert and calls update-ca-trust. What do you think?

rayson commented 6 years ago

@csomh It would be nice to trust the CA globally in that pod, but unfortunately update-ca-trust requires root :(

csomh commented 6 years ago

Hm, yeah, I've forgot about that.

One more way could be to use REQUESTS_CA_BUNDLE env var (did not try, but could work in theory).

Or maybe just be explicit about the whole thing and stick with settings.py ... Let's see what the others say.

sochotni commented 6 years ago

@csomh It would be nice to trust the CA globally in that pod, but unfortunately update-ca-trust requires root :(

If you look at /bin/update-ca-trust you'll see it does not check root ID. All you'd need is to set those couple files in /etc to be writeable by root group - that way you could run update-ca-trust within entrypoint

Not going to judge whether it's worth the trouble or other solution might be preferable...

rayson commented 6 years ago

@sochotni Sure we can make the CA bundles writable, but I am not sure if it will violate any security rules that the team wants to follow.
@csomh @ralph @lholecek @dcallagh Are you OK with making CA bundles writable?

lholecek commented 6 years ago

As @csomh suggested, I would rather go with REQUESTS_CA_BUNDLE. If that doesn't work, let's implement new option.

rayson commented 6 years ago

@lholecek @csomh I will try REQUESTS_CA_BUNDLE and see if it works.

rayson commented 6 years ago

@lholecek @csomh
Just verified: Specifying REQUESTS_CA_BUNDLE env var and STOMP_CONFIGS.connection.ssl_ca_certsconfig option works in my test environment.

rayson commented 6 years ago

@csomh @lholecek
We need an approach to inject the internal CA certificate to the running pod. Which option do you prefer?

Creating a Secret containing the content of the CA certificate. This means the content of CA certificate is hardcoded in the WaiverDB OpenShift manifest.
Download the CA certificate to somewhere at WaiverDB pod starts. We need to provide an entrypoint script to download it from password.corp.redhat.com and the target directory should have the write permission.

lholecek commented 6 years ago

@rayson Perhaps do it the same way as Estuary (Dockerfile, install-ca.sh) - and maybe we don't even need the REQUESTS_CA_BUNDLE variable.

CC @mprahl

rayson commented 6 years ago

I've created #239 and https://gitlab.cee.redhat.com/devops/factory2-openshift-templates/merge_requests/100 to reflect this change.

Edited 6 years ago by rayson

rayson commented 6 years ago

Closing as merged.

Metadata Update from @rayson:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

6 years ago