HTTPS connection and authentication are not supported between swift-proxy and swift-account-server/swift-container-server/swift-object-server.

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

This seems like a known behavior already documented in the security guide: https://docs.openstack.org/security-guide/object-storage.html#first-thing-to-secure-the-network . Issues around management network are usually triaged as class C1 according to VMT's taxonomy ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ).

This is a known fact of operating Swift clusters, documented in the security guide Tristan linked and also as a proposal for improvement upstream (documented publicly at https://wiki.openstack.org/wiki/Swift/ideas/network_security).

If Swift is deployed on an untrusted network, operators could set up a separate tunneling system without changing Swift or use a VPN. However in practice, TLS connections between proxy and storage nodes can significantly negatively impact data throughput.

Furthermore, the bug reporter is correct that there is no authorization for the Swift storage nodes. If one can make a network connection to them, one can request and access any data on that server.

Since there are ways to mitigate network security concerns, this isn't something that has been prioritized upstream over other work. However, I do agree that out-of-the-box encrypted communications between servers in a Swift cluster is definitely nice to have.

For now, all internal-to-the-cluster network traffic (proxy<->storage and storage<->storage), including all consistency engine traffic, must be deployed on a limited-access network. In the case of multi-region deployments, this includes setting up a VPN between the regions and setting firewall rules (or taking other measures) if the traffic may be seen by entities not part of the Swift cluster.

I do not consider this a security bug that needs an embargo.

Based on John's input above, this is more a class D report (security hardening opportunity) with no need for embargo nor advisory. Triaging accordingly.

I agree with John's analysis i.e. this is publically known. Marking as a wishlist bug for swift.