suse / portus

Authorization service and frontend for Docker registry (v2)

Portus

• Website | Documentation | Blog | Supported versions | How to deploy
• Mailing list: Google Groups
• Last stable release: 2.4.3 (2.4, 2.4.3 and latest tags from the official Docker image)

Portus is an authorization server and a user interface for the next generation of the Docker registry. Portus targets version 2 of the Docker Registry API. The minimum required version of Registry is 2.1, which is the first version supporting soft deletes of blobs.

master	v2.4	Code Climate

Features

Fine-grained control of permissions

Portus supports the concept of users and teams. Users have their own personal Docker namespace where they have both read (aka docker pull) and write (aka docker push) access. A team is a group of users that have read and write access to a certain namespace. You can read more about this in our documentation page about it.

Portus implements the token based authentication system described by the new version of the Docker registry. This can be used to have full control over the images served by an instance of the Docker registry.

Web interface for Docker registry

Portus provides quick access to all the images available on your private instance of Docker registry. User's privileges are taken into account to make sure private images (the ones requiring special rights also for docker pull) are not shown to unauthorized personnel.

Self-hosted

Portus allows you to host everything on your servers, on your own infrastructure. You don't have to trust a third-party service, just own everything yourself. Take a look at our documentation to read the different setups in which you can deploy Portus.

And more!

Some highlights:

• Synchronization with your private registry in order to fetch which images and tags are available.
• LDAP user authentication.
• OAuth and OpenID-Connect authentication
• Monitoring of all the activities performed onto your private registry and Portus itself.
• Search for repositories and tags inside of your private registry.
• Star your favorite repositories.
• Disable users temporarily.
• Optionally use Application Tokens for better security.

Take a tour by our documentation site to read more about this.

Contributing

There are multiple ways of setting up a development environment. We recommend using docker-compose, so you only need to perform:

$ docker-compose up

You can read more about this environment here.

Also, make sure to understand our contribution guidelines, as explained in this document.

Testing

Unit tests

Unit tests are located in the spec directory. To run them, simply:

$ bundle exec rspec spec

Make sure to install phantomjs from your Linux distribution before running unit tests, since feature tests rely on PhantomJS being installed. All the other ruby dependencies are already covered by our Gemfile.

We also have tests in the frontend. For this, you have to install yarn from your Linux distribution and run:

$ yarn test

Integration tests

Check this document in order to better understand how integration tests work. For development, though, if you have already installed Docker, docker-composer and bats, running the following should just work:

$ chmod +x bin/test-integration.sh
$ ./bin/test-integration.sh

Other checks

A common pitfall for developers is to forget about code style. For that, make sure to run rubocop:

$ bundle exec rubocop -a

Note that the command above includes the -a flag. This flag will automatically fix small issues for you. We also run a code style check for the frontend code:

$ yarn eslint

We also run brakeman in order to detect security vulnerabilities:

$ bundle exec brakeman

Last but not least, make sure that your git commit follows a proper style. To ensure this, you can run the following task:

$ bundle exec rake test:git

Continuous Integration

We use Travis CI for continuous integration. You can run what we run in Travis locally:

$ chmod +x bin/ci/run.sh
$ ./bin/ci/run.sh

This script simply executes all the tests and checks that we have presented above.

Licensing

Portus is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.

portus's Issues

Ensure users can be created without conflicts

When creating a new user we must ensure their username is unique (already done) but also that we can create a namespace with the same name. If not then we should block user creation.

Rename "Dashboard" tab to "Activities"

As the dashboard is not fully implemented yet, we're currently displaying only activities under the "Dashboard" tab.
I'd advise to rename this as "Activities" until we ship a complete dashboard.

Force that there always has to be an admin user

Imagine the following situation:

1. There are no users in our system, and we create a new admin.
2. Go to the admin page and click the "Users" container.
3. Update the current admin user to not be an admin user.
4. Now there are no admin users.

Even though this might be proper behavior, it's unexpected. I propose two solutions:

1. Don't allow to remove admin rights to the last admin.
2. Cleaner solution imho: don't allow a user to "un-admin" itself. This would protect the user from making any mistakes. Therefore, it should be another admin user the one to "un-admin" this user. This way, we make sure that there's always an admin in the system, and that stupid mistakes cannot happen.

When creating a new team the name of the associated namespace should be shown

