CLOUD-2689: jboss.container.java.certs module #312
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,10 @@ | ||
| #!/bin/sh | ||
| set -e | ||
|
|
||
| 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! |
||
| /usr/bin/update-ca-trust | ||
| fi | ||
| fi | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| #!/bin/sh | ||
| # Configure module | ||
| set -e | ||
|
|
||
| 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 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 |
||
| chmod 777 \ | ||
| /etc/pki/ca-trust/extracted/openssl \ | ||
| /etc/pki/ca-trust/extracted/java \ | ||
| /etc/pki/ca-trust/source/anchors \ | ||
| /etc/pki/ca-trust/extracted/pem | ||
|
|
||
| d=/opt/jboss/container/java/certs | ||
| mkdir -p "$d" | ||
| cp "${ARTIFACTS_DIR}/trust-ose-cert.sh" "$d" | ||
| chmod +x "$d/trust-ose-cert.sh" | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| schema_version: 1 | ||
| name: jboss.container.java.certs.bash | ||
| version: '1.0' | ||
| description: Trust runtime-supplied OpenShift/Kubernetes CA | ||
|
|
||
| envs: | ||
| - name: JAVA_DISABLE_TRUST_OPENSHIFT_CA | ||
| example: true | ||
| description: When defined, the container will not automatically trust a CA certificate provided by OpenShift at run-time. | ||
|
|
||
| execute: | ||
| - script: configure.sh | ||
| user: root |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed