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)

  12. 12 Posted by Jay on 17 Dec, 2017 10:47 PM

    Jay's Avatar

    Hi Kenny,

    I've been able to reproduce this bug in both 3.17.4 (which we're currently on) and 4.1.1.

    My reproduction steps are as follows:

    • Role - Variable View

      • CertificateView
      • EnvironmentView
      • LibraryVariableSetView
      • ProjectView
      • VariableView
      • VariableViewUnscoped
    • Role - Variable Edit

      • LibraryVariableSetEdit
      • LibraryVariableSetView
      • VariableEdit
      • VariableEditUnscoped
      • VariableView
      • VariableViewUnscoped
    • Team - Developers (scoped only to DEV environment)

      • Role - Variable View
      • Role - Variable Edit
    • Team - Developers - SIT Visibility (scoped only to SIT environment)

      • Role - Variable View

    A member of both teams is prevented from introducing or modifying SIT-scoped variables in a project. However, that same user can introduce or modify SIT-scoped variables in Library Variable Sets.

    This raises the question: what is the purpose of the LibraryVariableSetEdit permission?

    If VariableEdit paired with a team limited to the DEV scope is sufficient to prevent a user from modifying project variables outside that environment, then why doesn't VariableEdit+LibraryVariableSetView against that same team prevent that user from modifying library variable set variables outside that environment?

    I've worked with the API a bit and have noted that a VariableSetResource is agnostic as to it's parent entity. That is, the very same object is a property of both ProjectResource and LibraryVariableSetResource. Why have permissions work differently between the two?

    I can only speculate that, with this feature working in 2.6.4, broken somewhere between then and 3.16.4, re-instated with 3.17.1 and broken again in 3.17.4 (remaining broken up to the latest version) that you're dealing with Internal Philosophical Differences. At least someone there disagrees with my reasoning and I'm interested to know the counter-argument.

    Following comes from my Audit team who take the separation of duties in the support of banking software pretty seriously (please excuse the formatting):

    Hi Jay,

    As discussed, the review of the proposal to refactor Octopus Deploy team and role >security has identified a the following issue: • Library Variable Set modification capabilities are granted to developers providing >the ability to modify production configuration.

    This issue affects the following requirements of the PCI DSS v3.2 standard (refer to >attachment) Maintain a Vulnerability Management Program Requirement 6 – Develop and maintain secure systems and applications 6.4 – Follow change control processes and procedures for all changes to system components. The processes must include the following: 6.4.1 – Separate development/test environments from production environments, and enforce the separation with access controls 6.4.2 – Separation of duties between developments/test and production environments 6.4.6 – Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable. Strong Access Control Measures Requirement 7 – Restrict access to cardholder data by business need to know 7.1 – Limit access to system components and cardholder data to only those individuals whose job requires such access. 7.2 – Establish an access control system(s) for system components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

    Before the proposal to change role security configuration can be endorsed, this issue needs to be escalated and addressed by Octopus Deploy. Can you please raise a ticket regarding this issue and keep the Information Security and Risk team apprised of the situation, many thanks.

    Regards Linda Timbs

    So, to aid us in complying with PCI DSS requirements, can we resume this conversation?

    Thanks,

    Jay

    P.S. The 4.1.1 look and feel is straight up awesome! I had prototype environments, projects, teams, users etc. set up and a deployment completed in about 5 minutes! Great work!

  13. 13 Posted by Jay on 18 Jan, 2018 12:39 AM

    Jay's Avatar

    Hi OD,

    has this one fallen through the cracks? Should I start a new discussion?

    Jay

  14. Support Staff 14 Posted by Kenneth Bates on 18 Jan, 2018 02:39 AM

    Kenneth Bates's Avatar

    Hi Jay,

    Thanks for following up on this one! This thread did fall through the cracks, and your reply to it brought it back up. I'm terribly sorry about the loss of contact!

    I've just done some testing around the information you provided, and it does indeed look like this issue has re-emerged. It looks like a regression based on some other fixes we've done around version 3.17.4 like you've mentioned. I've reopened the same issue to get this looked into again.
    https://github.com/OctopusDeploy/Issues/issues/3591

    I'm sorry again about the big delay in getting back to you! Thank you kindly for bumping this thread back to my attention.

    P.S. Thank you for the kind words! We're happy you're liking the new look and feel of version 4! (Other than this issue, that is.) :)

    Best regards,

    Kenny

  15. 15 Posted by Hugo Hidalgo on 22 Jan, 2018 04:14 PM

    Hugo Hidalgo's Avatar

    Hi,

    We have the same issue in our Octopus(. Now, All people can edit/view variables of PROD/PRE, This is a big problem of security that it should be fix asap.

    When do you expect to have the solution?

    Regards,
    Hugo Hidalgo
    NEC

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