CLOUD-2689: jboss.container.java.certs module #312
Conversation
This module enables the trusting of CA certificates provided to running containers by OpenShift. At build-time: various system PKI paths are made world writeable-by-all, in order that the random-UID runtime user can insert CA certificates into the trusted store At run-time: copy the CA file into place and invoke /usr/bin/update-ca-trust To generate derivative trust stores (e.g. OpenSSL & Java JKS) Signed-off-by: Jonathan Dowland <jdowland@redhat.com>
|
Further work required
|
This ensures the script will be invoked for all S2I entrypoints Signed-off-by: Jonathan Dowland <jdowland@redhat.com>
|
Here's the test harness I used to verify this work for myself. It leaves much to be desired but might aid assurance for reviewing this PR https://github.com/jmtd/redhat-openjdk-18-openshift-image/tree/cloud-2689-certificates-TEST Ideally it would be refactored into a module test, or a S2I-enabled repo, but I didn't want to delay this PR further at this time |
jmtd
changed the title
|
When JAVA_DISABLE_TRUST_OPENSHIFT_CA is defined the trust-openshift-supplied-CA code will not run. Signed-off-by: Jonathan Dowland <jdowland@redhat.com>
| SCRIPT_DIR=$(dirname $0) | ||
| ARTIFACTS_DIR=${SCRIPT_DIR}/artifacts | ||
|
|
||
| # necessary for random UID user to run update-ca-certs |
There was a problem hiding this comment.
Is it possible to chmod these back afterwards? it seems odd to leave them 777.
There was a problem hiding this comment.
Unfortunately not because the chmod is happening in the build stage but the write access (via update-ca-trust) is happening at runtime.
It's unpleasant and uncomfortable and comparable to where we chmod and chown /etc/passwd, or where we chown and chmod the entire EAP distribution to the jboss user.
I think of it a little like we've put up this big, thick wall around our processes (the container) and we're taking down the walls within that boundary that were more critical before, but might still be an important part of defence against some attack vectors, even now.
I would like us to have some kind of cross-team discussion about security issues like this.
There was a problem hiding this comment.
Is it enough to simply ensure the files are owned by root group and have write privs on group?
There was a problem hiding this comment.
Yes g+w is sufficient. The threat model doesn't really change (same user in both cases) but it feels nicer to not have it as wide as 777. I'll commit this.
There was a problem hiding this comment.
@rcernich the test harness I wrote to check this stuff out, I published here. In particular see test.sh line 1: each invocation of the test harness uses a random uid, just like openshift.
This harness gave me the confidence to refine my implementation and was the system I used to ensure that e.g. the symlink thing you suggested would work. It's also very easy to substitute the test CA in that branch with another, such as an internal CA cert, and adjust the invocation of the java program to check an internal HTTPS system, demonstrating that the JKS keystore was updated.
There was a problem hiding this comment.
Yes, but OpenShift also runs with group 0.
There was a problem hiding this comment.
Ah I missed the group spec! I'll adjust my harness and re-test.
There was a problem hiding this comment.
fixed and re-tested locally; seems fine
| #!/bin/sh | ||
| set -e | ||
|
|
||
| if [ -z "$JAVA_DISABLE_TRUST_OPENSHIFT_CA" ]; then |
There was a problem hiding this comment.
note that there are 2 different CA... the ca.crt , which I would call "the openshfit CA", and the service-ca.crt is a very specific one (https://docs.openshift.com/online/dev_guide/secrets.html#service-serving-certificate-secrets )
I'd prefer if we (optionally) added both.. However, even if we don't, we should make it clear in the names of the env and comments which CA is being (or not being) added.
| if [ -z "$JAVA_DISABLE_TRUST_OPENSHIFT_CA" ]; then | ||
| ca=/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt | ||
| if test -r "$ca" ; then | ||
| cp "$ca" /etc/pki/ca-trust/source/anchors/ |
There was a problem hiding this comment.
Do we want to copy this or create a link? If we create a link, can we link it to the appropriate location in the image, with a broken link...and will that link resolve appropriately once the file is mounted by OpenShift? If so, we could get away with simply invoking update-ca-trust. wdyt?
There was a problem hiding this comment.
Yes I think that would work. I'll take a look
There was a problem hiding this comment.
This seems to work fine. Thanks for the suggestion!
g+w is sufficent (group is root, and OpenShift running user is in group root) for this approach to work. Signed-off-by: Jonathan Dowland <jdowland@redhat.com>
Install a static symlink from the OS TLS/PKI trust store to the location that OpenShift uses for its CA certificate, instead of copying it at run-time. Signed-off-by: Jonathan Dowland <jdowland@redhat.com>
|
I don't think we need this anymore: I think OpenShift (4.1? 4.2?) is handling this via an operator. |
This module enables the trusting of CA certificates provided to
running containers by OpenShift.
At build-time: various system PKI paths are made world writeable-by-all,
in order that the random-UID runtime user can insert CA certificates
into the trusted store
At run-time: copy the CA file into place and invoke /usr/bin/update-ca-trust
To generate derivative trust stores (e.g. OpenSSL & Java JKS)
Signed-off-by: Jonathan Dowland jdowland@redhat.com
https://issues.jboss.org/browse/CLOUD-2689
Thanks for submitting your Pull Request!
Please make sure your PR meets following requirements:
[CLOUD-XYA] SubjectCONTRIBUTING.md)Signed-off-by: Your Name <yourname@redhat.com>- usegit commit -s