@ammario do you also think we should add an admin role that is different than root?

We can limit the admin role.

I think it's useful to draw a distinction between roles and users here. "root" is a user, and in our system today, "admin" is a role.

Some organizations might prefer to deploy with a single "root" user that has the "admin" role, and everyone else, even people who operate the coder deployment day to day have a less powerful role, but I don't think it's universal. We don't currently have the concept of "sudo" in our API, CLI, or Web UI, so it's adding a lot more friction if the operators need to log out and log back in as root to do stuff.

@ammario do you also think we should add an admin role that is different than root?

We can limit the admin role.

Yes. It's unnecessary for MVP but if it's an easy add might as well.

I think it's useful to draw a distinction between roles and users here. "root" is a user, and in our system today, "admin" is a role.

I'm proposing root as a role and not a user. I understand it's a user in Linux. It's easier on the user if we reuse our concept of role instead of creating a new concept of sacred users. If we want to restrict these powers to one user, we could make a special rule around the role that when it's assigned the other assignee is deauthorized.

Some organizations might prefer to deploy with a single "root" user that has the "admin" role, and everyone else, even people who operate the coder deployment day to day have a less powerful role, but I don't think it's universal. We don't currently have the concept of "sudo" in our API, CLI, or Web UI, so it's adding a lot more friction if the operators need to log out and log back in as root to do stuff.

The people who operate the deployment day-to-day will probably use a lesser role based on our current customer behavior. There is friction of logging out and in. The GitHub Enterprise management console has the same problem. A "sudo" could help but I can't think of a product that does that, probably because people don't need god powers that frequently.

If root is a role and not a user, then I don't think I understand how we're proposing this gets used. Can you provide a worked example of what users would exist and what role(s) they would have?

For example

If root is a role and not a user, then I don't think I understand how we're proposing this gets used. Can you provide a worked example of what users would exist and what role(s) they would have?

What I have in mind is the first user is given this root role instead of admin. The MVP is just a rename of the "admin" role, a change to a string constant. As a follow-up, we could create a lesser admin role. Perhaps admin can update, stop and delete workspaces but not shell into them. We should discuss the ideal admin role elsewhere though.

What I have in mind is the first user is given this root role instead of admin.

I feel like this conflicts with:

I prefer "root" since everyone knows you're not supposed to use "root", except transiently. Everyone also knows "root" is dangerous.

By first user I mean the one generated by coderd on startup. It is standard for a product's first user to be given god powers. I can't think of a product that doesn't do that.

Is it standard for that first user login to not be an actual person?

Like, if I, Spike, am setting up a coder deployment, do I name that first user "Spike" and have it be my actual username going forward? If so, then giving it a role called root feels wrong for exactly the reason that it feels dangerous.

If I'm not expected to name it "Spike", and it has god powers that I shouldn't use, then why don't we just name it "root" automatically?

Cloud services like GitHub tend to go with a role called "Owner" for the person who sets things up. I've never seen anything indicating that Owner is dangerous in docs or the site.

OTOH, AWS has a "management account" with godlike powers and actively dissuades people from using it in everyday life: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html

@spikecurtis GitHub's self-installed Enterprise has a Management Console with god-like powers. You can even SSH into the instance. God is far more dangerous in Coder than in applications like GitHub. In Coder, you can steal everyone's secrets and impersonate them.

As for the name of the first user, if we go down the root role route then making sure it's named root or similar makes sense.

owner can mean the same thing, but it seems less dangerous and is typically a role you would wear on your main user.

Maybe we should take a step back and consider if we should give any user, no matter how thoroughly authorized, the ability to view everyone's secrets.

I like the idea of keeping the regular old admin user but only giving them super powers if they do the equivalent of sudo. It would be either time or operation limited and come with a scary banner or CLI colors or what have you.

A "sudo" could help but I can't think of a product that does that, probably because people don't need god powers that frequently.

This doesn't make sense to me. It seems like the logic would go the other way. If you need god powers infrequently, the added step would be little issue. If you need them frequently, then you'd dislike the extra step every time.

They don't use the exact same terminology, but Rippling has a mode switch between regular user and admin mode.

