Permission cascade

Sebastian Bebrys's Avatar

Sebastian Bebrys

13 Feb, 2018 12:52 PM

Is it possible to achieve access control like so: user who have limited permissions, but can add or edit another users, roles and teams, can't attach permissions that he currently hasn't?

It allow to more flexible manage permissions for leaders, and secure before situation where user extend self permissions through role edition.

  1. Support Staff 1 Posted by Nick Josevski on 14 Feb, 2018 06:46 AM

    Nick Josevski's Avatar

    Hi Sebastian,

    Thanks for getting in touch. The permission system does not support the case you describe. As soon as a user has team edit, they can edit their own team to grant further permissions (with some major exceptions like adding the 'Administrator' permission).

    The permission system is focused on restricting access to Projects and Environments (and Tenants if you use them) in combination with what you can do, e.g. Deploy Project X to Environment Y.

    We are currently working on a feature we're calling Spaces that is designed to partition everything in Octopus, so teams can better self manage in their own Space, I would appreciate some more details from you about the extra level of control on permissions.

    Would you end up with several roles like, "User/team manager who can..."

    • Create users to create and release deployments
    • Create users to manage Environments/Roles
    • Create users to create/edit accounts
    • Create users to edit library variables
    • Create users to help edit teams and roles

    Would that become a management overhead?

    Wouldn't you end up granting them more access over time so they didn't have to find someone else who had greater permissions?

    Aren't you making it harder for these team leaders to be responsible for their area, they would often have to seek assistance from someone with higher permissions as roles and responsibilities grow and change?

    So if we think about trying to solve this with Spaces. If you set up the Spaces so the owner/leader of a Space is truly responsible for what's in it, Feeds, Environments, Projects, Library Variable Sets, etc, is that enough of a security boundary? Does it sound like it would help achieve better segregation of permissions for leaders? Or is there something very specific in your organisation that is driving this desire?

    I look forward to hearing from you.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac