[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Inject Custom CA during builds



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 <ahmed aossama com <mailto:ahmed aossama com>> 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 <ahmed aossama com
    <mailto:ahmed aossama com>> 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
    users lists openshift redhat com
    <mailto:users lists openshift redhat com>
    http://lists.openshift.redhat.com/openshiftmm/listinfo/users
    <http://lists.openshift.redhat.com/openshiftmm/listinfo/users>


-- Regards,
    Ahmed Ossama


    _______________________________________________
    users mailing list
    users lists openshift redhat com
    <mailto:users lists openshift redhat com>
    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
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]