In this short video, we will demonstrate how we can configure a custom password policy for Artifactory users in terms of length and complexity. This will allow the Artifactory admins to ensure that their users will set a more secure and complex passwords.
Video Transcript
Hello, this is Nir from JFrog support, and today we're going to talk about how to set path-based permissions for a user or group.
So, we go to our Artifactory instance, as you can see here.
Let's say I have a team of RPM devs, and I want to give them permissions to specifically only really see the RPM repository, and even more specifically, only see this 7-atomic-slush-atomic path, because that's what they're going to be working on.
I don't want them messing around with other projects or other people's things. This team is only for this 7-slush-atomic repository.
So, what we can do is first of all, we need a user which I've already created. We have this user, Alex, and he's in our team-one group, which is going to be our RPM team.
Now, we have to create permissions for that. We can give him read permissions and, like, deploy and such permissions. But how do we set it specifically for that path? That's where path-based permissions come in.
So, let's create a name for our permission: RPM-Devs.
What we're going to do is add our RPM repositories here, and now, what we see here in these include patterns and exclude patterns — these are the paths, these are Ant-like expressions to create a path or exclude a path from our permissions.
Currently, this ** means that everything is applied on everything.
So, what we want to do is, if we do something like this, this expression says: only in these RPM repositories, only this path will have the permissions that we apply here. And you can see that here.
So, that might sound a bit confusing, and here I'll show you.
Let's add our user. You can also add groups whichever one you want, or both and we'll add our permissions.
Now, we'll log in as Alex.
Let's press OK on that.
So, here, now, we only see these RPM repositories because those are the only ones we have permissions for. Before this, we had no permissions on anything.
So, we opened this up, and you see that of that giant RPM repository, we only see the 7-atomic folder, and here we see the information inside of it. So, we only have permissions for this.
But this is my devs, and there's this repo folder that I don't really want them to mess around with too much — it has password files and things like that.
So, what I'm going to do is, let's go back to our admin user that can affect permissions.
We showed how to do an include on the path; now let's do an exclude.
So, we go back to our RPM-Devs permission and we'll edit this.
In the exclude patterns, we're going to do something like repo/7-atomic/**.
Now, it's important that I do this slash /** instead of just ** like this, and I'll show you why.
I'm going to add this pattern, so this path is excluded.
Let's log out and go back to Alex.
Now, theoretically, this repo folder that we saw there should be gone, and we wouldn't even know it exists.
I mean, you can set your permissions to have read access on one but not delete and things like that — so you could still see it but not mess with it.
But currently, we don't see it because we removed all permissions from it because of the exclude pattern.
Another thing is, we made sure not to repost our ** because that would have also taken out this repo data which we want to keep. That's why we did the repo/**.
And that's basically it for path-based permissions.
You can layer them one on top of the other — multiple permission targets — and really customize how you work with your teams and your repositories.