Create a role with full API permissions by default. #1277
Comments
|
@skabashnyuk - I'm not sure if this role should be enabled or disabled by default. What are your thoughts? Also this came up with an OEM customer because they were trying to operate on a user's workspace, but the same issue could exist for project, machines and maybe other parts of the model too. |
|
|
|
Yes, I'm not suggesting that all roles have full permissions, but we need one role that either defaults to full permissions or can easily be granted full permissions. The use cases are in the description but imagine a scenario where something is going wrong with a codenvy install and an admin needs to stop a bunch of user workspaces, add RAM to them all and restart them. Right now I think that would require all of those workspace owners to grant the admin permission to do that but if there are 600 workspace owners that's a lot of people to chase down... Another example is an OEM where we are part of an online training solution - the training solution may have a 2 hour timeout for each "free class" but paid classes have no timeouts. There needs to be a way for the training solution outside Codenvy to shut down workspaces when free class workspaces get to the 2 hour timeout. If you want to have a call and discuss let me know. |
User with role
@sleshchenko wdyt ?
Not sure it's good idea. @sleshchenko @gazarenkov wdyt? |
|
Some of the things are dangerous, yes. But it's like a linux root user -
our job isn't to protect people from themselves, it's to notify them
through docs about the potential dangers.
…On Fri, Dec 2, 2016 at 2:34 PM, Sergii Kabashniuk ***@***.***> wrote:
stop a bunch of user workspaces
User with role manageSystem is able to do that
, add RAM to them all
@sleshchenko <https://github.com/sleshchenko> wdyt ?
restart them
Not sure it's good idea. @sleshchenko <https://github.com/sleshchenko>
@gazarenkov <https://github.com/gazarenkov> wdyt?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1277 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHSnChaZLbHeHrTYwVHGeT4CSVe985Kyks5rEHLGgaJpZM4LCnxU>
.
--
Brad Micklea | bmicklea@codenvy.com | 416.707.0792
|
|
In general, I do not think Linux root user is a person who should be able to do anything, it is very simplified view which rather the case of smaller organization which do not really care about fine grained permission access or temporarily when you want to just make it work. What I am saying is that the requirement makes sense but definitely can not be taken as a "best practice" to apply everywhere. That is why we totally reworked access permission model for C4. Actually we do not prevent any of scenarios by model, it is very flexible. **What I am saying is that we need to discuss and solve this in complex like:
|
|
I think this is spiralling away from the original intent.
A simple question: If I install a Codenvy system and need to stop several
user workspaces how would I do that without requesting each workspace owner
grant me permissions?
…On Sat, Dec 3, 2016 at 04:10 Gennady Azarenkov ***@***.***> wrote:
In general, I do not think Linux root user is a person who should be able
to do anything, it is very simplified view which rather the case of smaller
organization which do not really care about fine grained permission access
or temporarily when you want to just make it work.
I suppose latter ("just to make it work for demo" :) ) is the motivation
for this requirement.
*What I am saying is that the requirement makes sense but definitely can
not be taken as a "best practice" to apply everywhere. That is why we
totally reworked access permission model for C4.*
Actually we do not prevent any of scenarios by model, it is very flexible.
It assumes fine grained permissions which potentially can be applied to
user individually, to a group of users.
We do not have the notion of "role" in the core model but this citizen can
be added (Role is a predefined group of Permissions) to simplify management
experience - we assumed this when designed the model.
The good news here is that these things can be done declaratively and
individually per system.
The bad news (but we need to do this anyway) is that it requires
additional entities (probably), settings, tools/UI probably.
**What I am saying is that we need to discuss and solve this in complex
like:
- how to define roles (as a set of permission) per-system and what
kind of defaults we need to have.
- how to change UX to make it accept roles along with atomic
permissions**
So, I would redefine the epic in more generic way and consider a time
for implementing it (apparentkly should be postponed due to Team project)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1277 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHSnCmCpzxvouOTuy23aFjscSQvbeAEDks5rETIXgaJpZM4LCnxU>
.
|
|
You don't have to. Admin is able to do that we just need UI for that. |
|
@skabashnyuk if we mess it this way I think we are in trouble. |
|
let me rephrase my statemented . User with role |
|
Is that a role or permission? I think everything is a permission now so if
a user is granted a `systemManager` permission then they can stop
workspaces without the workspace owner needing to give them permissions?
Or only the workspace owner can grant someone the `systemManager`
permission?
…On Sat, Dec 3, 2016 at 2:53 PM, Sergii Kabashniuk ***@***.***> wrote:
let me rephrase my statemented . User with role systemManager is able to
stop any workspace.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1277 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHSnCmFKcC7Avc1ic2P-1WjNCVkM-PLiks5rEciygaJpZM4LCnxU>
.
--
Brad Micklea | bmicklea@codenvy.com | 416.707.0792
|
|
@skabashnyuk better but we will have to change it for real enterprise usecase I am afraid. It should be more fine-grained. |
|
"manageWorkspaces" permission should be applied on account (organization) level instead |
|
+1
…On Mon, Dec 5, 2016 at 03:26 Gennady Azarenkov ***@***.***> wrote:
"manageWorkspaces" permission should be applied on account (organization)
level instead
then this user is able to manage all the org's workspaces
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1277 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHSnCsuObIR-n6Jm0ljern8_sgcaStL5ks5rE8qXgaJpZM4LCnxU>
.
|
|
User who has |
Problem
Today a Codenvy admin can't directly control a user's workspace/projects/machines until that user grants the admin the permission to do so. This means that by default admins can't fully control the system.
Use Cases
In most large organizations system administration follows a linux user style model where there is a role that has ultimate power (the super-admin or "root" user). This is what people expect and allows them to take charge of the system in the event that there is an incident and fix or change anything that is needed to restore service when workspace owners may not be available.
In white label / OEM situations this is often a critical requirement to the integration. For example, Codenvy may be a part of a larger system and its workspace behavior may need to be changed in response to events outside. Having a super-admin account makes complex, automated relationships between the Codenvy and the other system possible.
There are secure / regulated environments where the existence of a super-admin user may not be allowed. In these cases the customer needs a way to disable the super-admin account.
Requirements
The text was updated successfully, but these errors were encountered: