fine grain access control to subset of repositories within a harbor project

xaleeks commented 4 years ago

Currently, harbor admin can create harbor projects (highest hierarchy) and users added to a project get access to all repositories created within it.

Changes needed for finer grain access controls

decouple members of a projects from repositories of project so it's not all for nothing and increase granularity
Allow users to be configured to have access to a certain set of repositories within a harbor project (still call this ‘project’ for now). Access to repositories can be added or removed at any time.
Allow robot accounts to be configured to have access to a certain set of repositories within a harbor project. Access to repositories can be added or removed at any time.
Allow grouping of users & robot accounts into groups that can then be mapped to specific repos for access, so it’s not all or nothing. Members can be added or removed from these at any time.
Allow configurable permissions (read, write, admin) at the repository level so users or groups of users can get different permissions for different repositories
Needs to resolve with current system of role-based access control where guest / dev / master / admin have specific set of permissions

xaleeks commented 4 years ago

https://docs.google.com/document/d/1AM9XEUjSepv7EgvjSpJXP-2pSBTrExoJsj8XKYN1sZ4/edit

discussions here, ping me for access

turnham-hcl commented 4 years ago

My team is very interested in this feature. I'm not sure if the discussion link above is just for contributors..if not would love to get access. Otherwise, if you need any early adopter validation we'd be happy to try it out. Our primary use case for this would be API-driven, keeping user repository access in sync with another system we have that manages user entitlements.

xaleeks commented 4 years ago

@turnham Thanks, you can detail your requirements on this ticket here or email me. We are looking to make a couple of changes, mainly 1) the ideas described here around grouping of users and permission mappings to existing projects as well as 2) add more granularity to existing harbor tenancy (ie think sub-project within a project) for better isolation. I've shared the doc w/ you

DASXCE commented 4 years ago

Hi Team,

Are there any plans to allow Project Admins, maybe even Masters, to configure and trigger replications for their own projects?

hyy0322 commented 4 years ago

@xaleeks Hi, I'v requested doc access. Please let me in, thanks.

hyy0322 commented 4 years ago

This issue is talking about subset of repositories within a project. Here I want to introduce our requirements about Harbor.

In our cloud environment, we use tenant to separate all kinds of resources such as users, projects, applications, calculating resource like cpu, memory. Because tenant is not support in Harbor, so we have to maintain relationship between a certain set of projects and a certain set of users in a tenant in out database to restrict a user with limited permissions for certain set of projects in a tenant.

So in multi-tenant cloud environment, we have some requirements in access control about Harbor.

Support tenant concept.
Projects and users can be separated by tenants.
Certain projects can be shared among certain tenants, especially for public projects.
Allow users to be configured to have access to a certain set of projects within a tenant, or have access(read) to a certain set of projects(public) in other tenants.
Tenant manager have access to all projects in his/her tenant, and can access(read) a certain set of projects(public) in other tenants.

I think repos in projects like @xaleeks mentioned is much like projects in tenants. So other access control detail is quite similar to @xaleeks mentioned above

/cc @gaocegege, do you have anything else to add or detailed?

phin1x commented 3 years ago

@xaleeks are there any updates on this issue or a timeline when this feature will be implemented? especially granting global roles to users would be great.

manuelnucci commented 3 years ago

@xaleeks what would be the best way with the current features of Harbor to have granularity by Users and Robot Account? One project per microservice?

Does this issue aims to ease the management of different artifacts of different environments in the same project, and provide specific Service Accounts to specific pipelines?

adamkdean commented 2 years ago

This is a feature we would also find super useful. Currently we're restricted by the inability to have per-repo permissions for robot users.

warmfusion commented 2 years ago

We have the same problem. We're using gitlab-ci to build projects, and have different project teams pushing containers to their respective projects in harbor. Some teams collaborate and use eachothers images as part of their CI/CD pipelines but are unable to access the images due to the robot being used for their own project not being able to read from the other project.

If robots could be granted membership like regular users we'd be able to progress, however when attempting to add robot@project+ci-bot to the other project I recieve a server error.

smveloso commented 2 years ago

Very interested in this feature.

If it gets to be implemented, I wonder if assigning quotas at the "subproject" level would also be useful. It seems to me that it would make sense because today quotas are also restricted to the highest hierarchy level.

burghard-britzke-drv commented 2 years ago

This issue is open since 2019 with no commit until now. Are there any plans to work at a finer grained access control by the harbor project?

github-actions[bot] commented 2 years ago

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

adamkdean commented 2 years ago

It's relevant, it's just that we're still waiting for the feature