This seems like something that should get customer input. We're relying too much on our own opinions here.

Maybe we should take a step back and consider if we should give any user, no matter how thoroughly authorized, the ability to view everyone's secrets.

Per @dwahler's comments, this exists whether we like it or not since the template administrator can silently change the contents of the template to create a reverse shell or sidecar access. There will always be some concept of a role that can modify templates for the feature to exist, even if the role is reserved for machine users.

I like the idea of keeping the regular old admin user but only giving them super powers if they do the equivalent of sudo. It would be either time or operation limited and come with a scary banner or CLI colors or what have you.

We can add something to the UI to indicate a danger god mode for this role. That seems fine to me, but doesn't preclude the need for the role, and therefore is out of this issue's scope.

This seems like something that should get customer input. We're relying too much on our own opinions here.

This could be a good one for @tjcran to flesh out. Perhaps even getting more validation on our overall access model. But, per my previous points, a god role is inevitable and we have customer evidence that such a role cannot be widely used. We could not create lesser admin role, but I hope we can agree it would be surprising to have no middle ground between god and basic user.

Per @dwahler's comments, this exists whether we like it or not since the template administrator can silently change the contents of the template to create a reverse shell or sidecar access. There will always be some concept of a role that can modify templates for the feature to exist, even if the role is reserved for machine users.

Yes. But we don't need to make it easy. And perhaps with some concentration we can make it even less easy.

I think this type of banner works well for our purposes

@ammario my impression is we can wait on this until post-launch. Do you suggest this is a consideration we should make right away?

@ammario my impression is we can wait on this until post-launch. Do you suggest this is a consideration we should make right away?

This is a rename, I can make the change in 5m, so I don't think it matters when we do it we just have to come to a decision.

I think we should minimize the number of user-visible renamings after we declare v2.0. I kind of prefer "admin" to "root," but I prefer any final decision over a post-v2.0 change.

I think we should minimize the number of user-visible renamings after we declare v2.0. I kind of prefer "admin" to "root," but I prefer any final decision over a post-v2.0 change.

I understand the root rationale, but I'm not sure it conveys anything more serious than 'admin' does, which is also associated with OP god mode.

I think the most important outcome here is more sufficient warnings about the dangers of admin.

I imagine in the future "admin" should be a rare role. A prod instance should have "template-manager" roles or something to that affect for certain user types in the system.

So currently "admin" is almost a stop gap of trying to label all those different users at present. If we have to do a rename later, it could be apart of a larger effort to make deployments set better roles in general.

Not really proposing anything, just voicing some thoughts I had.

I like that suggestion @Emyrk. we make stronger warnings now, but leave god-mode admin labelled as admin. and then in the future when we have more better representative roles for things, admin is really only there for the initial setup and nobody else has full admin and it's not recommended to be used, ever.

@mark-theshark just cited a customer concern with our god-mode admin. Whether or not we rename the roles, we should add the lesser role soon since it's easy.

I have no idea what to call this lesser role other than admin. We could use "superadmin" or "owner" for the root role.

I believe this is too basic to be considered enterprise. Most deployments with >10 users will want this.

There doesn't seem to be consensus on the admin role. However, I think we can make steps towards a solution by creating roles for the things we create admin users for.

For example, it might be a good idea to have a "template-manager" role added that can create and edit all templates site wide. So we don't need to promote users to "admin" to get that functionality.

Opinions? @spikecurtis @ammario @ketang
#3490

There doesn't seem to be consensus on the admin role.

God mode: full access to everything under the sun
Admin: can't shell into other users stuff, but can crud users, templates, workspaces, and has control over all deployment settings
Template admin: site-wide template management ability.

@Emyrk does that seem reasonable?

I spoke with @Emyrk and @f0ssel about this, and we decided on this matrix:

PR by @Emyrk incoming...

Last question. We have User admin, Template Admin, and the god Owner. The 1 thing lacking, is that only an Owner can promote other users to various roles.

What role should be able to give the User/Template admin role so that we don't need any Owners? Should we just allow User Admins to give the roles? Which means they are also effectively Template Admins?

@bpmct @tjcran

@Emyrk — Let's stick with the owner managing roles for now.