Giter Club home page Giter Club logo

docker_auth's People

Contributors

adamdecaf avatar alekseiapa avatar andsens avatar carsonoid avatar cpq avatar dhrp avatar duyanghao avatar germaino avatar imax9000 avatar jrodbeta avatar karmi avatar kcd83 avatar kwk avatar mgenov avatar mikecook avatar mrueg avatar mtronrd avatar raphink avatar robinschneider avatar rojer avatar roman-vynar avatar schegi avatar segevfiner avatar strayer avatar summerqlin avatar techknowlogick avatar tharindulak avatar trutx avatar tsl0922 avatar yc avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

docker_auth's Issues

UNAUTHORIZED when visit via browser


docker_auth and registry were up successfully. but when i try to visit the registry by chrome, i get follwing error, is this work with registry version 2.3.1?

error info:
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"registry","Name":"catalog","Action":"*"}]}]}

-the container's log as following:

root@ubu89:/var/lib/docker/containers/2c3cdb37bb770574860623cb4e8bac1c90ce12d087338478260c5164e3ef395f# cat 2c3cdb37bb770574860623cb4e8bac1c90ce12d087338478260c5164e3ef395f-json.log
{"log":"time="2016-03-22T08:28:48Z" level=warning msg="No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable." go.version=go1.5.3 instance.id=1dbd103a-8580-45f4-9783-b11040c376ca version=v2.3.1 \n","stream":"stdout","time":"2016-03-22T08:28:48.184011866Z"}
{"log":"time="2016-03-22T08:28:48Z" level=info msg="redis not configured" go.version=go1.5.3 instance.id=1dbd103a-8580-45f4-9783-b11040c376ca version=v2.3.1 \n","stream":"stdout","time":"2016-03-22T08:28:48.184337501Z"}
{"log":"time="2016-03-22T08:28:48Z" level=info msg="Starting upload purge in 35m0s" go.version=go1.5.3 instance.id=1dbd103a-8580-45f4-9783-b11040c376ca version=v2.3.1 \n","stream":"stdout","time":"2016-03-22T08:28:48.184922941Z"}
{"log":"time="2016-03-22T08:28:48Z" level=info msg="using inmemory blob descriptor cache" go.version=go1.5.3 instance.id=1dbd103a-8580-45f4-9783-b11040c376ca version=v2.3.1 \n","stream":"stdout","time":"2016-03-22T08:28:48.186249676Z"}
{"log":"time="2016-03-22T08:28:48Z" level=info msg="listening on [::]:5000" go.version=go1.5.3 instance.id=1dbd103a-8580-45f4-9783-b11040c376ca version=v2.3.1 \n","stream":"stdout","time":"2016-03-22T08:28:48.187164777Z"}
{"log":"time="2016-03-22T08:29:21Z" level=warning msg="error authorizing context: authorization token required" go.version=go1.5.3 http.request.host="10.62.99.89:5000" http.request.id=aa394ded-3de7-4b22-901a-eecddde06849 http.request.method=GET http.request.remoteaddr="10.60.69.15:51293" http.request.uri="/v2/_catalog" http.request.useragent="Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36" instance.id=1dbd103a-8580-45f4-9783-b11040c376ca version=v2.3.1 \n","stream":"stdout","time":"2016-03-22T08:29:21.355424343Z"}
{"log":"10.60.69.15 - - [22/Mar/2016:08:29:21 +0000] "GET /v2/_catalog HTTP/1.1" 401 134 "" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36"\n","stream":"stdout","time":"2016-03-22T08:29:21.355636089Z"}
{"log":"time="2016-03-22T08:33:44Z" level=warning msg="error authorizing context: authorization token required" go.version=go1.5.3 http.request.host="10.62.99.89:5000" http.request.id=505a6a57-d4dd-45cd-a39d-96d8c5a38e2d http.request.method=GET http.request.remoteaddr="10.60.69.15:51293" http.request.uri="/v2/_catalog" http.request.useragent="Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36" instance.id=1dbd103a-8580-45f4-9783-b11040c376ca version=v2.3.1 \n","stream":"stdout","time":"2016-03-22T08:33:44.62841023Z"}
{"log":"10.60.69.15 - - [22/Mar/2016:08:33:44 +0000] "GET /v2/_catalog HTTP/1.1" 401 134 "" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36"\n","stream":"stdout","time":"2016-03-22T08:33:44.62897301Z"}
root@ubu89:/var/lib/docker/containers/2c3cdb37bb770574860623cb4e8bac1c90ce12d087338478260c5164e3ef395f#

Support requests for multiple scopes

Per moby/moby#20387:

  1. cesanta/docker_auth only understands a single scope query parameter, and the docker engine is requesting push/pull for the repository you are pushing to and pull access for the repository you're mounting the blob from. This means you request both scopes and the auth server only returns a token with the single repository scope.

...

I can address issue number 2 so that it immediately falls back to pushing the blob on auth failure, specifically for the case of a cross-repo push, but I'd recommend filing an issue with cesanta/docker_auth to support this workflow.

auth-server not connecting to secure mongodb replicated cluster

Configured the auth-server same as the example with details modified to connect to my replicated mongodb cluster, we are seeing the following error,

Failed to create auth server: not authorized for query on dockdb.auth
{"log":"F0302 15:49:50.027015       1 main.go:46] Failed to create auth server: not authorized for query on

The mongodb cluster has internal authentication and my other java app is able to connect to the same without issues using the credentials, unable to do that through docker-auth.

Anyone has any experience with mongo auth ?

OpenID Connect Support?

You have Google authentication, and with just a little more work, you could support OpenID Connect. Google's server is almost compliant--they don't support dynamic client registration. I bet a lot of companies that use Docker don't want to rely on a central consumer IDP like Google, but would rather run their own authentication service with something more modern than LDAP (which is limited to username / password). My company makes a fully compliant free open source OpenID Connect Provider that is easy to deploy called the Gluu Server. We don't program Go, but we'd be happy to help you if you have any questions about how to setup a test server. Although it is ridiculously easy--apt-get install and run a setup program...

Bad regex pattern from mongo shuts the entire server down

I am running several instances of the auth server in production and I need to acl fetching to be more robust. Right now one bad acl entry will shut the entire server until manually restarted. Ideally bad rules will simply be ignored and the rest of the ACLs will continue to load. I'm happy and ready to write the code myself but I want your input on policy before I do anything. Maybe we could have a optional error collection in mongo where we can stick reports of failed ACL loads? I want to do something besides silently fail and crash the server. This was/is not an issue when using hard coded acls but is quickly becoming a problem when using mongo to back everything.

BTW thanks for the otherwise great little server!

either ServerName or InsecureSkipVerify must be specified in the tls.Config

I'm attempting to get LDAP auth working and I'm getting this error

authn #1 returned error: LDAP Result Code 200 "": tls: either ServerName or InsecureSkipVerify must be specified in the tls.Config

Things do work if I set InsecureSkipVerify, but for obvious reasons I'd rather not. I cam across this which suggests it may not be supported yet.

I also seems I can not directly manipulate tls.Config Is it possible to set ServerName currently via configuration?

Thanks

Not able to search images with "docker search"

Hi everyone,

I set up the auth. server and it is working really well with the pull/push requests.
The only missing part is the "docker search" part.
I added my private registry in the docker config (--add-registry) but I'm not able to run the search.

I can see this error-message with every search-request in the registry-logs:
registry_1 | time="2015-12-08T14:29:59Z" level=warning msg="error authorizing context: authorization token required"

Any hint from your side?
Thanks in advance!

Question about compiling

Dear @rojer
Dockerfile is under auth_server folder.
So , ADD auth_server / in Dockerfile seems to lead compiling failed.
compiling is OK when i move dockerfile to upper folder.
However, container running will be failed:
run command

$sudo docker run \
   --rm -it --name docker_auth -p 5001:5001 \
   -v /go/src/github.com/cesanta/docker_auth/auth_server/config:/config:ro \
   -v /var/log/docker_auth:/logs \
   -v /go/src/github.com/cesanta/docker_auth/auth_server/certs:/path/to/certs:ro \
   cesanta/docker_auth /config/auth_config.yml

error:

exec: "/auth_server": permission denied
FATA[0000] Error response from daemon: Cannot start container 9eb651d5c27dc32116a5ae06900e56dac54acfe0d82197ea4026ff3c745b0a3e: [8] System error: exec: "/auth_server": permission denied 

same running is OK when i use image cesanta/docker_auth on Docker Hub.
If I made mistake?

Using {account} variable in ACLs and Oauth

Hello everyone!

When I am trying to use a match like:
{account: "/.+/", name: "${account}/*"}

and when I want to use it together with google_auth I am having such an issue:

root@dockercli:~# docker tag a5a467fddcb8 registry.somedomain.org/[email protected]/ubuntu-test
FATA[0000] Error response from daemon: Illegal tag name (somedomain.com/ubuntu-test): only [A-Za-z0-9_.-] are allowed, minimum 1, maximum 128 in length

and I can't push it anyhow to registry. To be able to push it I have to include my full e-mail to registry path.

Thanks for great project and I would appreciate your help.

Example of non-tls config?

Is there an example config for using the non-tls config option merged in #25?

@rojer, @dkjer I see that this has been merged, but how does one set up the registry config to use this? The registry config hard requries a rootcertbundle, but if TLS is disabled, what do we put there?

I'm also looking at doing TLS termination on the ELB rather than in the auth server.

Could you provide examples of both the registry config and the auth server config?

Also, has this been released to the public docker hub repo?

Thanks!!!

LDAP group matching example?

Can someone give me a hint on how I would write the config to source authentication from LDAP, and then specify access control based on group?

Essentially I want members of the developer group to be able to pull images but not push them (so nobody accidentally clobbers a production image).

Also, I was able to get registry v2 negotiating TLS and authentication with a basic auth backend, and it works like a charm. So thanks! (I didn't it using puppet and systemd unit files, if anyone is interested in example snippets of how that's done),

RBAC support in acls

I've been thinking a lot about acls and access control at scale. It seems to me that needing to support RBAC is inevitable. gorbac is available and could be used to load in roles from Mongo, static, and ldap sources. In my mind it would work the same way as ACLs do now where we refresh them on a regular basis and hold them in memory for validation.

Roles would go hand-in-hand with ACLs, with the ACLs functioning more as high-level rules and roles providing the more fluid and fine-grained control.

I'd be willing to code it, but I'm interested in input from others about what we would want out of role based access.

Handler for POST /auth returned error: no successful auth challenge for <myserver:5000/v2/

Hi All,
I'm needing your help to understand why the authorization server setup is not working for us. I am using Docker 1.8.2 and trying to integrate Cesanta's authorization server with Docker Registry (v.2.1.1) . For this integration purpose I am using the following reference http://the.binbashtheory.com/creating-private-docker-registry-2-0-with-token-authentication-service/. For authentication I am using exactly the same "authorize_config.yml" described in the link of course replacing the htpasswd password accordingly. Unfortunately I am getting always this error ..."Error response from daemon: no successful auth challenge for http://docker-myserver.com:5000/v2/ - errors: [token auth attempt for registry http://docker-myserver.com:5000/v2/: https://myserver.com:5001/auth?account=admin&service=Docker+registry request failed with status: 401 Unauthorized]. In the Authorization server log I can't see any message. Please let me know if you have any suggestion or need more information regarding to my setup.

Command used
$ docker login docker-myserver.com:5000

Launching Docker Registry:
docker run -d -p 5000:5000
--restart="always" --name "registrytoken"
-v pwd/config.yml:/etc/docker/registry/config.yml
-v /root/auth_server/ssl:/ssl
-v /root/docker_registry/data:/var/lib/registry
-e "REGISTRY_AUTH=token"
-e "REGISTRY_AUTH_TOKEN_REALM=https://docker-myserver.com:5001/auth"
-e "REGISTRY_AUTH_TOKEN_SERVICE=Docker registry"
-e "REGISTRY_AUTH_TOKEN_ISSUER=Auth Service"
-e "REGISTRY_AUTH_TOKEN_ROOTCERTBUNDLE=/ssl/server.pem"
-v /root/auth_server/ssl:/ssl
registry:2.1.1

Launching Authorization Server:
docker run -d --name docker_auth -p 5001:5001
-v pwd/auth_server/config:/config:ro
-v /var/log/docker_auth:/logs
--restart=always
-v pwd/auth_server/ssl:/ssl cesanta/docker_auth /config/auth_config.yml

Thanks in advance

JC

When creating a token, 'not before' is really necessary?

If the time of running this server (for example, my local PC) is different with time of docker registry (on IDC), token will be failed to verify, because of nbf(not before) in claim.
To be specific, when the time of docker_auth is faster than that of docker registry, we should wait to verify a token as the gap.

By the way, nbf field can get away. It's optional (https://tools.ietf.org/html/rfc7519#page-10)
So.. In my opinion, it is better to get away of it.

Question: TLS certificate

@rojer ,
I read #3 . But still have some confusion.
How do you generate TLS certificate?
If it is via openssl genrsa and openssl req? I don't think so.
Because the certificate's content is not accepted by docker distribution.
Could you please provide some example certificate?
Thanks a lot!

Question on ACL Order

I'm not sure if this intended, a bug, or I'm doing something wrong. I'm attempting configure some ACLs and I've used the reference example as a starting point.

When I have this configuration:

- match:
    account: /.+/
  actions:
  - pull
  comment: All logged in users can pull all images.
- match:
    account: /.+/
    name: ${account}/*
  actions:
  - push
  - pull
  comment: All logged in users can push all images that are in a namespace beginning
    with their name

As you would expect I am able to pull just fine, however pushing to a repo in the users namespace It tosses an unauthorized: authentication required.

However this works (its exactly the same, just the ordering has been flipped):

- match:
    account: /.+/
    name: ${account}/*
  actions:
  - push
  - pull
  comment: All logged in users can push all images that are in a namespace beginning
    with their name
- match:
    account: /.+/
  actions:
  - pull
  comment: All logged in users can pull all images.

So it feels like the first ACL that matches is returned, and the rest are not applied. Do I need to do anything to make it honor both regardless of order?

Thanks

question about start the image

i following the readme to try this, but i always get following error:

root@ubu89:/config# docker run --rm -it --name docker_auth -p 5001:5001 -v /path/to/config_dir:/config:ro -v /var/log/docker_auth:/logs paasrepo.io:5000/docker_auth:latest --v=2 --alsologtostderr /config/auth_config.yml

F0321 09:09:07.255478 1 main.go:167] Failed to load config: could not read /config/auth_config.yml: open /config/auth_config.yml: no such file or directory

i have created the config folder than auth_config.yml file. what shall i do to solve it?

Auth with LDAP error

Hi ,

I tried with ldap auth and getting following error. I used cesanta/docker_auth:stable. My config are bellow. Any idea?

ldap_auth:
addr: "ldap://ldap.xxx.com:389"
tls: true

In case bind DN and password is required for querying user information,

specify them here. Plain text password is read from the file.

bind_dn: "uid=docker,ou=staff,dc=xxx,dc=com"
bind_password_file: "config/pass.txt"

User query settings. ${account} is expanded from auth request

base: "ou=staff,dc=xxx,dc=com"
filter: "(&(uid=${account})(objectClass=person))"

Error :

I0318 05:19:09.615764 1 server.go:1934] http: panic serving 192.168.56.190:53095: runtime error: invalid memory address or nil pointer dereference
goroutine 33 [running]:
net/http.(_conn).serve.func1(0xc820216000, 0x7f2bb0bed060, 0xc820214000)
/usr/local/go/src/net/http/server.go:1287 +0xb5
github.com/go-ldap/ldap.(_Conn).Close(0x0)
/go/src/github.com/cesanta/docker_auth/auth_server/Godeps/_workspace/src/github.com/go-ldap/ldap/conn.go:132 +0x6d
github.com/go-ldap/ldap.(_Conn).Bind(0x0, 0xc82005b950, 0x22, 0xc8202e5560, 0x14, 0x0, 0x0)
/go/src/github.com/cesanta/docker_auth/auth_server/Godeps/_workspace/src/github.com/go-ldap/ldap/bind.go:94 +0x3c
github.com/cesanta/docker_auth/auth_server/authn.(_LDAPAuth).bindReadOnlyUser(0xc82002a090, 0x0, 0x0, 0x0)
/go/src/github.com/cesanta/docker_auth/auth_server/authn/ldap_auth.go:101 +0x266
github.com/cesanta/docker_auth/auth_server/authn.(_LDAPAuth).Authenticate(0xc82002a090, 0xc8202f0152, 0x6, 0xc820218547, 0x9, 0x0, 0x0, 0x0)
/go/src/github.com/cesanta/docker_auth/auth_server/authn/ldap_auth.go:67 +0x11d
github.com/cesanta/docker_auth/auth_server/server.(_AuthServer).Authenticate(0xc8201449c0, 0xc8202d2f00, 0x11, 0x0, 0x0)
/go/src/github.com/cesanta/docker_auth/auth_server/server/server.go:167 +0x11e
github.com/cesanta/docker_auth/auth_server/server.(_AuthServer).doAuth(0xc8201449c0, 0x7f2bb0bed690, 0xc8202c1b80, 0xc8202a5180)
/go/src/github.com/cesanta/docker_auth/auth_server/server/server.go:314 +0x3b3
github.com/cesanta/docker_auth/auth_server/server.(_AuthServer).ServeHTTP(0xc8201449c0, 0x7f2bb0bed690, 0xc8202c1b80, 0xc8202a5180)
/go/src/github.com/cesanta/docker_auth/auth_server/server/server.go:286 +0x1ef
net/http.serverHandler.ServeHTTP(0xc8201b5b00, 0x7f2bb0bed690, 0xc8202c1b80, 0xc8202a5180)
/usr/local/go/src/net/http/server.go:1862 +0x19e
net/http.(_conn).serve(0xc820216000)
/usr/local/go/src/net/http/server.go:1361 +0xbee
created by net/http.(_Server).Serve
/usr/local/go/src/net/http/server.go:1910 +0x3f6

Version tagged releases

We've been using the stable tag for a bit now without issue, but it feels like we are tempting fate a bit by not pinning to a static tag. Do you think it would be possible to apply some versioned (or some other unchanging) tag on Docker Hub?

For most images that do this we'd just push a known version into our own internal registry, but since this image is needed to actually build that system we rely on Docker hub for this one.

Thanks

Proposal: allow to outsource ACLs

Hi,

I'm using cesanta/docker_auth in my docker-registry-setup project. It serves as a proof of concept and shall make up the foundation for developing a next generation of docker registry frontends. My old docker-registry-frontend has no notion of authentication built into it except for Apache-based Kerberos authentication. It has absolutely no knowledge about authorization.

My docker-registry-setup works fine but once you think about a Web UI component that shall perform actions like deleting a repo or tagging an image from within a browser, that frontend needs to be aware of ACLs. In fact, as an admin you might want to be able to configure ACLs from within the frontend. Right now I don't see a way to be able to use the ACLs specified in docker_auth's config file from a frontend, do you?

Here are my questions:

  1. That being said, what do you think about the idea to create a "module" (just like LDAP or Google for authentication) to store ACLs inside a database (e.g. MongoDB) or an external service?
  2. If you at all agree that this might be useful, would you consider to merge a PR if somebody creates such code?
  3. Do you think it is a good idea to model what is currently possible with ACLs in a database backend of choice? Or do you have other plans for the ACLs?

Thank you in advance for answering my questions!

  • Konrad

UI / Admin Interface

Hi,
cool you build this, great work! Do you plan to add a admin panel, or CLI for creating users and controlling access?

Auth fails if auth container has newer time than the registry server

We saw an issue where the auth server was about 30 seconds ahead of the registry server due to misconfigured ntp. This got us thinking that there could be an issue if the auth server is even a couple of seconds ahead of the registry server. Should there be a little bit of a window (say 5 seconds before)?

time="2015-12-29T19:50:55.842580115Z" level=error msg="token not to be used before 1451418688 or after 1451419589 - currently 1451418655"

Invalid Memory Address with AD LDAP via TLS

I've configured LDAP for TLS connecting to an AD server, but I get the following error whenever a user attempts to login.

runtime error: invalid memory address or nil pointer dereference
goroutine 12 [running]:
net/http.(_conn).serve.func1(0xc82017fce0, 0x7f2f7223a268, 0xc82008c840)
/usr/local/go/src/net/http/server.go:1287 +0xb5
github.com/go-ldap/ldap.(_Conn).StartTLS(0xc82027c900, 0xc8201c1680, 0x0, 0x0)
/home/rojer/go/src/github.com/go-ldap/ldap/conn.go:180 +0x125c
github.com/cesanta/docker_auth/auth_server/authn.(_LDAPAuth).ldapConnection(0xc8200240b0, 0xc8201fe540, 0x0, 0x0)
/home/rojer/go/src/github.com/cesanta/docker_auth/auth_server/authn/ldap_auth.go:133 +0x33d
github.com/cesanta/docker_auth/auth_server/authn.(_LDAPAuth).Authenticate(0xc8200240b0, 0xc8202748d2, 0xd, 0xc82027e32e, 0x9, 0x0, 0x0, 0x0)
/home/rojer/go/src/github.com/cesanta/docker_auth/auth_server/authn/ldap_auth.go:56 +0x8c
github.com/cesanta/docker_auth/auth_server/server.(_AuthServer).Authenticate(0xc820126680, 0xc82025ed80, 0x11, 0x0, 0x0)
/home/rojer/go/src/github.com/cesanta/docker_auth/auth_server/server/server.go:109 +0x11e
github.com/cesanta/docker_auth/auth_server/server.(_AuthServer).doAuth(0xc820126680, 0x7f2f7223e8e8, 0xc8202820b0, 0xc820233960)
/home/rojer/go/src/github.com/cesanta/docker_auth/auth_server/server/server.go:229 +0x3d1
github.com/cesanta/docker_auth/auth_server/server.(_AuthServer).ServeHTTP(0xc820126680, 0x7f2f7223e8e8, 0xc8202820b0, 0xc820233960)
/home/rojer/go/src/github.com/cesanta/docker_auth/auth_server/server/server.go:201 +0x1ef
net/http.serverHandler.ServeHTTP(0xc8201a05a0, 0x7f2f7223e8e8, 0xc8202820b0, 0xc820233960)
/usr/local/go/src/net/http/server.go:1862 +0x19e
net/http.(_conn).serve(0xc82017fce0)
/usr/local/go/src/net/http/server.go:1361 +0xbee
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:1910 +0x3f6

How to develop a docker_auth

Hi:
I would like to use keystone as the authentication medium, using Python as the development language, which I should follow the standards?
For example, the API structure specification and return specification。
Thank you.

ACL for allowing anonymous access to catalog

I would like to setup my ACL to allow anonymous access to the catalog, as well as pulling all images. Could someone help me with how to specify that?

Here's what I am currently using, but it isn't working:

acl:
  # Admin has full access to everything.
  - match: {account: "admin"}
    actions: ["*"]
  # User "public" can pull stuff.
  - match: {account: "public"}
    actions: ["pull"]
  # Trying to allow anonymous to access the catalog, pull stuff
  - match: {account: ""}
    actions: ["pull"]
  # Access is denied by default.

This is what I get when I try to hit https://my-registry.server.org/v2/_catalog in a web browser:

{"errors":[{"code":"UNAUTHORIZED",
"message":"access to the requested resource is not authorized",
"detail":[{"Type":"registry","Name":"catalog","Action":"*"}]}]}

mongo acl update fails on primary re-election of mongo replica set

We are facing a strange issue when the primary mongo instance from the mongo cluster goes down, the auth server throws the following error in the logs,

tail -f /var/lib/docker/containers/77a26e18a502696d9da77afb39603a24aae4a936cb1b02268582cb7d3c3bcc50/77a26e18a502696d9da77afb39603a24aae4a936cb1b02268582cb7d3c3bcc50-json.log
{"log":"E0309 16:39:37.399743      1 acl_mongo.go:138] Failed to update ACL. ERROR: EOF\n","stream":"stderr","time":"2016-03-09T16:39:37.400394964Z"}
{"log":"W0309 16:39:37.400356      1 acl_mongo.go:139] Using stale ACL (Age: 1m59.99889041s, TTL: 1m0s)\n","stream":"stderr","time":"2016-03-09T16:39:37.400888752Z"}
{"log":"E0309 16:40:37.399780      1 acl_mongo.go:138] Failed to update ACL. ERROR: EOF\n","stream":"stderr","time":"2016-03-09T16:40:37.400130687Z"}
{"log":"W0309 16:40:37.400094      1 acl_mongo.go:139] Using stale ACL (Age: 2m59.998905529s, TTL: 1m0s)\n","stream":"stderr","time":"2016-03-09T16:40:37.400527491Z"}

Once the config file is changed (i just did an echo " ">> /config/ldap_auth.yml) and it reloaded the config and it starts working

{"log":"I0309 16:41:09.447069      1 main.go:144] Restarting server\n","stream":"stderr","time":"2016-03-09T16:41:09.450893014Z"}
{"log":"I0309 16:41:09.448508      1 main.go:150] New config loaded\n","stream":"stderr","time":"2016-03-09T16:41:09.450938039Z"}
{"log":"I0309 16:41:09.448611      1 server.go:283] Server stopped\n","stream":"stderr","time":"2016-03-09T16:41:09.45094872Z"}
{"log":"I0309 16:41:09.448622      1 main.go:43] Config from /config/ldap_auth.yml (1 users, 2 ACL static entries)\n","stream":"stderr","time":"2016-03-09T16:41:09.45095705Z"}
{"log":"W0309 16:41:09.458879      1 main.go:78] Running without TLS\n","stream":"stderr","time":"2016-03-09T16:41:09.459429096Z"}
{"log":"I0309 16:41:09.459040      1 main.go:90] Serving\n","stream":"stderr","time":"2016-03-09T16:41:09.459466899Z"}

Has anyone seen a similar issue and is there a better workaround/fix for setting the read preference for the replica set.?

Make an ACL engine like the Authentication

Allow ACL to pluggable like the authentication currently is.

Ex:

  • LDAP
  • A database

This allows an organization to have non developer maintain this mapping. For instance with new hires or people leaving. Or new repos and new groups

I would be happy to take a shot at adding this if you are open to this type of feature. Certain implementations would also solve #6

config reload

Is there a way to let the docker_auth reread the config file? Currently you need to restart the container if you changed the config file. I see the following options:

  1. reload on file changed
  2. reload every minute
  3. reload on every request
  4. reload on the call of special api route

It would be nice to have one of this options (toggleable via config) if your config is changed from an external program like a CLI or a webinterface.

Possible regression with multiple scopes support?

After #68
I have been having issues pushing or pulling images using ACL accounts that don't have top level repo access in my private repo.

The following conf file used to work with docker_auth prior to PR#68, which basically defines the following users:

admin should have full access to all levels
orgadmin should have full access only under org/*
orgreadonly should only have pull access under org/*
all users, including non login users have pull only access under org2/*

...
users:
  "admin":
    password: "REDACTED"
  # admin user for push/pull access to all levels in priv registry
  "orgadmin":
    password: "REDACTED"
  # admin user for /org/*
  "orgreadonly":
    password: "READACTED"
  # readonly user for /org/*
  "": {} # Allow anonymous (no "docker login" access)

acl:
  # Admin has full access to everything.
  - match: {account: "admin"}
    actions: ["*"]
  # orgdmin has full access under org/*
  - match: {account: "orgadmin", name: "org/*"}
    actions: ["*"]
  # orgreadonly has readonly access under org/*
  - match: {account: "orgreadonly", name: "org/*"}
    actions: ["pull"]
  # Anonymous users can pull everything under org2
  - match: {account: "", name: "org2/*"}
    actions: ["pull"]
  # Access is denied by default.

The trouble is that after using the latest version of docker_auth while I am able to perform all operations as the admin user I can not push anything with orgadmin or pull with orgreadonly content from org/*

For instance, on a clean vm with docker-engine setup I pull ubuntu:trusty then
docker tag ubuntu:trusty myprivateregistry/org/mytestubuntu:latest
and after successfully logging in docker login myprivateregistry as orgadmin user, when I do docker push myprivateregistry/org/mytestubuntu:latest I am getting auth errors:

The push refers to a repository [myprivateregistry/org/mytestubuntu]
5f70bf18a086: Preparing 
11083b444c90: Preparing 
9468150a390c: Preparing 
56abdd66ba31: Preparing 
unauthorized: authentication required

whereas docker distribution logs complain about insufficient scope:

 {"environment":"someenvironment","go.version":"go1.5.3","http.request.host":"myprivateregistry","http.request.id":"67a32b35-cd57-4327-8a93-586606478831","http.request.method":"GET","http.request.remoteaddr":"REDACTED","http.request.uri":"/v2/","http.request.useragent":"docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64","instance.id":"c7031ff7-a004-4906-a92f-857319afd0f5","level":"warning","msg":"error authorizing context: authorization token required","service":"registry","time":"2016-03-13T22:25:27.677671395Z","version":"v2.3.1"}
 10.0.0.74 - - [13/Mar/2016:22:25:27 +0000] "GET /v2/ HTTP/1.1" 401 87 "" "docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64"
 {"environment":"someenvironment","go.version":"go1.5.3","http.request.host":"myprivateregistry","http.request.id":"ba625634-e25c-4396-a2c2-013b09c86da6","http.request.method":"HEAD","http.request.remoteaddr":"READACTED","http.request.uri":"/v2/org/mytestubuntu/blobs/sha256:28a2f68d1120598986362662445c47dce7ec13c2662479e7aab9f0ecad4a7416","http.request.useragent":"docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64","instance.id":"c7031ff7-a004-4906-a92f-857319afd0f5","level":"warning","msg":"error authorizing context: insufficient scope","service":"registry","time":"2016-03-13T22:25:29.495285814Z","vars.digest":"sha256:28a2f68d1120598986362662445c47dce7ec13c2662479e7aab9f0ecad4a7416","vars.name":"org/mytestubuntu","version":"v2.3.1"}
 10.0.1.89 - - [13/Mar/2016:22:25:29 +0000] "HEAD /v2/org/mytestubuntu/blobs/sha256:28a2f68d1120598986362662445c47dce7ec13c2662479e7aab9f0ecad4a7416 HTTP/1.1" 401 150 "" "docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64"
 {"environment":"someenvironment","go.version":"go1.5.3","http.request.host":"myprivateregistry","http.request.id":"6d89d7c4-0c77-4dec-9c9e-a48afcfd65f8","http.request.method":"HEAD","http.request.remoteaddr":"READACTED","http.request.uri":"/v2/org/mytestubuntu/blobs/sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4","http.request.useragent":"docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64","instance.id":"c7031ff7-a004-4906-a92f-857319afd0f5","level":"warning","msg":"error authorizing context: insufficient scope","service":"registry","time":"2016-03-13T22:25:29.502771895Z","vars.digest":"sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4","vars.name":"org/mytestubuntu","version":"v2.3.1"}
 10.0.1.89 - - [13/Mar/2016:22:25:29 +0000] "HEAD /v2/org/mytestubuntu/blobs/sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4 HTTP/1.1" 401 150 "" "docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64"
 {"environment":"someenvironment","go.version":"go1.5.3","http.request.host":"myprivateregistry","http.request.id":"249622ea-b2ce-4642-b128-088a909c9829","http.request.method":"HEAD","http.request.remoteaddr":"READACTED","http.request.uri":"/v2/org/mytestubuntu/blobs/sha256:fd2731e4c50ce221d785d4ce26a8430bca9a95bfe4162fafc997a1cc65682cce","http.request.useragent":"docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64","instance.id":"c7031ff7-a004-4906-a92f-857319afd0f5","level":"warning","msg":"error authorizing context: insufficient scope","service":"registry","time":"2016-03-13T22:25:29.509935394Z","vars.digest":"sha256:fd2731e4c50ce221d785d4ce26a8430bca9a95bfe4162fafc997a1cc65682cce","vars.name":"org/mytestubuntu","version":"v2.3.1"}
 10.0.1.89 - - [13/Mar/2016:22:25:29 +0000] "HEAD /v2/org/mytestubuntu/blobs/sha256:fd2731e4c50ce221d785d4ce26a8430bca9a95bfe4162fafc997a1cc65682cce HTTP/1.1" 401 150 "" "docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64"
 {"environment":"someenvironment","go.version":"go1.5.3","http.request.host":"myprivateregistry","http.request.id":"4873884a-483e-41bf-8e16-3f99d45aefa4","http.request.method":"HEAD","http.request.remoteaddr":"READACTED","http.request.uri":"/v2/org/mytestubuntu/blobs/sha256:5a132a7e7af11f304041e93efb9cb2a0a7839bccaec5a03cfbdc9a3f5d0eb481","http.request.useragent":"docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64","instance.id":"c7031ff7-a004-4906-a92f-857319afd0f5","level":"warning","msg":"error authorizing context: insufficient scope","service":"registry","time":"2016-03-13T22:25:29.558190632Z","vars.digest":"sha256:5a132a7e7af11f304041e93efb9cb2a0a7839bccaec5a03cfbdc9a3f5d0eb481","vars.name":"org/mytestubuntu","version":"v2.3.1"}
 10.0.1.89 - - [13/Mar/2016:22:25:29 +0000] "HEAD /v2/org/mytestubuntu/blobs/sha256:5a132a7e7af11f304041e93efb9cb2a0a7839bccaec5a03cfbdc9a3f5d0eb481 HTTP/1.1" 401 150 "" "docker/1.10.3 go/go1.5.3 git-commit/20f81dd kernel/3.19.0-25-generic os/linux arch/amd64"

Is there some additional configuration for the scope required in the ACLs section?

Thank you!

Details+versions

docker client:

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.10.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 4
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 3.19.0-25-generic
Operating System: Ubuntu 14.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 993.1 MiB
Name: ubuntu14vbox
ID: 3KWH:7SS2:RGQH:NMPB:OLMK:H54J:HQAE:SJVG:IB4Y:IVWZ:TQ5O:IOCO
WARNING: No swap limit support

docker distribution:

# /bin/registry -v
/bin/registry github.com/docker/distribution v2.3.1

Does this support network address ACLs?

Working on a PoC for a docker registry cluster with authentication and authorization. Use case would be that I would want developers to be able to pull images but not push if they log in, docker hosts (servers) to be able to pull images but not push if they are in a whitelist (for example a known network, or by a private key), and a build server to be able to push images.

ACL add allow&deny keyword

Hi Rojer,

Your current design about acl is only for allow. As long as the account is allowed by one acl entry, it will gain the access right.

Do you have ever think about deny? We could design like

  • if account is denied by any acl entry, it will lose access right.
  • if account isn't denied by any acl entry, and allowed by one acl entry, it'll gain access right.

Is this design reasonable to you?

Thanks

[Proposal] : Parameterize the NotBefore validity of token for NTP sync issues more than 1 sec

I am using docker auth and has been working fine. Lately with AWS multi AZ setup and cross AZ load balancing, we observed that the time on the hosts was not in sync to the sec.

I understand from #41 and #59 that NotBefore flag cannot be made optional, however can we make the hardcoded 1 sec value optional/configurable from the config yaml file.

This will certainly help users like us where we are getting this issue despite the ntp configuration.
I have already tested the same from my fork and will generate the pull request shortly.

Please let me know your thoughts.

Feature Request: Prolong token lifetime through Refresh tokens (request for comments)

Hi,

I'm not sure if this is the plan behind PR #29 but I wanted to propose a mechanism to be able to prolong the lifetime of a token.

Use case

Normally, you're probably going to use the auth server not directly but transparently through your docker client when you pull (or push) an image from a docker image registry. The docker client is smart enough to actually store a copy of your username and password so you only have to login once to every registry you interact with. Docker stores this on Linux in the file ~/.docker/config.json.

~/.docker/config.json

{
    "auths": {
        "0.0.0.0:443": {
            "auth": "c2VjcmV0Cg==",
            "email": "[email protected]"
        },
        "0.0.0.0:5000": {
            "auth": "c2VjcmV0Cg==",
            "email": "[email protected]"
        },
        "https://index.docker.io/v1/": {
            "auth": "c2VjcmV0Cg==",
            "email": "[email protected]"
        }
    }
}

Let's suppose you want to write an application that let's you browse your docker image registry which is protected with JWT tokens. Below I discuss some of the implications this has.

How the auth server fits in

Since your docker image registry is configured to require a JWT token, you need to login to the auth server with your username and password and query if you have the required permissions to access the resource in the docker registry. The auth server then creates a token and signs it and you must hand it over to the docker image registry together with you actual request.

Token lifetime and cached credentials

Each token has an expiration or lifetime of some sort. To get a new token, one has to provide a username and a password to the auth server again. What if you want to go: hey, my token is about to expire in a minute, let's contact the auth server and prolong the token? Of course, the auth server currently requires as username and password and you won't actually prolong a token but instead get a completely new one. To achieve this however, you would have to cache the username and password used when making the first request to the auth server. In practice this is a no go!

Proposal

What if the auth server sends back not only the actual token we're going to hand over to the docker registry but also send us a (the client) a refresh token (https://auth0.com/blog/2015/10/07/refresh-tokens-what-are-they-and-when-to-use-them/ or https://auth0.com/docs/refresh-token) of some sort? Given such a refresh token, a client can request a new prolonged token without asking the user for a password on each request and without caching the credentials.

Storing refresh tokens on server side for invalidation/revocation of "sessions"

Through refresh tokens it is possible for an application to always have an unexpired token. This can be dangerous because no matter how short you set the expiration time of your normal JWT-token, the client will probably be able to artificially keep the lifetime as long as it wants.

If the auth server can keep track of the refresh tokens it has authored (maybe see #29 for this), then one can also implement a form of invalidation or revocation of refresh tokens. Just suppose that every refresh token being sent to the server is checked against a database and if it finds a match, the refresh token is considered okay; otherwise the refresh token has been effectively made unusable. (This can be compared to application specific passwords you authored in your Google or Facebook account.)

Final thoughts

What do you think of this idea? Do you see a use for this? I wrote the docker-registry-frontend and this is the use for myself. All in all the workflow won't break the communication between the docker client and the docker registry because the refresh token can be transmitted by the auth server in some X-header that is ignored by the docker client.

If you think this idea is good then I ask you to discuss whether a refresh token lets you query for a different repository or namespace than you originally asked for. In my opinion this should be possible; otherwise you'd need credentials again. Also, you might want to ask the auth server for access to more than one repository/namespace at a time. The problem right now is that the auth server doesn't support this kind of list-requests. But it is not required and an application probably can keep a token for each individual resource and refresh those individually as well.

Improper exit code

When I stop docker_auth with Ctrl+C (SIGINT) or SIGTERM, it exits with exit code 1. When docker_auth fails to start due to being unable to read the config file, it also exits with code 1.

POSIX convention says exit code 0 indicates success - no error. Exit codes other than 0 indicate failures. docker_auth can be fixed by exiting with code 0 on a clean exit.

$ docker run --name docker-reg-auth --user=nobody --cap-drop=ALL -v /data/config/dr_auth:/config:ro -v /data/certs:/certs:ro docker.io/cesanta/docker_auth --v=2 --alsologtostderr /config/auth_config.yml
... Ctrl+C...
$ echo $?
1

Error 400 OAuth 2.0

Hi,
I'm working to deploy a google auth for a private registry with your docker_auth and after configuration the Static user works perfectly but when i try to use Google Auth, it tell me error 400.

Any Idea?
error

Thanks in advance

Pattern matching for "name"?

A very common pattern is to allow anyone to access their own named repository. Thus, if I can successfully authenticate as "jimd", then I should be able to access a repo that is at jimd/.

The current config (seems) not to support it. It should be fairly simple to do the following, though:

acl:
  # All logged in users can access their own images 
  - match: {account: "/^(.+)$/", name: "/^\1\/*"}
    actions: ["*]
  # alternate pattern, depending on your regexp engine
  - match: {account: "/^(.+)$/", name: "/^\$1\/*"}
    actions: ["*]

Logging

I can't seem to get it to log anything. I doesn't log to console out at all and mapping something to /log doesn't generate any files.

Unable to authenticate - Error 404

I've deployed a private registry on my.domain.com:5000 and docker auth on my.domain.com:5001.

I'm now trying to login by docker login my.domain.com:5001 but I'm facing with error:

Error response from daemon: Unexpected status code [404] : Not found

If I try to login to port 5000 instead I'm having

Error response from daemon: no successful auth challenge for https://my.domain.com:5000/v2/ - errors: []

Google Oauth: Docker login fails because because of invalid char in user name

Hi, and first of all thanks for this cool project !

I'm trying to setup docker_auth with a google apps domain. I can start the auth service fine, and logging in the auth service goes well. It then tells me to run docker login with my e-mail address as username and a generated string as password.

When I do so, I get the following error from docker:

$ docker login
Username: [email-address]
Password: 
Email: 
Error response from daemon: Registration: "Wrong username format (it has to match \"^[a-z0-9]{4,30}$\")"

Am I doing something wrong ?

Question on API Access

I finally got this working, still having issues related to osx and boot2docker with custom CA but it works from one ubuntu box to another!! Great work!

One question though...
Is there a way to just get a token to pass with curl in order to hit docker registry api?

Unable to push new images after adding auth

Hello,

I added authentication to my private registry and now am unable to push new images. Oddly enough, pulling images and pushing UNCHANGED images work fine.

However, when I push a new image, or an image that requires any layers to be updated, I get this:

bash-3.2$ docker push docker.djsdomain.com/gleaner
The push refers to a repository [docker.djsdomain.com/gleaner] (len: 1)
c2dce7213213: Pushing [==================================================>]     32 B/32 B
unauthorized: access to the requested resource is not authorized

Logs from the authentication server for this transaction:

I0930 00:47:27.582009       1 server.go:220] Auth request: {djenriquez:***@10.170.140.121:37572 {djenriquez pull,push repository gleaner}}
I0930 00:47:27.586096       1 server.go:103] Authn static djenriquez -> true, %!s(<nil>)
I0930 00:47:27.586165       1 acl.go:37] {djenriquez pull,push repository gleaner} matched {"Match":{"account":"djenriquez"},"Actions":["*"]}
I0930 00:47:27.586436       1 server.go:122] Authz static ACL {djenriquez pull,push repository gleaner} -> [pull push], %!s(<nil>)
I0930 00:47:27.595800       1 server.go:184] New token for {djenriquez:***@10.170.140.121:37572 {djenriquez pull,push repository gleaner}}: {"iss":"djsdomain ACME server","sub":"djenriquez","aud":"Docker Registry","exp":1443574947,"nbf":1443574046,"iat":1443574047,"jti":"6833611524882594851","access":[{"type":"repository","name":"gleaner","actions":["pull","push"]}]}
I0930 00:47:27.595879       1 server.go:250] {"token":"<Removing token for security -DJ>"}

I think the authentication server is doing everything correctly, but I figured i'd check if anything here looks odd. I do know that before adding authentication, I was able to push new images just fine.

I also opened an issue in the official docker/distribution repo.

Any ideas?

Error when compile it

Hi,

I'm trying to compile the server go. But i have problem. I make it and when run the "go build" show:

root@a235c66bb404:~/docker_auth/auth_server# go build
main.go:29:2: cannot find package "github.com/cesanta/docker_auth/auth_server/se
rver" in any of:
/usr/local/go/src/github.com/cesanta/docker_auth/auth_server/server (fro
m $GOROOT)
/go/src/github.com/cesanta/docker_auth/auth_server/server (from $GOPATH)
main.go:30:2: cannot find package "github.com/facebookgo/httpdown" in any of:
/usr/local/go/src/github.com/facebookgo/httpdown (from $GOROOT)
/go/src/github.com/facebookgo/httpdown (from $GOPATH)
main.go:31:2: cannot find package "github.com/golang/glog" in any of:
/usr/local/go/src/github.com/golang/glog (from $GOROOT)
/go/src/github.com/golang/glog (from $GOPATH)
main.go:32:2: cannot find package "gopkg.in/fsnotify.v1" in any of:
/usr/local/go/src/gopkg.in/fsnotify.v1 (from $GOROOT)
/go/src/gopkg.in/fsnotify.v1 (from $GOPATH)

Any idea to resolve it?

Token auth is generated, but registry responds 403 Forbidden

Hi, @rojer , since last week I succeeded with auth by account test:test by fixing certs issues. Today I tried again, I got another error.

Without any credential saved in my local, I tried docker push localhost:5000/test-busybox:latest.

8c2e06607696: Image push failed
FATA[0000] Error pushing to registry: token auth attempt for registry http://localhost:5000/v2/: https://127.0.0.1:5001/auth?scope=repository%3Atest-busybox%3Apull%2Cpush&service=Docker+registry request failed with status: 403 Forbidden

I expect the commandline will ask me username and password, as I've seen last week.

By the way, if I try docker login localhost:5000, input username test, password test, I was able to login.

If I try to curl

curl -k -u test:test https://127.0.0.1:5001/auth?scope=repository:test-busybox:push&service=Docker+registry

It gave me the token

 {"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IlZJU006NFhOSjpCQUdMOkUyVFU6S0VQVzpIVDNTOkYzT0U6UkxLTzpUSlA0OkVTTDU6WUVUMzpUUEFLIn0.eyJpc3MiOiJBY21lIGF1dGggc2VydmVyIiwic3ViIjoidGVzdCIsImF1ZCI6IiIsImV4cCI6MTQzMzkzMzA2MCwibmJmIjoxNDMzOTMyMTU5LCJpYXQiOjE0MzM5MzIxNjAsImp0aSI6IjQ2MDc3MzAzODg0ODkxMDM0NjIiLCJhY2Nlc3MiOlt7InR5cGUiOiJyZXBvc2l0b3J5IiwibmFtZSI6InRlc3QtYnVzeWJveCIsImFjdGlvbnMiOlsicHVzaCJdfV19.o-fFYibAPBGnWC2B8NIKyMZdZIT4KFFWRfEYhSszk_HvJfURLDfOUahRV30fgsjudza0rCpo7jYwnAeyz3qcVM3wMTlxdK5nZ_qC7AVqoAj7lIZZNfGpGjFBbzB0VA60dt8zVxY3fF1H-wl1sk0ml_keAOz4r9x2mTIe89RZGSwsd1vcGSYbRJbzz7fG3hSGX18ekVuxgJ9MaOAsbEvNakn20UBhobTyL8OZVczaQEH4dr3x0nH9Zfz_GI1I6C5oMdUw4tWdEB3aqMP3ALVYeg8d_cLJ5a2aLh00O9RFS-6GwLQtUI4uoI2hJ3gcRH87b4yxaf26pFKE1bCcRQYrug"}

Seems auth server is working. But why registry gave me 403 even without asking me for username and password???
And here is registry's log, the wired thing is it reports 401 instead of 403???

time="2015-06-10T10:33:01.89432815Z" level=debug msg="authorizing request" environment=development http.request.host="localhost:5000" http.request.id=57dfc29a-0ec3-4ffb-b1cb-1aeed52d04e1 http.request.method=GET http.request.remoteaddr="172.17.42.1:37871" http.request.uri="/v2/" http.request.useragent="docker/1.6.0 go/go1.4.2 git-commit/4749651 kernel/3.13.0-48-generic os/linux arch/amd64" instance.id=9ab8120f-fb74-4b3f-a062-324bc6760508 service=registry version=v2.0.0-179-g3073b1d.m
time="2015-06-10T10:33:01.895085187Z" level=error msg="error authorizing context: authorization token required" environment=development http.request.host="localhost:5000" http.request.id=57dfc29a-0ec3-4ffb-b1cb-1aeed52d04e1 http.request.method=GET http.request.remoteaddr="172.17.42.1:37871" http.request.uri="/v2/" http.request.useragent="docker/1.6.0 go/go1.4.2 git-commit/4749651 kernel/3.13.0-48-generic os/linux arch/amd64" instance.id=9ab8120f-fb74-4b3f-a062-324bc6760508 service=registry version=v2.0.0-179-g3073b1d.m
time="2015-06-10T10:33:01.895478806Z" level=info msg="response completed" environment=development http.request.host="localhost:5000" http.request.id=57dfc29a-0ec3-4ffb-b1cb-1aeed52d04e1 http.request.method=GET http.request.remoteaddr="172.17.42.1:37871" http.request.uri="/v2/" http.request.useragent="docker/1.6.0 go/go1.4.2 git-commit/4749651 kernel/3.13.0-48-generic os/linux arch/amd64" http.response.contenttype="application/json; charset=utf-8" http.response.duration=6.673508ms http.response.status=401 http.response.written=114 instance.id=9ab8120f-fb74-4b3f-a062-324bc6760508 service=registry version=v2.0.0-179-g3073b1d.m
172.17.42.1 - - [10/Jun/2015:10:33:01 +0000] "GET /v2/ HTTP/1.1" 401 114 "" "docker/1.6.0 go/go1.4.2 git-commit/4749651 kernel/3.13.0-48-generic os/linux arch/amd64"
time="2015-06-10T10:33:01.905632772Z" level=debug msg="authorizing request" environment=development http.request.host="localhost:5000" http.request.id=7b4585d7-5546-4bc7-8897-259b9cee2a35 http.request.method=GET http.request.remoteaddr="172.17.42.1:37877" http.request.uri="/v2/" http.request.useragent="docker/1.6.0 go/go1.4.2 git-commit/4749651 kernel/3.13.0-48-generic os/linux arch/amd64" instance.id=9ab8120f-fb74-4b3f-a062-324bc6760508 service=registry version=v2.0.0-179-g3073b1d.m
time="2015-06-10T10:33:01.906005775Z" level=error msg="error authorizing context: authorization token required" environment=development http.request.host="localhost:5000" http.request.id=7b4585d7-5546-4bc7-8897-259b9cee2a35 http.request.method=GET http.request.remoteaddr="172.17.42.1:37877" http.request.uri="/v2/" http.request.useragent="docker/1.6.0 go/go1.4.2 git-commit/4749651 kernel/3.13.0-48-generic os/linux arch/amd64" instance.id=9ab8120f-fb74-4b3f-a062-324bc6760508 service=registry version=v2.0.0-179-g3073b1d.m
time="2015-06-10T10:33:01.906345031Z" level=info msg="response completed" environment=development http.request.host="localhost:5000" http.request.id=7b4585d7-5546-4bc7-8897-259b9cee2a35 http.request.method=GET http.request.remoteaddr="172.17.42.1:37877" http.request.uri="/v2/" http.request.useragent="docker/1.6.0 go/go1.4.2 git-commit/4749651 kernel/3.13.0-48-generic os/linux arch/amd64" http.response.contenttype="application/json; charset=utf-8" http.response.duration=4.724482ms http.response.status=401 http.response.written=114 instance.id=9ab8120f-fb74-4b3f-a062-324bc6760508 service=registry version=v2.0.0-179-g3073b1d.m
172.17.42.1 - - [10/Jun/2015:10:33:01 +0000] "GET /v2/ HTTP/1.1" 401 114 "" "docker/1.6.0 go/go1.4.2 git-commit/4749651 kernel/3.13.0-48-generic os/linux arch/amd64"

The docker image cannot be started

we are having problem to started and we have no idea how to resolve it:

[root@docker-registry tmp]# docker run --rm -it --name docker_auth -p 5001:5001 -v /tmp/:/config:ro -v /var/log/docker_auth:/logs cesanta/docker_auth --v=2 /config/docker_auth.yml
F0714 08:29:46.246461 1 main.go:146] Failed to load config: could not read /config/docker_auth.yml: open /config/docker_auth.yml: permission denied

we got "permission denied" error on reading the yml file but this is already set to 777.

Authentication fail

I am so excited to see registry v2's authentication server's built up! But I couldn't pass authentication.

When I run: docker push localhost:5000/test-busybox
FATA[0003] Error response from daemon: no successful auth challenge for http://localhost:5000/v2/ - errors: [token auth attempt to http://localhost:5000/v2/ realm "https://127.0.0.1:5001/auth" failed with status: 401 Unauthorized]

When I run: docker push localhost:5000/test/test-busybox
FATA[0000] Error pushing to registry: token auth attempt for registry http://localhost:5000/v2/: https://127.0.0.1:5001/auth?account=test&scope=repository%3Atest%2Ftest-busybox%3Apull%2Cpush&service=Docker+registry request failed with status: 403 Forbidden

My auth_config.yml setting for account 'test'

 "test":
    password: "$2a$05$oU4jdJOakJaUYKkfXY06jul6EneXPXtCeyZf2davojiNaocyFxCKW" 
  ...
   - match: {account: "test", name: "test-*"}
    actions: ["*"]
   - match: {account: "test"}
    actions: []

I don't know whether it's code issue or my config's wrong.

can not build it by Makefile

root@ubuntu-zxc:/home/docker_auth/auth_server# make
go get -v -u github.com/tools/godep github.com/jteeuwen/go-bindata/... .
github.com/tools/godep (download)
github.com/jteeuwen/go-bindata (download)
Fetching https:///home/docker_auth/auth_server?go-get=1
https fetch failed.
Fetching http://
/home/docker_auth/auth_server?go-get=1
import "/home/docker_auth/auth_server": http/https fetch for import "/home/docker_auth/auth_server": Get http://_/home/docker_auth/auth_server?go-get=1: lookup _: no such host
package github.com/tools/godep
imports github.com/tools/godep/Godeps/_workspace/src/github.com/kr/fs
imports github.com/tools/godep/Godeps/_workspace/src/github.com/kr/pretty
imports github.com/tools/godep/Godeps/_workspace/src/github.com/kr/text
imports github.com/tools/godep/Godeps/_workspace/src/github.com/pmezard/go-difflib/difflib
imports github.com/tools/godep/Godeps/_workspace/src/golang.org/x/tools/go/vcs
imports github.com/jteeuwen/go-bindata
imports github.com/jteeuwen/go-bindata/go-bindata
imports /home/docker_auth/auth_server: unrecognized import path "/home/docker_auth/auth_server"
make: *** [update-deps] Error 1

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.