feat(images): use imagePullSecret when pulling a private image #718
Conversation
|
Should we be manually testing this and if so how? |
Testing InstructionsPlease provide a detailed list for how to test the changes in this PR.
Also, please provide a description of the desired result after the tester completes the above steps.
|
|
One e2e caught a scenario I had not accounted for so I need to investigate that better, looks like I am missing a data guard somewhere |
helgi
force-pushed
the
image_secret
branch
2 times, most recently
from
5e38e49
to
9d8fa91
Compare
Current coverage is 84.60%@@ master #718 diff @@
==========================================
Files 29 29
Lines 2585 2649 +64
Methods 0 0
Messages 0 0
Branches 407 421 +14
==========================================
+ Hits 2214 2241 +27
- Misses 259 290 +31
- Partials 112 118 +6
|
|
|
Currently blocked on #721 |
|
moving to rc1 |
helgi
force-pushed
the
image_secret
branch
8 times, most recently
from
fcecece
to
cdceb0c
Compare
|
how is this blocked by #721? Just call |
|
controller/rootfs/api/models/release.py Line 113 in b13152a |
|
@bacongobbler that's not the point, I am aware of how the code works and how I could pull the image into the local registry. The point here is we are having k8s fully pulling images and dealing with the secrets but then having Controller pull the image into the insecure registry just to inspect a port, causing false sense of security and adding in additional download time and storage requirements. That's what is being discussed in #721 |
|
Right, but that's something we can implement later when we come to a conclusion on how we can resolve it. For now let's just follow what we've been doing since v1. Whether or not it's stored in the registry doesn't matter since the image is in the cluster anyways. |
|
Maybe what's being lost in translation here is that Authenticated External Registry is net new feature functionality as a fully support part of Deis (not a hack) so this scenario doesn't really compare to v1, which allowed for public only images (unless you copied configs over). Also, by default the port is Doing this post 2.0 wouldn't be very viable since you'd be moving the user from introspection to the above, so we couldn't do this until 3.0 |
use a k8s Secret to encode a '.docker/config.json' to completely bypass the Controller when it comes to images if a private registry is being used Handles the various possible errors coming from k8s and bubble that up through to the end user, similar to how the deis dockerclient can do. k8s adds more information on top of what docker gives so an error message bubbled up from this compared to when the Controller was handling the Docker interaction ref deis#639
… instead of auto discovering port Rationale here is to not pull down the image since Kubernetes now owns the downloading and interaction with the Private Registry. Pulling an image down into the Deis Registry will strip away the benefits of the security given. This change moves the docker port auto-discovery into the docker-client and general port handling into Release model, making the Scheduler unaware of the inherent logic. Ports are still auto-discovered on public images but when Private Registry is used the default port is 5000 and if the user wants to use a different one then they need to do config:set PORT=3000 Logic may change in the future where a user can use Private Registry but pull into the local registry, and get port auto-discovery, at the cost of security.
use a k8s Secret to encode a
.docker/config.jsonto completely bypass the Controller when it comes to images if a private registry is being usedHandles the various possible errors coming from k8s and bubble that up through to the end user, similar to how the deis dockerclient can do.
k8s adds more information on top of what docker gives so an error message bubbled up from this compared to when the Controller was handling the Docker interaction
ref #639