Bug 1648775
Summary: | [3.10] Binary builds are not automatically including the pull secret from the service account during the build. | |||
---|---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Jaspreet Kaur <jkaur> | |
Component: | Build | Assignee: | Ben Parees <bparees> | |
Status: | CLOSED ERRATA | QA Contact: | wewang <wewang> | |
Severity: | urgent | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 3.10.0 | CC: | aos-bugs, bparees, florin.peter, jkaur, sauchter, wzheng | |
Target Milestone: | --- | |||
Target Release: | 3.10.z | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Enhancement | ||
Doc Text: |
Feature: Builds that do not explicitly indicate the docker image they consume (by providing an inline dockerfile or defining the docker strategy's From field) and do not explicitly indicate a pull secret to use, will now use the build's service account's docker secret by default. Examples of such builds would be a build that includes a Dockerfile in a git repo.
Reason: Previously these builds would use no secret and potentially fail if the base image was not public.
Result: Those builds will now succeed without the need to either explicitly specify a pull secret, or explicitly specify the base image in the buildconfig.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1649062 1649063 (view as bug list) | Environment: | ||
Last Closed: | 2018-12-13 17:09:08 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1649062, 1649063 |
Description
Jaspreet Kaur
2018-11-12 06:05:09 UTC
Does this occur w/ a non-binary build? The k8s documented behavior has no bearing on this because builds must do their own determination of what secret to use because builds can reference images in different ways than pods do, and the secrets that k8s mounts into the build pod are not the secrets the build will use. I do not think this is specific to binary builds. Any build where you have not explicitly told us in the buildconfig, what image you will be referencing, will have this issue. The build must make the decision, prior to starting the build pod, what secrets to mount into the build pod so that docker can pull the images. Since we don't know what your dockerfile looks like until after the build pod starts (at which point the dockerfile is either streamed in (binary build) or git cloned(normal build)), we can't mount it in advance. Yes, it is technically possible that we can fallback to using the builder service account's docker secret in this scenario, but that will only solve the problem for builds that reference the internal registry. You would still have this problem if you referenced some other private registry. As you've noted, the solutions are either: 1) explicitly indicate the image you want to reference via the buildconfig's From field 2) explicitly indicate the secret you want to use to pull the image via the buildconfig's pullsecret field. I will work an update that causes us to fallback to the service account's docker secret(if available) when we have no other information about what image is being pulled (as is the case here), but you will still have problems if you reference some other private registry in this way, so it would really be better to solve this in what I consider to be the correct way: reference a secret you know can pull the image. Verified in openshift version: v3.10.79, allow the service accounts in fptest namespace to pull images from the base namespace, build can be complete $ oc get builds --watch ruby-ex-1 Source Git@887f01c Complete About a minute ago 1m19s build logs: https://url.corp.redhat.com/5303f10 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3750 |