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
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" injection must
exist in container ("/etc/ssl/certs")
I tried changing the destinationDir to /etc/certs, and the build passed
the above error but yet failed to connect to the repositories.
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
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
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
--
Regards,
Ahmed Ossama
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
