Can no longer pull with docker 1.8.1 if the user only has pull access #22
Comments
|
looking |
|
pushed new images, should be ok now |
|
Oh excellent! Thank you @rojer I will try it. |
|
Hmm, still not working for me, but I am not sure this is the issue. Here is the output of And my config file: server: # Server settings.
# Address to listen on.
addr: ":5001"
# TLS certificate and key.
certificate: "/certs/registry.crt"
key: "/certs/registry.key"
token: # Settings for the tokens.
issuer: "reg.local" # Must match issuer in the Registry config.
expiration: 900
# Static user map.
users:
# Password is specified as a BCrypt hash. Use htpasswd -B to generate.
"admin":
password: "$2y$05$SirvKgES6jlgIKDqElQgAu6.3d.czANNYnyPe6SJy4exvAW0cpUjW"
"avid":
# password is 12345678
password: "$2y$05$NZ694lx3DXadnm/Z3QXo9OVc5TFbAUSlYVjN4HvT.dDNDpdpUY3SC"
"avi2":
# password is 12345678
password: "$2y$05$NZ694lx3DXadnm/Z3QXo9OVc5TFbAUSlYVjN4HvT.dDNDpdpUY3SC"
"": {} # Allow anonymous (no "docker login") access.
acl:
# Admin has full access to everything.
- match: {account: "admin"}
actions: ["*"]
# User "avid" has full access to avid/* images
- match: {account: "avid", name: "avid/*"}
actions: ["*"]
# User "avi2" has full access to avi2/* images but nothing else.
- match: {account: "avid", name: "avi2/*"}
actions: ["*"]
# User "avid" has full access to it/* images
- match: {account: "avid", name: "it/*"}
actions: ["*"]
# All logged in users can pull all images.
- match: {account: "/.+/"}
actions: ["pull"]
# All anonymous users can pull all images.
- match: {account: ""}
actions: ["pull"]
# Access is denied by default.I am trying to push However, if I do an explicit That is true even if I try a non-existent scope. So the ? |
|
Hmm, same thing for an anonymous Strange that docker_auth is returning Any way to enable debugging on it? |
|
yes, add --v=2 and --alsologtostderr auth server command line |
|
Hmm, OK, so part of it was cached login information. I cleared it out, restarted all, and now it works at least partially. I cleared out the cache in
Here are the logs from docker_auth And from docker: |
|
And for the actual command: |
|
really weird. immediately after logging at line 250 of server.go we return the token with status 200, yet registry claims it got 401. huh? |
|
Yeah, that's what I thought. That's why I ran |
|
For some comparison, the output from the docker daemon when I try to login to the official registry: |
|
this is using v1 sorry, no idea - WFM with 1.8.1 and registry:2.0 and daemon's output: DEBU[0007] Calling POST /auth |
|
What do you get for the next line after `trying "bearer" "? I am running registry 2.0.1. Cannot imagine it matters, but try it? |
|
The fix worked for me using v2 and docker 1.8.1. We are using google authentication for pull but don't have anonymous pull enabled. and registry 2.1.1 |
|
nothing, that's the last line |
|
@silverbp what registry version? |
|
I updated my post but it's 2.1.1 |
|
we're using google authn too, but the authn method shouldn't matter, as that clearly succeeds - after "Authn static avid -> true" it's over with authn. |
|
Yes, quite. If it is returning |
|
but most of all i'm puzzled by this discrepancy: i can't see how auth server can return anything but 200, and yet registry reports 401. |
|
yeah, go figure... |
|
docker 1.8.1, registry 2.0.1 and 2.1.1, cesanta/docker_auth:latest, how can this be happening?? |
|
PEBKAC!! |
1 similar comment
|
PEBKAC!! |
|
@deitch ok, that happens. :) |
|
Sorry about that. Curious to know what it was? |
|
sure, do tell. probably talking to a different instance or something. |
|
I had copied over the registry yml from someplace else, and edited the environment, here is the relevant part. Do you see the type? :-( environment:
REGISTRY_AUTH: token
REGISTRY_AUTH_TOKEN_REALM: https://reg.local:5001/auth
REGISTRY_AUTH_TOKEN_SERVICE: reg.local
# HINT: LOOK AT THE NEXT LINE. SIGH!
REGISTRY_AUTH_TOKEN_ISSUER: my.reg.local
REGISTRY_AUTH_TOKEN_ROOTCERTBUNDLE: /certs/registry.crt |
|
Oops, I accidentally didn't change the token issuer. Sigh. Like I said, PEBKAC. |
|
all right. so it did get the token, but the issuer was wrong. makes sense. |
see
moby/moby#15640
I guess it's supposed to return the token with the appropriate rights and it's the registries responsibility to deny access.
Which makes since from an SSO kind of implementation with a JWT.
in 1.8.1 docker is requesting push and pull for just a pull, not sure why they changed that.
The text was updated successfully, but these errors were encountered: