What are your needs on Defender User Permissions?

Support Defender
1

Hey Defender users! As you may know, you can invite collaborators in Defender to work with you, sharing access to the same Relayers, Autotasks, and Sentinels, and reviewing Proposals as a team. However, today all users within a team have full access to all assets - which is an issue as team grows bigger and they need to restrict access.

With that in mind, we're starting to work on User Permissions for Defender, and there's plenty of ways to go about this. We can limit access per service (eg a user can see Sentinels, edit Relayers, but not access Autotasks), or by network (user can access Testnet but not Mannet), or even per resource (user can access Relayer X but not Y). But there's always a tradeoff between flexibility and ease of use. So with that in mind, we want to know from you:

What user roles would you need in Defender today? For instance, having a set of stakeholder users that can only sign Proposals, and others who focus on monitoring and take care of managing Sentinels.

What environments do you run today on Defender? Do you have testing, staging, and production Relayers and Autotasks? Or do you just use Defender for production? Is staging on a testnet or do you test in prod? Do you use separate email logins for testing and production, or keep everything under a single account?

We'll be sharing more info on this as we move forward with the development, but please share your thoughts!

2 Likes
2

Hey @spalladino !

It's great that you are starting to work on user permissions. I think that for me, the biggest need would be to separate the Relayers from everything else. For example, I would love for someone in my org to be able to handle monitoring through Sentinels, but today that would also mean having access to the Relayers and their funds. And maybe something similar with Autotaks. Having the ability to access some autotaks, but not others.

Regariding the environment, we currently have everything set up for prod only, and it's basically the same set up, duplicated for each network.

1 Like
3

Thanks @NChamo, that's super useful!

I'm curious, what's the difference between these Autotasks, that some of them may be accessible but not others?

4

As for this, how do you manage when you need to do a change across multiple networks? (eg change an Autotask or a Sentinel configuration) Do you make all changes simultaneously, or first on a network and then others? Do you make the changes manually, or have you automated them via API?

5

We just finished creating a github repository with a workflow that takes a network, and updates all our sentinels and autotasks for that network. It does so automatically, using the different npm clients. So we would only need to run the workflow for each network we want to deploy things to.

Since we have the same contracts and addresses on all the networks we deployed to, it was basically a copy-paste, so we wanted to make it a little bit more automatic.

If it's a big change, then I would deploy to one network and test it a little bit before deploying to the others. If not, then I would deploy to all at the same time

1 Like
6

Regarding the different autotasks, I was thinking about trying to secure the relayers and their funds. Some autotaks have a relayer linked, and could use access the funds. While there are other autotasks, that are just to send a more detailed message to Telegram after a Sentinel detects a specific event.

These last autotasks have little to no risk, while the first ones should be managed only by trusted users.

1 Like
7

This sounds awesome! How was the experience? Was it difficult to set up? Any ideas on how we could make it easier?

8

It wasn't that difficult. There were a few minor things that could have made it a little easier, like:

  • Merging both examples repository (this and this)
  • We had some problems customizing the alert body of a sentinel, and I reported it here, but it's already being worked on
  • We run into some typing issues and I'll create a pull request or issues for those

But I think that the easiest for us, would be the ability to set up entities (autotasks, sentinels) for multiple networks. If we had that ability, we wouldn't have created that repository in the first place, we would have done everything directly on the UI. But when we realized we had to duplicate everything, and update all entities with every single change, we realized tried to automate it.

I'm not sure how difficult it would be to do so, but in our case, we are just duplicating all autotasks and sentinels for each network we want to be in. Ideally, we would have one sentinel that listents to multiple chains (in our case we even have the same contract addresses), and we would have one autotask linked to multiple relayers (one on multiple chains)

That's just my two cents, ignore it if it's not possible or worth it haha

1 Like