We should show the name of the namespace associated with the team during its creation. We should also allow the user to change the proposed name.

Let bootstrap handle the closing of flashy messages

As discussed in the commit 83d5268, bootstrap can handle the closing of flashy messages on its own. This way we maintain less code.

Unnecessary messages for the user

The alerts used when the user Logs in or Logs out are not necessary and should be removed. It's redundant to display a success message "Signed in successfully" (same for logging out) when it is obvious you are inside the admin panel or Portus.

The user profile page is broken

It's broken in two ways:

1. The style. We should update the style of this page.
2. The different forms have not been updated with the changes that we have been doing on the different models. For example, if you now try to update anything (e.g. changing the email), then for me it deletes the user. But anyways, let's imagine that we remove the last button (the one removing users). Then, you find that you can no longer update your email (it will complain about the current password being blank).

Team names must be downcase

Team names are automatically mapped to Docker's namespaces, which must be downcase.

Use Slim syntax for classes and IDs

Replace the .[class="something"] for .something

Collapse input fields after use

Currently, when a new user is added or a namespace is created the input field mask remains visible also after a successful creation.

After a successful insertion the input filed should disappear.

Use typeahead when adding users to a team

Improve the usability of adding a user to a team.
Typeahead or similar (*) should be introduced so to suggest a list of valid users matching the current input of the user.

(*) https://twitter.github.io/typeahead.js/examples/

Allow many users to own a team

A team should be managed by more users, not just by a single owner.

The team owners are the only one that can add/remove users from the team and decide the pull/push permissions of the namespace associated with the team.

Switch to PostgreSQL

We should use PostgreSQL rather than sqlite.

Don't search if the user has not typed anything

In the search box, if the user has not written anything, the search button shouldn't be enabled.

Namespace creation UI

No validation is being done apparently (e.g.: usernames with spaces are accepted).

Docker validates namespace's name using this regexp: [a-z0-9-_]

Show a cancel button when editing the role of a team member

Right now, when you're editing the role of a team member, you have to click the edit button again in order to cancel the action. Instead of clicking the edit button, there should be an obvious way for the user to cancel the action.

Easier creation of the first administrator user

We should make it easier to create the 1st admin user.

Proposed workflow: portus should show an admin signup page until the first admin is created.

Team should have many users

A team should have an owner and many users.

Members of the team are able to pull and push any image inside of the namespace associated with the team.

Sanitize the namespace automatically created upon team creation

Creating a team named "spaces are not allowed" results into the creation of a namespace named "spaces are not allowed".

RFC: do not create a namespace upon team creation

Right now when a new team is created an associated namespace is created as well.

Given:

