Uploaded image for project: 'OpenShift BuildConfig'
  1. OpenShift BuildConfig
  2. OCPBUILD-44

Dev Preview - User Namespace Builds

XMLWordPrintable

    • Dev Preview - User Namespace Builds
    • False
    • Hide

      None

      Show
      None
    • False
    • Done
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      * With this update, you can run builds within a user-namespaced container by default, as a Developer Preview feature. That is, in terms of the host, you can run a build as a non-root user. For instructions, see link:https://access.redhat.com/articles/6878201[Unprivileged OpenShift Builds (Developer Preview)] (link:https://issues.redhat.com/browse/BUILD-432[BUILD-432])
      Show
      * With this update, you can run builds within a user-namespaced container by default, as a Developer Preview feature. That is, in terms of the host, you can run a build as a non-root user. For instructions, see link: https://access.redhat.com/articles/6878201 [Unprivileged OpenShift Builds (Developer Preview)] (link: https://issues.redhat.com/browse/BUILD-432 [ BUILD-432 ])

      OCP/Telco Definition of Done
      Epic Template descriptions and documentation.

      <--- Cut-n-Paste the entire contents of this description into your new Epic --->

      Epic Goal

      • Run OpenShift builds that do not execute as the "root" user on the host node.

      Why is this important?

      • OpenShift builds require an elevated set of capabilities to build a container image
      • Builds currently run as root to maintain adequate performance
      • Container workloads should run as non-root from the host's perspective. Containers running as root are a known security risk.
      • Builds currently run as root and require a privileged container. See BUILD-225 for removing the privileged container requirement.

      Scenarios

      1. Run BuildConfigs in a multi-tenant environment
      2. Run BuildConfigs in a heightened security environment/deployment

      Acceptance Criteria

      • Developers can opt into running builds in a cri-o user namespace by providing an environment variable with a specific value.
      • When the correct environment variable is provided, builds run in a cri-o user namespace, and the build pod does not require the "privileged: true" security context.
      • User namespace builds can pass basic test scenarios for the Docker and Source strategy build.
      • Steps to run unprivileged builds are documented.

      Dependencies (internal and external)

      1. Buildah supports running inside a non-privileged container
      2. CRI-O allows workloads to opt into running containers in user namespaces.

      Previous Work (Optional):

      1. BUILD-225 - remove privileged requirement for builds.

      Open questions::

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

              rhn-engineering-nalin Nalin Dahyabhai
              adkaplan@redhat.com Adam Kaplan
              Votes:
              0 Vote for this issue
              Watchers:
              16 Start watching this issue

                Created:
                Updated:
                Resolved: