> On 17 Jul 2018, at 10:50 pm, Ben Parees <[email protected]> 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
>
> <https://docs.openshift.org/latest/dev_guide/builds/build_inputs.html#using-secrets-s2i-strategy>
That documentation is misleading as I understand it.
The destination directory does not need to exist.
The requirement is that all parent directories down to the destination
directory need to exist.
So:
"source": {
"binary": {},
"secrets": [
{
"destinationDir": "/tmp/build",
"secret": {
"name": "mysecret"
}
}
],
"type": "Binary"
},
is okay as /tmp exists, even though /tmp/build doesn't.
It yields:
+ ls -las /tmp/build
total 0
0 drwxr-xr-x. 3 root root 70 Jul 17 22:01 .
0 drwxrwxrwt. 1 root root 66 Jul 17 22:01 ..
0 drwxrwxrwx. 2 root root 17 Jul 17 22:01 ..2018_07_17_22_01_08.125432697
0 lrwxrwxrwx. 1 root root 31 Jul 17 22:01 ..data ->
..2018_07_17_22_01_08.125432697
0 lrwxrwxrwx. 1 root root 10 Jul 17 22:01 key -> ..data/key
But:
"source": {
"binary": {},
"secrets": [
{
"destinationDir": "/tmp/build/subdir",
"secret": {
"name": "mysecret"
}
}
],
"type": "Binary"
},
will fail as /tmp/build doesn't exist.
error: Uploading to container failed: Error response from daemon:
{"message":"lstat
/var/lib/docker/overlay2/38b6aa3a51dd7f3d6d8dd4fe58025562e81086d78d88cff347a4ce1c76d868da/merged/tmp/build:
no such file or directory"}
ERROR: The destination directory for
"/var/run/secrets/openshift.io/build/mysecret" injection must exist in
container ("/tmp/build/subdir")
Graham
> 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
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
