Bug 1041525

Summary: [RFE][swift]: Improving the security of Swift's internal network
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/swift/+spec/secure-internal-network-requests
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_approved
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:03:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 16:49:41 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/swift/+spec/secure-internal-network-requests.

Description:

Swift assumes that its internal network (the connections between the proxy and the storage nodes) is secure. Therefore, Swift does not do any sort of on-the-wire encryption or request authorization.

At the San Diego summit, we had a good discussion led by Sam Merritt about how to improve the security of Swift's internal network. After the session, Robert Clark, Sam, and I got together to discuss some of the challenges and possible solutions in more detail.

Generally, the problem being solved is protecting the cluster if there is an attacker on the internal network. How can we prevent that attacker from sending messages to swift servers?

The most obvious solution is to use SSL. This gives us what we are looking for and also allows all of the messages to be encrypted. However, SSL is quite expensive on the object servers. We need to find a different solution.

One solution that will work is to sign each request that comes from swift servers with a shared secret key. If the signature does not match the request, then the request is denied.

Two keys should be supported at any time. This allows for key rotation and phased rollouts. The request signature should be generated in the same way as in existing Swift code (tempurl and formpost): hmac with sha1.

The request signing is good, but it would be nice if we could prevent unlimited replay attacks too. To do this, the servers should have a config option for a request signature TTL. Requests may include a TTL, but the server will use the shorter of the request TTL and the config TTL.

The signature is a hmac of the timestamp and the transaction id. It is validated on the timestamp, transaction id, and that the TTL has not expired.

Specification URL (additional information):

None