Maybe you can try to replace/add files inside
> /etc/pki/ca-trust/extracted/
You can prepare the files on a real machine and then copy them over to
containers as secrets.
P.S. SSL was invented exactly to prevent man in the middle (what the
appliance is presently doing) as far as I can tell. While there might be
legitimate use cases they would be mostly limited to the situation where
the user and the intercepting appliance owner is the same person/company.
Ahmed Ossama wrote on 07/17/18 17:14:
So I inspected the container runtime, and it turns out to be that
/etc/ssl/certs is a sym link to /etc/pki/tls/certs directory.
Modifiying the destinationDir caused the certificate to be injected, but
the build process is still failing because the certificate is not in the
global trusted CAs in the container.
Did anyone come across an issue like this where the outbound internet
connection going to an appliance that inspects the traffic and injecting
it's own certificate?
On 07/17/2018 08:50 AM, Ben Parees wrote:
On Tue, Jul 17, 2018 at 5:06 AM, Ahmed Ossama <[email protected]
<mailto:[email protected]>> wrote:
For option #1, I granted the sa/builder the anyuid scc, and added
the serviceAccount: builder in the buildconfig. I thought this
might make the build run with root (Yes, it's not a good idea to
run builds using root, I was just trying it), but it didn't work
anyway.
For option #2, I've created the secret with:
$ oc create secret generic root-certificate
--from-file=RootCertificate-2048-SHA256.crt=RootCertificate-2048-SHA256.crt
Then edited the bc to:
source:
git:
ref: c967a614ca0429ef219e884ae1b2ff6e447449d8
uri:
http://gitlab.example.com/public-projects/java-blueprint.git
<http://gitlab.example.com/public-projects/java-blueprint.git>
secrets:
- destinationDir: /etc/ssl/certs
secret:
name: root-certificate
type: Git
So this causes the build to fail with the error:
error: Uploading to container failed: Error response from daemon:
{"message":"Error processing tar file(exit status 1): mkdir
/certs/..2018_07_17_00_07_32.144170643: no such file or directory"}
ERROR: The destination directory for
"/var/run/secrets/openshift.io/build/root-certificate
<http://openshift.io/build/root-certificate>" injection must exist
in container ("/etc/ssl/certs")
the docs make this behavior clear:
"The |destinationDir| must exist or an error will occur. No directory
paths are created during the copy process."
https://docs.openshift.org/latest/dev_guide/builds/build_inputs.html#using-secrets-s2i-strategy
I tried changing the destinationDir to /etc/certs, and the build
passed the above error but yet failed to connect to the repositories.
presumably this created a directory named "/etc/certs" containing a
file for each key in your secret. Your build logic would need to
reference /etc/certs/<keyname> as the CA input file.
Is there another way to inject the CA during the builds? Or this
is the only way?
On 07/16/2018 09:49 PM, Graham Dumpleton wrote:
The first will not work because you aren't root when a build
occurs so can't copy files to locations which require root access.
For the second option, how has the build secret been set up in
the build config? Specifically, what does the spec.source.secrets
part of the build config look like, and what keys are defined in
the secret?
$ oc explain bc.spec.source.secrets
RESOURCE: secrets <[]Object>
DESCRIPTION:
secrets represents a list of secrets and their destinations
that will be
used only for the build.
SecretBuildSource describes a secret and its destination
directory that
will be used only at the build time. The content of the
secret referenced
here will be copied into the destination directory instead
of mounting.
FIELDS:
destinationDir<string>
destinationDir is the directory where the files from the
secret should be
available for the build time. For the Source build strategy,
these will be
injected into a container where the assemble script runs.
Later, when the
script finishes, all files injected will be truncated to
zero length. For
the Docker build strategy, these will be copied into the
build directory,
where the Dockerfile is located, so users can ADD or COPY
them during
docker build.
secret<Object> -required-
secret is a reference to an existing secret that you want to
use in your
build.
$ oc explain bc.spec.source.secrets.secret
RESOURCE: secret <Object>
DESCRIPTION:
secret is a reference to an existing secret that you want to
use in your
build.
LocalObjectReference contains enough information to let you
locate the
referenced object inside the same namespace.
FIELDS:
name<string>
Name of the referent. More info:
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
<https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names>
Graham
On 17 Jul 2018, at 9:16 am, Ahmed Ossama <[email protected]
<mailto:[email protected]>> wrote:
Hi Everyone,
I have an OpenShift installation which is sitting behind an
appliance which intercepts outbound SSL traffic. Regular
machines have the SSL certificate of the appliance installed on
them and they are able to access the internet without any issues.
My issue is with during the build; Because OpenShift builds
images in containers, thus the container which is building the
code doesn't have the SSL certificate of the interceptor
installed in it. So grabbing code dependencies from npm, maven
or pypi during a build fails because the build tries to connect
to the repo manager via HTTPs, but since the CA of the
interceptor is not installed in the build container it fails.
My question is: How can I inject the CA certificate of the
interceptor in the build container so that the traffic from the
interceptor is trusted?
So far I've tried two options but they failed:
Option #1, have customized .s2i/bin/assemble script which
downloads the certificate in /etc/pki/ca-trust/source/anchors/
and running update-ca-trust. But this option fails with:
$ oc logs dsqc-4-build
% Total % Received % Xferd Average Speed Time Time
Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:--
--:--:-- 0Warning: Failed to create the file
Warning:
/etc/pki/ca-trust/source/anchors/ZscalerRootCertificate-2048-SHA256.cr
Warning: t: Permission denied
52 1732 52 901 0 0 14515 0 --:--:-- --:--:--
--:--:-- 14770
curl: (23) Failed writing body (0 != 901)
p11-kit: couldn't create file:
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:
Permission denied
p11-kit: couldn't create file:
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem: Permission denied
p11-kit: couldn't create file:
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem: Permission
denied
p11-kit: couldn't create file:
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem:
Permission denied
p11-kit: couldn't create file:
/etc/pki/ca-trust/extracted/java/cacerts: Permission denied
/tmp/scripts/assemble: line 14: /tmp/scripts/s2i-setup: No such
file or directory
error: build error: non-zero (13) exit code from
registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift@sha256:6c009f430da02bdcff618a7dcd085d7d22547263eeebfb8d6377a4cf6f58769d
<http://registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift@sha256:6c009f430da02bdcff618a7dcd085d7d22547263eeebfb8d6377a4cf6f58769d>
Option #2: following the steps detailed in
https://docs.openshift.com/container-platform/3.9/dev_guide/builds/build_inputs.html#using-secrets-during-build
<https://docs.openshift.com/container-platform/3.9/dev_guide/builds/build_inputs.html#using-secrets-during-build>
but it fails with the error:
$ oc logs po/dsqc-5-build
error: Uploading to container failed: Error response from
daemon: {"message":"Error processing tar file(exit status 1):
mkdir /certs/..2018_07_16_23_14_03.650131122: no such file or
directory"}
ERROR: The destination directory for
"/var/run/secrets/openshift.io/build/root-certificate
<http://openshift.io/build/root-certificate>" injection must
exist in container ("/etc/ssl/certs")
Any help is extremely appreciated.
--
Regards,
Ahmed Ossama
_______________________________________________
users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
<http://lists.openshift.redhat.com/openshiftmm/listinfo/users>
--
Regards,
Ahmed Ossama
_______________________________________________
users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
<http://lists.openshift.redhat.com/openshiftmm/listinfo/users>
--
Ben Parees | OpenShift
--
Regards,
Ahmed Ossama
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
