Multiple Visibility Levels and enforcement Levels for Projects #242
Conversation
Signed-off-by: Vadim Bauer <1492007+Vad1mo@users.noreply.github.com>
Vad1mo
changed the title
Vad1mo
changed the title
|
+1 |
|
Perhaps you want to have a way to explicitly tag users as "internal". So internal projects are not accidentally exposed to customers, who have an account to download software delivered to them. Otherwise, I find the proposal quite useful for larger organisations. |
thank you for your input. This is not in scope for this proposal. In this context, internal does not refer to users but to networks, this would be a separate use case IMO. |
| users can view and pull artifacts from this project. | ||
| But they are not allowed to pull any artifact from this project unless they are explicitly added as members to the project. |
There was a problem hiding this comment.
Maybe a copy-pasta issue: In 44 you say "users can view and pull". Next line "But they are not allowed to pull".
| we want the internal projects | ||
| to be visible and accessible inside the organization, but private to the outside. | ||
| The same would apply to pulling artifacts, | ||
| internally without a pull secret and externally just like a private project with a pull secret. |
There was a problem hiding this comment.
what means internally / externally in this context?
|
|
||
| To handle this the internal use case, we would need | ||
| to have a functionality | ||
| that can distinguish between access from internal or external networks. |
There was a problem hiding this comment.
I think adding the complexity of networking here makes the proposal bigger than it needs to be.
For me it's about authorizing all authenticated identities to a project by default.
IMHO adding networking brings much complexity and risk with it.
| that are explicitly added as members to the project to get access, | ||
| based on their access level. | ||
| - **Internal View Only** | ||
| All authenticated (hence authenticated) |
There was a problem hiding this comment.
"hence authenticated", you mean authorized?
add related issue Signed-off-by: Vadim Bauer <Bauer.vadim@gmail.com>
This proposal extends Harbor with additional project visibility and permission levels and upgrades the current public/private project visibility and access, making Harbor Suitable for more use cases.