I have a private Docker registry running.
Any user should be able to push and pull any image. Therefore, right now I am not using any user identification at all.
However, a user should not be able to trick the registry to overwrite the Images of other users.
If user A uploads ourRegistry/myProgram:version_1, then user B should not be able to upload something tagged ourRegistry/myProgram:version_2.
Is there a way to add user authentification to a private registry to do this?
Additionally, the registry is part of a server that already has its own database of registered users. Is there a way to synchronize the users, so that the users don't have to remember two passwords?
The official documentation on docker registry authentication is located here: https://docs.docker.com/registry/deploying/#native-basic-auth. Since it uses htpasswd to handle its authentication I'm not sure if there's any way to use your user database dynamically (obviously you can write a script to import all your users using htpasswd mentioned in this documentation)
Related
I am working with an image called tensort built using my local docker daemon. This is the command I am using to push the image.
$ docker push della/tensort:latest
But how does it work in devops teams of a few developers, if someone wants to work with others' image? How does the image name (della/tensort:latest in my case) look like? Should the image contain the user name of the developer who pushed it, like a git commit?
Yes, to answer your question, if you were to be working on someone else's docker container image, you would want to pull it onto your local machine using
docker pull [options] <your-collegue's-docker-id>/<docker-container-name>:<tag>
(In your case, your co-developers need to use "della/tensort:latest" to pull the image)
For more details on the options and their uses, kindly refer to the documentation below.
https://docs.docker.com/engine/reference/commandline/pull/
The image name would typically the name of the organization that owns it, like a GitHub repository. If your source code is in https://github.com/examplecom/tensort then you'd typically build an image examplecom/tensort.
Remember that a Docker image is immutable and contains a built copy of your application; the only thing you can really do with an image is run it. If you want to publish built images to your colleagues you can, and if your organization permits you could use your personal Docker Hub account for it. In my current role I rarely check out other developers' source-control branches (though it happens) and basically never try to run their prebuilt images.
Docker hub has the concept of teams and organizations.
Docker Hub organizations let you create teams so you can give your team access to shared image repositories.
Organizations are collections of teams and repositories that can be managed together.
Teams are groups of Docker Hub users that belong to an organization.
You typically would use those to work across teams. For example, your company has an organization with the same name as the company, then you have multiple teams under that organization and can add employees of your company to the individual teams with certain permissions such as read and write.
I'm looking to test automated container builds on Dockerhub, and I see that I need to link my github account to my hub.docker.account.
However, when I click on the 'connect' button, I'm taken to a github authorization page that says:
Docker Hub Builder by docker wants to access your larryms account
Repositories
Public and private
This application will be able to read and write all public and private repository data.
This includes the following:
- Code
- Issues
- Pull requests
- Wikis
- Settings
- Webhooks and services
- Deploy keys
- Collaboration invites
This seems far too permissive and overly broad; if I'm understanding it correctly, I need to grant Docker Hub Builder read & write access to all my github repositories, both public and private.
Is there any way to do this using the principle of least privilege, eg only granting Docker Hub Builder necessary rights (hopefully read only) only to specific github repos?
OAuth scopes on GitHub are indeed wide (see https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes, where you cannot grant read access without granting write access as well). However, the scopes are applied together with the actual permissions the user has on the repo in question. That is, if the user has only read access to repo X, and the user granted an oauth token with read & write scope to dockerhub, dockerhub would only be able to read from repo X on behalf of this user. If the user gets admin access to repo X later on, the already granted access token will not allow admin access, as the scope of the token allows read & write access only.
With this in mind, you can create a dedicated user for dockerhub in your github org, and grant this user read access to relevant repos. Then connect dockerhub to your github account with this user, granting just read access to the selected repos.
I am trying to create separate push and pull for docker registry in terms of safety reasons. Is it possible to create it in any of the container registries.
Docker Registry 2.0 introduced a new, token-based authentication and authorization protocol. ACL is supported if you use token based authentication for the docker registry. You can use a pre-built ACL solution like this https://github.com/cesanta/docker_auth.
It porvides fine grained ACL rules, e.g.
acl:
- match: {account: "admin"}
actions: ["*"]
comment: "Admin has full access to everything."
- match: {account: "user"}
actions: ["pull"]
comment: "User \"user\" can pull stuff."
# Access is denied by default.
see full example https://github.com/cesanta/docker_auth/blob/master/examples/simple.yml
For your scenario you can create two users with push and pull permissions only, then login as appropriate user for the operation (push or pull).
If you use Docker Hub, there is already sort of ACL for organisations.
Docker Hub organizations let you create teams so you can give
colleagues access to shared image repositories. A Docker Hub
organization can contain public and private repositories just like a
user account. Access to push or pull for these repositories is
allocated by defining teams of users and then assigning team rights to
specific repositories. Repository creation is limited to users in the
organization owner’s group. This allows you to distribute limited
access Docker images, and to select which Docker Hub users can publish
new images.
https://docs.docker.com/docker-hub/orgs/#repository-team-permissions
Permissions are cumulative. For example, if you have Write
permissions, you automatically have Read permissions:
Read access allows users to view, search, and pull a private repository in the same way as they can a public repository.
Write access allows users to push to non-automated repositories on the Docker Hub.
Admin access allows users to modify the repositories “Description”, “Collaborators” rights, “Public/Private” visibility
and “Delete”.
In your scenario you must have at least two registered hub users, then one of them could be a member of a team with Read only permissions, the other user could be a member of a team with Write (and automatically Read) access.
Note: A User who has not yet verified their email address only has
Read access to the repository, regardless of the rights their team
membership has given them.
Is there a way using UCP that we can limit certain users to push only to certain tags for example, deny push to abc/batch_scheduler:1.0.0 but let them push to abc/batch_scheduler:dev123 ?
Thank you in advance.
The restrictions would need to be handled by the registry server, which for Docker EE would be DTR. With DTR, the restrictions on push access to a repository are all or nothing per repository, not per tag. However, you can create multiple repositories, allow developers to upload to one repository, and have a promotion policy to copy images matching specific criteria to another repository. The user does not need access to push images to the second repository, only the user that created the promotion policy needs access, which could be an administrator.
I'm setting up a docker registry using the container provided in the official documentation.
I setup the token authentication for the registry and I would like to consume the catalog API, e.g. for
listing repositories, but I would like to restrict it at the user level.
Therefore, an authenticated user, at the point of calling myregistry.com/v2/_catalog it will get as part
of the response body just the repositories where he has access.
Is there any middleware mechanism that can be easily implemented within the current docker registry
version?
If not, what is the recommended approach you would suggest in order to fulfil this use case.