I then scoped these Space Permissions to just a specific environment. The script console works when using just the environment scoped to, but fails whenever selecting and environment and target.
For example, let’s say I have an environment DEV and PROD. I have 2 machines in each environment, one with role role1 and the other with role2.
I have configured a as role 'Script Consoleas described in the form post linked above. I created a team, and scoped this role to a user only for theDEVenvironment. They can now access the script console and run scripts on machines only in theDEV` environment.
If they select the Select individual deployment targets to run the script on option, they can select any server in the DEV environment as expected. They can also select the Run the script on all deployment targets in set of environments, roles, and tenants and select the DEV environment to run scripts on both servers as expected. If they try to run a script on any machines in the PROD environment, they get a missing permission error as expected.
However, if they select Run the script on all deployment targets in set of environments, roles, and tenants selecting the DEV environment and role role1, they mistakenly get a missing permission error.
Since they can run scripts on all machines in the environment, surely they should be able to filter just machines in that environment that have a specific role. Instead, the current workout is to go to the environment editor, find all the machines that have both the DEV environment and role1 role, and then enter in the machines as Select individual deployment targets to run the script on. For one server this isn’t bad, but when you have many servers, this process is quite cumbersome.
Thanks for getting in touch! That workaround certainly does sound like it would become cumbersome, and I’m sorry to hear you’re hitting this unexpected issue. I haven’t been able to reproduce this same result after setting up the same scenario, however, and selecting an environment and role correctly filters out any unmatching machines which then avoids the missing permissions error.
Could you let me know which version of Octopus you’re currently running? Since I was running 2020.2.14 (current latest) in my local test, I’m wondering if this issue might be a previous bug that has been fixed since.
Please let me know if I’ve misunderstood anything about this issue. If so, or if you’re still hitting it, would you be willing to also send through a permissions export from this affected user so I can make sure my reproduction attempt is perfectly accurate? You can get this export in the web portal under Configuration > Test Permissions, selecting the user and Export.
I’m running the latest Octopus version (2020.2.14).
To add some more detail, it appears that selecting an environment and role will only execute on the intersection of these 2 sets, but will require permissions for the union of these 2 sets.
So for example in my original example: Server1: DEV environment, role1 role Server2: DEV environment, role2 role Server3: PROD environment, role1 role Server4: PROD environment, role2 role
Let’s assume a user only has access to the DEV environment.
When they execute a script in the DEV environment, a permission check appears to be done on all servers matching DEV (Server1 and Server2), and the script will be executed on both Server1 and Server2.
Now, let’s say that they execute a script in the DEV environment and role role1. It appears that the permission check happens for servers matching DEV or role1 (Server1, Server2, Server3). Because they do not have permissions to Server3, the script execution is denied. However, since the script is only executed on servers matching DEV and role1 (Server1), the check should only be on that single server.
For completeness, if they try to execute a script on role role1 servers, the permission check will be done on all servers matching role (Server1 and Server3), and the execution will be denied because they don’t have access to Server3 since it is in the PROD environment.
I attached a file of my test user’s permissions where I’ve done this test. (Note that our Everyone team has fairly generous view permissions, hence all the extra unrelated view permissions). Permissions_export_2020_06_29__06_10_21_UTC.csv (1.3 KB)
Thank you kindly for following up and providing more specifics and the permissions export itself. I’ve tweaked my previous repro attempt to exactly match your setup and that’s allowed me to see the behavior you’re referring to. I’ve raised this as a bug report at the following link for you to track.
Unfortunately the only workaround I’ve been able to think of is what you found, to select the servers individually here.
I appreciate you bringing this our attention, and my apologies again for the confusion and inconvenience this bug has caused! Let me know if you have any further questions or concerns moving forward.