-
Notifications
You must be signed in to change notification settings - Fork 4.7k
[DO NOT MERGE] Handle cross repository mount #9582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -90,7 +91,7 @@ var ( | |||
) | |||
|
|||
func newAccessController(options map[string]interface{}) (registryauth.AccessController, error) { | |||
log.Info("Using Origin Auth handler") | |||
log.Info("using Origin Auth handler") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why changing that, only errors start with small letter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, most of the upstream log messages are lower-cased. In v2.4.1 it's 33 messages starting with upper-cased letter vs 81 starting with lower-cased (all log levels).
But ok, keeping the messages same won't do any harm. I'll lower-case the new messages though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is part of origin code in which the patterns I've mentioned apply.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is part of origin code in which the patterns I've mentioned apply.
Yes, but the message appears only in registry's logs. Another reason for having registry in its own repository 😄.
Nits, but overall LGTM. |
LGTM |
LGTM, squash and you're good to go. |
ab83d21
to
7940966
Compare
@soltysh thanks! squashed. |
(I'd still rather wait for a clean pass though) |
Your wish is my command! I'll merge once this turns green. |
// | ||
// This function always grants access in the first case because OpenShift registry treats all the local blobs | ||
// as accessible once authorized to access given repository (target one). | ||
func isCrossRepoMountFromSourceRepository(ctx context.Context, namespace, imageRepo, verb string) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how are we guaranteeing that the access check has already been performed on the imageRepo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's upstream's responsibility to do auth check for both repositories (source and target). See here: https://github.com/openshift/origin/blob/master/Godeps/_workspace/src/github.com/docker/distribution/registry/handlers/app.go#L771. The source check is done first. The second check will decide whether the user is authorized to push.
i've added extended test requests for tests that i think were broken by the recent registry changes. |
7940966
to
c78781b
Compare
@@ -196,7 +197,7 @@ func (ac *AccessController) Authorized(ctx context.Context, accessRecords ...reg | |||
} | |||
verifiedPrune = true | |||
default: | |||
if err := verifyImageStreamAccess(ctx, imageStreamNS, imageStreamName, verb, osClient); err != nil { | |||
if err := authorizeRepositoryAccess(ctx, imageStreamNS, imageStreamName, verb, osClient); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather see this loop be aware of access records being skipped because they appear to be cross-repository mounts... if we skip an access record for that reason, this loop should ensure it is paired with an authorized push access record check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's reasonable, I'll change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
actually, if I understand this correctly, this would allow a client to do the following:
|
c78781b
to
c823e8c
Compare
func (r *pullthroughBlobStore) Create(ctx context.Context, options ...distribution.BlobCreateOption) (distribution.BlobWriter, error) { | ||
options = append(options, storage.WithRepositoryMiddlewareWrapper( | ||
func(ctx context.Context, repo distribution.Repository, name reference.Named) (distribution.Repository, error) { | ||
nameParts := strings.SplitN(name.Name(), "/", 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want to artificially limit the segments to 2, or fail if they give us something with more than 2 segments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're doing it the same way on most other places. And AFAIK upstream registry doesn't support more than 2 segments either. We could create a utility function to do this. But I wouldn't clobber this with such a refactor.
c823e8c
to
9892109
Compare
I changed the behavior to the old one. Now the first auth check for source repository is skipped in the auth module. The auth check has been moved to repository middleware. If the check fails (most of the time), the registry falls back to a blob upload (sends If we were doing both checks in the auth module, the registry would return unathorized which would cancel whole push. For this, we need to propagate our middleware code to upstream blob store during a This doesn't attempt to fix the cross-repo mount by checking for blob presence in source repository. The blob checking needs to be done at several other places. We should fix it together with #7792. Until then, let's keep the old behavior. |
continuous-integration/openshift-jenkins/test Running (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/5501/) |
rather than skipping errors during auth, what if we store ones that look like cross-mount errors in the context. then, in the repository impls, we can first check to ensure auth ran, then short-circuit any operations for a given repo if there were deferred errors. see #9593 for a quick POC. that would make me a lot more comfortable deferring enforcement of some auth errors, and being confident that no API path was going to hit a repository interface method we didn't expect |
9892109
to
fb49049
Compare
Evaluated for origin test up to fb49049 |
…pper during cross-repo mounts This allows to use pullthroughBlobStore middleware wrapper during a cross-repository mount. This is an upstream part of fix to enable remote layer federation for the push. Signed-off-by: Michal Minar <[email protected]>
This allows us to: - do additional authorization checks during cross-repo mount on source repository - remote layer federation Signed-off-by: Michal Minar <[email protected]>
fb49049
to
3199a57
Compare
continuous-integration/openshift-jenkins/testextended Running (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin_extended/253/) (Extended Tests: core(images), core(builds)) |
[testextended][extended:core(images)] |
(bot does not seem to respect two testextended tags in one comment?) |
Evaluated for origin testextended up to 3199a57 |
[testextended][extended:core(builds)] |
closing in favor of #9593 |
closing in favor of #9593 |
During a push with a cross-repo mount, authorize only against target
repository, not against source repository.
In OpenShift we allow to pull any blob stored in the registry as long as
the user is authorized to pull from repository he requested.
Closes #9540
Not sure whether #6841 is close-able with this. The issue mentions proper association of credentials with repositories (and especially the remote once if a pull through is in play). I'll verify.