-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Docker digest validation is too strict #32627
Docker digest validation is too strict #32627
Conversation
@eparis if you want to normal cherry-pick we can use this one - I wanted to make sure the patch compiled against 1.4 which is why I opened the other PR |
LGTM |
Removing label |
Hold until I validate in the morning whether Docker 1.10 is correctly setting RepoDigest on all supported versions. |
3657594
to
28e8dc3
Compare
Updated to use RepoDigest first, use stricter parsing (which could break if Docker updates, but prevents us from missing string format changes). I would prefer to use the Docker structures (since we already are for parsing the ref) so as to avoid potential prefix attacks due to comparison. |
All 3 major RHEL versions and 2 fedora versions I tested returned RepoDigest. |
Nevermind, I read Clayton's last comment |
Hold for re-review with the new code approach |
This is ready for re-review |
if d, isDigested := named.(dockerref.Digested); isDigested { | ||
// Allow prefix matches for shorter SHA values | ||
if digest.Digest().Algorithm().String() == d.Digest().Algorithm().String() && | ||
strings.HasPrefix(digest.Digest().Hex(), digest.Digest().Hex()) { |
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.
Shouldn't one of these digest
s be d
?
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.
Yes
28e8dc3
to
0c9e994
Compare
0c9e994
to
331a841
Compare
continue | ||
} | ||
if d, isDigested := named.(dockerref.Digested); isDigested { | ||
// Allow prefix matches for shorter SHA values |
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.
nit: remove the comment.
lgtm. just a nit to remove the outdated comment. |
331a841
to
95cee6e
Compare
Nit fixed On Wed, Sep 14, 2016 at 12:24 PM, Yu-Ju Hong notifications@github.com
|
Thanks a lot for fixing this! |
Removing lgtm b/c of 1 issue which I'll comment on shortly |
} | ||
if d, isDigested := named.(dockerref.Digested); isDigested { | ||
if digest.Digest().Algorithm().String() == d.Digest().Algorithm().String() && | ||
digest.Digest().Hex() == digest.Digest().Hex() { |
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.
double digest
again
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.
good catch. Add a unit test?
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.
Just as an FYI, if we get into this for loop, it means:
pod.containers[i].image
is digested- the image exists on the node
- the kubelet was able to
docker inspect
the image using the digest
It should be impossible to get here and not have a match between pod.containers[i].image
and the value from RepoDigests
.
We should be defensive, so I'm not suggesting we remove or change anything here. Just an FYI
Docker 1.10 does not guarantee that the pulled digest matches the digest on disk when dealing with v1 schemas stored in a Docker registry. This is the case for images like centos/ruby-23-centos7@sha256:940584acbbfb0347272112d2eb95574625c0c60b4e2fdadb139de5859cf754bf which as a result of kubernetes#30366 cannot be pulled by Kube from a Docker 1.10 system. Instead, use RepoDigests field as the primary match, validating the digest, and then fall back to ID (also validating the match). Adds more restrictive matching.
95cee6e
to
4a48bf8
Compare
Updated with all comments. |
LGTM |
@smarterclayton I'll create a cherrypick PR using the script. |
Thanks On Wed, Sep 14, 2016 at 2:24 PM, Yu-Ju Hong notifications@github.com
|
GCE e2e build/test passed for commit 4a48bf8. |
Automatic merge from submit-queue |
Automatic merge from submit-queue Docker digest validation is too strict Docker 1.10 does not guarantee that the pulled digest matches the digest on disk when dealing with v1 schemas stored in a Docker registry. This is the case for images like centos/ruby-23-centos7@sha256:940584acbbfb0347272112d2eb95574625c0c60b4e2fdadb139de5859cf754bf which as a result of kubernetes#30366 cannot be pulled by Kube from a Docker 1.10 system. This partially reverts commit 875fd16. (cherry picked from commit b841a8b)
Commit found in the "release-1.4" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked. |
Automatic merge from submit-queue Docker digest validation is too strict Docker 1.10 does not guarantee that the pulled digest matches the digest on disk when dealing with v1 schemas stored in a Docker registry. This is the case for images like centos/ruby-23-centos7@sha256:940584acbbfb0347272112d2eb95574625c0c60b4e2fdadb139de5859cf754bf which as a result of kubernetes#30366 cannot be pulled by Kube from a Docker 1.10 system. This partially reverts commit 875fd16. (cherry picked from commit b841a8b)
Docker 1.10 does not guarantee that the pulled digest matches the digest
on disk when dealing with v1 schemas stored in a Docker registry. This
is the case for images like
centos/ruby-23-centos7@sha256:940584acbbfb0347272112d2eb95574625c0c60b4e2fdadb139de5859cf754bf
which as a result of #30366 cannot be pulled by Kube from a Docker 1.10
system.
This partially reverts commit 875fd16.
This change is