We’ve recently upgraded to Octopus v2018.3.2 (previously on v3.17.1).
Since doing so, users are seeing the following warning/error when viewing the variable tab on any project (https://octopus/app#/projects/MyProject/variables):
You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: CertificateView
We have granted Everyone the CertificateView permission so users don’t see the warning. We’ve not given the CertificateExportPrivateKey so it’s not possible to export the private key via the Octopus UI/API.
However this now means users are able to add a custom step to their projects that would write the certificate variable attributes to disk or send via email and they would then have access to the private key. We don’t want anyone to have access to the certificates or private keys apart from one dedicated team.
A possible workaround would be to go into each certificate and set an Environment restriction so the user can’t deploy the certificate somewhere they have access (although they could still email it!). It also requires this to be set correctly on every new certificate that is imported.
The ideal fix would be for the warning message not to be displayed to users when they go to the variables tab. It should just silently not display the certs if they don’t have access.
Thanks for getting in touch and making the upgrade to 2018. In version 3 the UI around checking
CertificateView permission wasn’t behaving as intended, this at the time was an oversight. In V4 we corrected it to behave how we intended which means the user should have
CertificateView to view variables. The decision was made not to filter the variables returned based on the permission.
What you’ve done is fine, and
CertificateExportPrivateKey shouldn’t be granted, the scoping you mention is also our recommendation for securing it within Octopus.
But on the topic of the user doing something the should not to access the certificates. Could they not achieve that in several other ways, e.g. write code in a package that extracts it and exfiltrate it that way? If they can manipulate the deployment process they can ship any code to the environments they have been granted access to, and do anything they please?
Having said that, we’re doing some major permission work now, and we’re going to have a look at factoring the broader permissions around Certificates and Accounts in the same way we treat scopes. You can follow along here: https://github.com/OctopusDeploy/Issues/issues/4372
We’re trying not to have things silently not show up like they did in V3, that leads to confusion and harder for us to work out if it was intended behavior or a bug/regression.
Thanks for raising the Github issue, I’ll keep an eye on it!
What you say is correct: a user who can modify a package or deployment process can do what they like to environments they have access to.
The issue we have is that our Dev and QA teams are free to update their own deployment processes and deploy to non-production environments as they please. We’re happy for them to do as they please here (approval is required for production). However certificates are not deployed to the same infrastructure. They are only used on our NGINX load balancers which are managed by a different team.
Since there are different businesses using the same Octopus instance here, it’s important that one unit can’t access the certificate of another. Will the new Octopus Spaces RFC solution help us out here or will it not apply to certificates?
Thanks for the extra details. Have you scoped your certificates to Environments does that give you any extra level of isolation for the time being?
Spaces will absolutely solve this, it’s primary objective is to facilitate true segregation of what Octopus stores.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.