dockerhub automated builds - broad github permissions required? - docker

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.

Related

How to secure the Docker hub repository accounts used in the CI/CD pipeline or Automation?

could anyone share some guidelines around this problem?
As the Docker hub repository is accessible through the internet outside the company , even for private repositories ,an employee leaving the organization can access the images (read/write) provided if he knows the user accounts used in the automation scripts. Assume this employee is a DevOps or a Developer it is too easy to record the username/passwords before he leaves the company. There is a concept of Access Token but then these are still tied to the user-account. Two factor authentication can be enabled for human based login but not for automation jobs (e.g Jenkins/scripts) .

Docker push and pull using separate credentials

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.

Add jeninks local user readonly account when using Global GitHub OAuth Sec

How can I add a limited access account for jenkins automation when I'm using Global GitHub OAuth Settings?
I'm using GitHub OAth for login to jenkins and I have python jenkinsapi scripts that I want to run as a user with read only access. At present, all my users are github users.
I can create a github account without access to my repositories and then limit that accounts access to jenkins but this seems cumbersome.
Is there a way to use multiple security realms or to create local users?
It seems that when jenkins contains a local user, that the plugin uses this first (plugin-source)
If you look at Manage Jenkins->Configure Global Security, you can see that you can select only one security realm.
I would say, for Jenkins use create a github service account specifically that user can be restricted to just a few repositories. You can also look at matrix based security or project based matrix security if you want to restrict authorization further

Docker registry catalog API restricted at the user level

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.

Providing acces to issue tracker only in bitbuckets repository

Questions:
If I have a user group related to clients added to a repository with read access, would they be able to clone the repository on their local system?
If yes, what measures should I take to keep a group or user restricted to issue tracker only and not the code, means they should be able to create,update and close the issues but they should not be able to clone the repository, is there any way to do it, as I do not want the client to have access to the code until he has paid for the whole project.
Bitbucket's permissions do not support what you want to do.
Users with read access can clone the repository:
View, clone, and fork the repository code. All public repositories grant all Bitbucket Cloud users read permissions automatically. Read access on a repository also allows users to create issues, comment on issues, and edit wiki pages.
There is no configuration that permits users to create and freely browse issues while restricting read access to the repository. The most likely setting would be private repository / public issue tracker, but in this case access to the issue tracker for users without repository access is restricted:
Only users who have access to the private repository can create an issue. Other Bitbucket users and any Internet browser can view the issue tracker if you publish the URL.
There may be other services that support your requirements.

Resources