Understanding how permissions work in Artifactory is fairly easy and you’re unlikely to have any trouble figuring out how to grant the precise permissions that your several users will need. This said, knowing the best way to assign permissions is not obvious. In particular, it’s helpful to get into the habit of setting up groups in which user roles and permissions for your teams/projects are carefully defined.
However, before we offer some handy tips, there are few key points, often misunderstood by our users, which we’d like to clarify:
-
Remote repositories can be seen and reached via two different URLs – the repository-name and the repository-name-cache. The latter functions just like a local repository in that it only serves those files that are present in it. You cannot deploy artifacts directly to a remote repository cache. Should you have a remote repository cache, Artifactory will first try to resolve your artifact(s) from the remote-cache. If your artifact(s) are not present in that location, Artifactory will then try to resolve your artifact(s) from your remote registry. Permissions that are assigned to your remote repository will also apply to its remote-cache.
-
When pulling new files from a remote repository’s URL into a remote-cache, the user performing this request must have deploy/cache permission. Additionally, should the possibility exist that a given remote file will change without a change in the file name (i.e., a checksum change), that user will also need delete/overwrite permission. Granting these permissions to all users, including those who are anonymous, is typically not considered very dangerous as a cache can easily be repopulated from its source following an accidental deletion.
-
The permissions chain looks like: User > Group > Permission Target > Repository. You can assign a permission directly to a user so it looks like: User > Permission Target > Repository. However, this should only be done for special cases, such as when configuring permissions for an anonymous user or a user intended to be used by CI systems or REST API scripts. Note: Permissions granted directly to a given individual user will override any group permissions which were granted to that user.
-
Admin privileges cannot be assigned automatically.
-
During the resolution process, virtual repositories use the permissions of their individual repositories.
As for best practices:
-
Try to discover patterns common to your users and/or projects. You'll generally find that your users have roles within your team that will define the type and variety of permissions they need.
-
Individual roles should be defined within the context of the groups that you define. Your groups can be created manually or, depending on the authentication method in use, 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 will allow you to automatically grant your users specific permissions.
-
You’ll find that certain projects or teams use certain repositories. This can help you when defining a given Permission Target, as your projects will contain your repository list(s). Be aware that these lists can overlap and very often do.
-
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.
-
Permissions you grant will also be split between remote and local repositories due to the need for users of remote repositories to have cache and overwrite permissions. Note: Some feel that granting permission to delete a cache is not exceptionally dangerous and, therefore, it’s safe to set the Any Remote permission to read/cache/overwrite for everyone, including anonymous users. The only exception to this is if any of your remote repositories are pointing to a local repository in another Artifactory instance, which contains sensitive binaries that you don’t want internal users to have access to.