Certificates and accounts associated with tenanted deployment targets are not validated #6530
Labels
area/security
kind/bug
This issue represents a verified problem we are committed to solving
priority
(obsolete) This issue has been recognised as a priority and should be addressed as soon as possible
release/2020.2
tag/breaking-change
The resolution of this issue introduced a deliberately breaking change
Milestone
This is the 2020.2.18 version of #6529
CVE-2020-16197
Description
A credential scoped to one tenant could be used to affect another tenant in certain circumstances.
Effectively, the logic was previously, "A credential may be used to access this target if it is applicable to any tenant on this target", and has been changed to, "A credential may be used to access this target only if it is applicable to ALL tenants on this target."
For example, given a certificate scoped to Tenant A and a deployment target scoped to Tenant A and Tenant B, the certificate would have previously been permitted to be used by the deployment. To give a more concrete example: with a Kubernetes cluster containing two tenants' application instances, changes made to the cluster can conceivably affect both tenants, so the certificate used to authenticate to the cluster now needs to be scoped to both tenants in order for its use to be permitted.
Affected versions
Octopus Server: 3.4 (since tenants were introduced).
Mitigation / Fix
In some edge cases, it is possible that an account or certificate has been inadvertently reused across tenants where it genuinely should not have been shared.
In this case, we recommend that you:
In the second scenario, it is feasible as a short-term workaround to follow the same steps as in the first scenario (i.e. scope the credential to all the tenants to mimic previous behavior) until the additional accounts/certificates have been provisioned.
Links
The text was updated successfully, but these errors were encountered: