Today, we upgraded from 2019.3.5 LTS to 2019.6.0 LTS. Now, any user whose only membership is on a team having the “Project deployer” role restricted to any set of tenants cannot select the associated environment when deploying a release. This is not a least privilege effect, as I can add an affected user to an additional team without tenant restrictions, and they are then able to deploy to the previously disallowed environment.
This effect persisted through deletion and recreation of the teams and restarts of the server and tentacle services. Health checks of the targets were successful.
For now, I have removed all tenants from roles. This gives more access that we wish to, of course. This was working as expected in 2019.3.5.
Thanks for getting in touch! I’m terribly sorry to hear you’re hitting this unexpected and inconvenient bug. I’ve been able to reproduce this same behavior in the UI and you can track the progress of the bug report at the following link.
I was able to work around this by deploying the release to the environment/tenant with this user’s API key via the Octo.exe deploy-release command (you could also do it via the API). Would this workaround be preferable over giving these users more access than you’d like?
I’m sorry again about this issue you’ve stumbled upon. Please don’t hesitate to reach out if you have any questions or concerns moving forward.
Thank you for the quick turnaround! This functionality is for our internal end users mostly, so the API/octo.exe workaround would be a big ask for them. We can upgrade to 2019.7.0, since we’re interested in the Kubernetes improvement as well…
Thanks for following up, and you’re very welcome! 2019.7.0 is now available on or Downloads page. This fix has also been included in the latest LTS release (2019.6.3).
Let me know how you go or if you have any further questions moving forward.
