Understanding permissions in Artifactory is not that hard; You can usually find your way to granting the correct permissions to a user to get things going. Knowing the best way to do that is not as easy. This guide is intended to help you find the best way to manage permissions with as little administrative impact as possible.
Before we begin, there are some key points to make that are often misunderstood by our users:
Remote repositories can be seen and reached via two different URLs. the repository-name and the repository-name-cache. The cache works just like a local repository in that it only serves the files that are present in it, though it cannot be deployed to directly. The remote will resolve files out of its cache if present but will also look outside to it’s remote URL. Permissions assigned to the remote will also apply to its remote-cache.
When pulling new files from a remote repository’s remote URL into the cache, the user performing the request must have ‘deploy/cache’ permission. Additionally, if any of the remote files might change without changing their name (checksum change) the user will need ‘delete/overwrite’ permissions. Giving these permissions to all users, even anonymous is typically not considered very dangerous as a cache can be easily re-populated from the source after an accidental deletion.
The permissions chain looks like: User -> Group -> Permission -> Repository. You can assign a user directly to a permission so it looks like: User -> Permission -> Repository but this should only be done in special cases such as when handling the anonymous user or a user intended to be used by CI systems or REST API scripts. Keep in mind that a user assigned directly to a permission will override any permissions granted by that user’s groups!
Admin privileges cannot be assigned automatically.
Virtual repositories use the permissions of their individual repositories during resolution.
The first step is to find patterns that your users and projects have. Generally you will find that your users have roles within your team that will define what kinds of permissions they will need, such as read-only or deployers. These roles should be defined by the the groups that you define. These groups can be created manually, or depending on the authentication method used, imported into Artifactory. For instance, when using LDAP you can import a group that a specific LDAP user belongs to and assign that group to permission targets. This allows you to automatically grant your users permissions.
Next you will find that certain projects or teams use certain repositories. This should help you define how to create permission targets, as they contain the repository list. These lists can overlap and naturally will. The repositories you choose will not necessarily match up with how you define your virtual repositories as those should be much more about the package type the virtual repository is managing. Note that you will also end up further splitting your permissions between remote and local repositories due to the need for remote repositories to have cache and overwrite permissions. Some feel that because having access to delete a cache is not exceptionally dangerous, it is safe to set the “Any Remote” permission to “read/cache/overwrite” for everyone, including anonymous. The only exception to this is if any of your remotes point to local Artifactory repositories somewhere else that contain sensitive binaries that you don’t want internal users to have access to.
Once you have set up groups to contain your user’s roles and permissions to define your teams/projects, it is time to assign groups to permissions. If you are being careful to make each assignment with a purpose, this will prevent permissions issues in the future.