Why library variable set permission is unscoped?

Cristian Uroz's Avatar

Cristian Uroz

22 Jun, 2017 07:59 AM

Hi, I am using Octopus 3.14.15.

I am playing with VariableEdit and LibraryVariableSetEdit and I found following behavior strange:

  • VariableEdit permission description states: Edit variables belonging to a project or library variable set BUT if I create a team with that permission and I restrict it to only "production" environment users still can add/edit/delete variable-set variables scoped for production environment.
  • This is caused whenever LibraryVariableSetEdit permission is enabled. So, VariableEdit has nothing to do giving permissions to variable-set variables.
  • Also, imho, LibraryVariableSetEdit permission should be related to variable-set metadata (set name and description).

Finally, I think, Octopus should have VariableEdit scoped to project variables and a new LibraryVariableSetVariableEdit scoped permission for variable-set variables. (Maybe also, LibraryVariableSetVariableEditUnscoped in same fashion).

  1. Support Staff 1 Posted by Kenneth Bates on 23 Jun, 2017 12:56 AM

    Kenneth Bates's Avatar

    Hi Cristian,

    Thanks for getting in touch! I can understand the confusion about this behavior, and I'm sorry about that.

    Previously, VariableEdit was required to edit variables in a set. This caused an issue, where if a user's team was scoped to a project, variables in a set weren't able to be edited, as these variables cannot be scoped to projects (variable sets are designed to be project-agnostic, so they can be applied to any project). So we changed the VariableEdit permission to not be related to variable sets. The wording on the permission description wasn't updated with this change, so it's now misleading. You can see this closed issue here.
    https://github.com/OctopusDeploy/Issues/issues/2804

    I've raised the following issue to get that wording fixed which you can track here.
    https://github.com/OctopusDeploy/Issues/issues/3587

    Your idea to have specific permissions for variable set metadata may be a great idea to suggest up on our UserVoice site as well. That way we can gauge how much community support is behind it.
    https://octopusdeploy.uservoice.com/

    I hope this clarifies it and helps! Sorry again about the confusion. Don't hesitate to reach out if you have any further questions.

    Best regards,

    Kenny

  2. 2 Posted by Cristian Uroz on 23 Jun, 2017 02:30 AM

    Cristian Uroz's Avatar

    Hi Kenneth,

    I understand the confusion caused in the past with VariableEdit and edit variables in a set.

    Talking about variable in a set (allow me push a little bit here).
    They are designed to be project-agnostic but those variables can be scoped by environment. To me, it looks more like a bug instead of a UserVoice petition request to just have whole-edit / non-edit-at-all permission (through LibraryVariableSetEdit) for variables in a set.

    Environment scope should be taken into account as it's considered for project variables (through VariableEdit). Something is missing there, don't?

    Where is the point to be able to limit project variables edit by environment and not doing the same for variable sets? For example, users without permission to edit production variables still can change production scoped variables in any variable set.

    Hope this rationale helps to catch your attention and skills to fix it :)

    cris-

  3. Support Staff 3 Posted by Kenneth Bates on 26 Jun, 2017 04:57 AM

    Kenneth Bates's Avatar

    Hi Cris,

    Thanks for following up. I believe I misunderstood what you meant earlier - I'm sorry about that (and for you hitting this unintended behavior). You're correct that the intended behavior is that a user's access to library variables should be limited only to variables that are scoped to the environment that the user's team is also scoped to. Environment scope should be taken into account for variables in sets.

    However, when testing this out on my local instance (running 3.14.15), my user is limited to only library variables scoped to the correct environment, as we would expect. To dig a bit deeper into what's going on in your case, could you attach an export of this user's permissions? You can get that in your web portal under Configuration > Teams > Test Permissions, as shown in our troubleshooting guide.

    I look forward to hearing back and getting to the bottom of this!

    Best regards,

    Kenny

  4. 4 Posted by Cristian Uroz on 26 Jun, 2017 09:18 AM

    Cristian Uroz's Avatar

    Hi Kenny,

    Thanks for taking your time into looking further this issue. Yes, it's exactly what you described in your first paragraph.

    I have a test_user and I tried to give him the smallest permission set to illustrate the problem. I attach the exported file permissions for this user.

    I am using this simple Variable Set (open image in new tab to see it larger):
    img test_user can edit production_var value and scope even his edit capabilities are limited to dev environment and unescoped variables.

    Hope this helps!
    cris-

  5. Support Staff 5 Posted by Kenneth Bates on 27 Jun, 2017 01:19 AM

    Kenneth Bates's Avatar

    Hi Cris,

    Thanks for following up with that extra info - that was perfect! I was able to reproduce what you're seeing, and further testing shows that the EnvironmentView permission is what is deciding access to library variables, where it should be the variable permissions. In other words, if you scope EnvironmentView to Dev and Production, but have VariableView scoped only to Dev, you can see Dev and Production-scoped variables in a set, when the user shouldn't have access to Production variables.

    I've raised an issue to get this resolved, and you can track that here.
    https://github.com/OctopusDeploy/Issues/issues/3591

    Thanks again for your assistance and patience. Please don't hesitate to reach out if you have any further questions.

    Best regards,

    Kenny

  6. 6 Posted by Cristian Uroz on 27 Jun, 2017 02:38 AM

    Cristian Uroz's Avatar

    Hi Kenny,

    Good news! Now I'll just seat and wait for the bugfix to be released :)

    cris-

  7. 7 Posted by Jay on 06 Sep, 2017 02:49 AM

    Jay's Avatar

    Hey OD,

    can we get an update on this issue please?

    We just upgraded from (very old) 2.6.4.951 to 3.16.4 and this is previously working functionality that has since been broken.

    I have just granted read-only access to our auditors who are losing their minds over our developers now having the ability to create and modify production variables. The only alternative that you have provided is that our developers be restricted from seeing anything to do with production environments whatsoever.

    In 2.6, developers could modify library variable set variables that were scoped to sub-production environments (as per their team access), but could not modify or create variables scoped to production.

    The issue was created in June, assigned in July, but has since gone quiet. I'd like to tell my auditors that the fix is scheduled for an upcoming release. What shall I tell them?

    Thanks,

    Jay

  8. Support Staff 8 Posted by Kenneth Bates on 07 Sep, 2017 02:16 AM

    Kenneth Bates's Avatar

    Hi Jay,

    Thanks for reaching out! I'm very sorry you're hitting this annoying issue. It's currently in the process of being resolved, and the fix should be available soon. I'll make sure to reach out to you specifically when it's available.

    I'm sorry again about the inconvenience this issue has caused you. Don't hesitate to reach out if you have any further questions or concerns.

    Kind regards,

    Kenny

  9. Support Staff 9 Posted by Kenneth Bates on 14 Sep, 2017 03:25 AM

    Kenneth Bates's Avatar

    Hi Cris and Jay,

    I'd just like to let you know that this issue has been resolved in Octopus 3.17.1 which has just been released. You can download it on our downloads page.

    Let me know if this resolves this issue, and thank you for your patience!

    Kind regards,

    Kenny

  10. 10 Posted by Jay on 14 Sep, 2017 07:05 AM

    Jay's Avatar

    Great news! Many thanks, Kenny.

  11. 11 Posted by Cristian Uroz on 14 Sep, 2017 07:21 AM

    Cristian Uroz's Avatar

    Thanks Kenny and Jay (to bump this issue)

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

Generic

? 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