Add an "internal" policy for namespaces

[sly-roar]

Hello!

First of all thank you for your project.

I have deployed Portus at our own environment and was able to connet it with our private docker registry. And I found that I cannot change permission access for global namespace.

I need configure restricted access to our docker registry. So that everybody could pull/push docker images to/from registry only after authentication.
Can I do such behavior using Portus?

Thanks.

[flavio]

Right now this is not possible.

As discussed with issue #279 we are open to the introduction of a "protected" level in addition to "public" and "private".

[mssola]

Maybe instead of protected a better name would be internal, since it would reflect better the purpose of this policy.

[mssola]

I've changed the title to reflect better what's this feature actually about :)

[diranged]

Within the context of this ticket, I think an internal or protected setting makes sense. I think it should be specific to each namespace, and I think that the basic concept is correct. From a naming perspective, I do think internal makese sense for me, but frankly protected makes just as much sense. If other services (gitlab?) use protected, then I'd suggest using that.

[holgerreif]

Just to summarize the discussion (even if it would be clear for involved people) and to add a possible piece for documentation:

Namespaces carry an attribute according to their policy for read access. Read access is required to

• pull images from the namespace
• search for images (once a search endpoint in registry with sufficient access control is available)
• listing of and search for namespaces and respositories at the web UI
  The following access policies are implemented
• a private namespace is accessable only by team members
• a protected namespace is accessable by any authenticated account
• a public namespace is accessable without any authentication
  The policy for each name space is configured by the owner role of the team owning the namespace or by the user for his personal namespace.

As a special case the global namespace can only have the access policy protected or public.

BTW: I don't like the term internal if not only for the fact that private is kind of internal as well.

[mssola]

Namespaces carry an attribute according to their policy for read access

This is relegated to teams. Team admins assign which kind of policy do members have onto the belonging namespaces.

As a special case the global namespace can only have the access policy protected or public.

I think that we never discussed this specific case actually :) I think it's fine to allow admins to set the global namespace as protected (note that push access would still be allowed only for admins).

BTW: I don't like the term internal if not only for the fact that private is kind of internal as well.

Fair enough 😉

[holgerreif]

Namespaces carry an attribute according to their policy for read access

This is relegated to teams. Team admins assign which kind of policy do members have
onto the belonging namespaces.

Whether a namespace is public or not is defined at the namespace level (I doubble-checked - look at pic from doc.

At team level there is a defintion of additional rights (write access for all kinds of namespaces and read access for private namespaces)

As a special case the global namespace can only have the access policy protected or public.

I think that we never discussed this specific case actually

I was more stating, that the global namespace could not be a private one. But just strike protected

[mssola]

Seems like I miss-understood what you were saying, sorry 😅