• we do not have a way to delete teams yet
• this consumes the possible usernames to pick (because the team's name is used to created the associated namespaces, the same thing happens with users)

I would propose to stop doing that. That would also close issue #72

Titles tags are not consistent

Use h1 for main titles in a page (when needed) and h5 inside .panel-heading

Do not allow users to remove their account

We cannot do that yet because Docker's registry does not support removal of contents yet. It should be shipped with version 2.1.

The sign up link is not visible with the current background

Very minor, but not to be forgotten.
The current colour of the Sign up link blends too much in the current background.

Ports conflicting in the Vagrant setup

I'm using Vagrant 1.7.2 and by just calling vagrant up I get the following error from the portus node:

Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 44242 is already in use
on the host machine.

To fix this, modify your current projects Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 80, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding.

I thought to pass the extra-argument auto_correct, but that was not quite working. However if in the Vagrantfile I change all the config.vm.network config lines to node.vm.network, everything seems to work.

Am I missing something or this is really a bug on the Vagrant config ?

Add support for for Roles and type of Namespace icons

In the current namespaces tab we should display next to each namespace two additional icons

• a Role icon
• a Namespace type icon

A Role icon represents the role owned by the user on the namespace (owner | collaborator | viewer).

A Namespace type icon can be of two different types, personal or team.
As a personal namespace is practically speaking a namespace owned by a team composed by only one person, the distinction should be done on the number of members the team is composed of.

Introduce the concept of registry

Add the Registry model to the db. A registry has many namespaces, a namespace belongs to a registry.

For simplicity we will allow just one registry to be created right now.

Validate requests to token endpoint - they should conform with specs of scope

We can use ActiveModel::Validations to build proper pure ruby class

Remove all the `alerts` from our code

For example, when you try to remove a member from a team, it shows an alert dialog. We should use something nicer like Bootstrap's pop-over.

Change the way we create namespaces

It has been pointed out that the way we create namespaces can be a bit confusing. Right now the logic goes as follows: since a namespace belongs to a team (and a team may have multiple namespaces), namespaces for a specific team should be created inside the team page.

Now, this is confusing, because since we have the "Namespaces" tab, the first thing that comes to mind for a user is to create it from there. The idea is to add the form for creating namespaces also in the "Namespaces" tab. In there, we should specify the team too.

So, to sum it up: there should be two ways for creating namespaces, one from the team page (as it is now), and another from the "Namespaces" page.

Inconsistency in strings

The Admin panel displays numbers for all the elements in the panels, however, for the registry we print out the string "None" instead of "0".

Make possible to disable gravatar

We should have an option that makes possible to disable gravatar usage.

The text on the panels from the admin page should be centered

Right now the contents of panels are rendered with Bootstrap's grid system. This can lead to:

Even if subtle, you can tell that the "3" in the image above is not in the center. Moreover, depending on the text, the contents will lean more to the left, and sometimes more to the right, leading to an incosistent situation. That's why the text should always be on the center.

The url of the signup page is wrong after failing to Sign up

If a user tries to sign up and makes a mistake, then it gets redirected to /users, instead of /users/sign_up. This is like this because of the way devise handles errors. This should be handled properly, because in this situation, after failing for the first time the user won't be able to reload the page.

Running in docker

Just wondering if running this in docker will ever be a thing or something people would be interested in.

Hint which users can be selected when adding a member to a team

Right now, you have to know the name of the user before adding to it. It would be much better if there were some kind of auto-completion when adding members to a team.

One idea is to use the chosen library.

Namespace should have different ACL for pull and push requests

Right now a namespace will accept push and pull requests only from the owner of the team associated with the namespace.

It must be possible to allow pulls also from registered users outside of the team.

Don't show the description of teams, descriptions, etc. in their different pages.

For example, the namespaces page should not describe what a namespace is. This belongs to documentation (.io page or wiki), not in Portus itself.

The login page is not centered

The login mask is not properly placed in the middle of the screen.

Handle global namespaces

Right now we do not allow users to pull and push to the global namespace. We should change that.

Every time a new Registry entry is created we should immediately create a Namespace with name nil and public set to true. Only admin users should be allowed to push to this namespace. We should also show this namespace in a special way inside of the UI.

Introduce "owned by" team in the namespace detailed view

By clicking on a namespace presented in the namespace tab, the name of the namespace will be presented in the header of the table:

This should be accompanied by a "owned by" followed by the name of the team to which the namespace belongs to.
In the best case (and not strictly necessary), for personal namespaces this could be omitted, not to display entries like
Namespace federica owned by federica

Introduce the concept of admin user

There must be users with more power than the others.

unsynced Clocks produces nbf to fail as it issued on before time actual on registry

Flashy messages don't disappear

This is a regression that can be reproduced at the master branch. Basically, when you click the cross of a flashy message to make it disappear, it just erases the contents of it but it doesn't disappear. Like this:

Team name should be unique

This is not enforced right now.

UI to manage teams

This issue tracks the creation of the pages required to:

• create a team
• manage the users associated with the team

Special handling of personal namespaces

Whenever a new user is create a personal namespace is being created. That involves the creation of a team named like the user, which in turn creates a namespace named as the team itself (and hence as the user).

These personal namespaces should be treated in a special way:

• the associated team should be hidden
• the page of the associated team should not be accessible
• no users can be added/removed from the team
• it is possible only to toggle their public status

Look into issue triggered by creation of a team with a uppercase name

I suspect something goes wrong when creating the associated namespace.

How can I start portus in ubuntu?

Differentiate better the different kind of activities

Right now, all the activities look the same. We should:

1. Expose a different class for each event so it can be properly styled.
2. Re-write some messages to make them more verbose/clear.
3. Re-think about which images to use for each event

Redirect to "Sign up" instead of "sign in" when no user has been created

The whole point is that you cannot log in if no user has been registered. Therefore, by default we should redirect to the sign up page instead of the sign in page when there are no users. Moreover, the sign up page has to be a bit different when there are no users in the system yet:

1. It shouldn't show the "Sign in" link.
2. There should be a text explaining that the first user to be created is the admin user.