OpenStack Object Storage (Swift) is a service that provides storage and retrieval of data over HTTP. Objects (blobs of data) are stored in an organizational hierarchy that offers anonymous read-only access or ACL defined access based on the authentication mechanism. A consumer can store objects, modify them, or access them using the HTTP protocol and REST APIs. Backend components of Object Storage use different protocols for keeping the information synchronized in a redundant cluster of services. For more details on the API and the backend components see the OpenStack Storage documentation. For this document the components will be grouped into the following primary groups: Proxy services Auth services Storage services Account service Container service Object service

An Object Storage environment does not have to necessarily be on the Internet and could also be a private cloud with the "Public Switch" being part of the organization's internal network infrastructure.

The first aspect of a secure architecture design for Object Storage is in the networking component. The Storage service nodes use rsync between each other for copying data to provide replication and high availability. In addition, the proxy service communicates with the Storage service when relaying data back and forth between the end-point client and the cloud environment. None of these use any type of encryption or authentication at this layer/tier. This is why you see a "Private Switch" or private network ([V]LAN) in architecture diagrams. This data domain should be separate from other OpenStack data networks as well. For further discussion on security domains please see . Rule: Use a private (V)LAN network segment for your Storage services in the data domain. This necessitates that the Proxy service nodes have dual interfaces (physical or virtual): One as a "public" interface for consumers to reach Another as a "private" interface with access to the storage nodes The following figure demonstrates one possible network architecture.

It is recommended that you configure each service to run under a non-root (UID 0) service account. One recommendation is the username "swift" with primary group "swift."

/etc/swift contains information about the ring topology and environment configuration. The following permissions are recommended: #chown -R root:swift /etc/swift/* #find /etc/swift/ -type f -exec chmod 640 {} \; #find /etc/swift/ -type d -exec chmod 750 {} \; This restricts only root to be able to modify configuration files while allowing the services to read them via their group membership in "swift."

The following are the default listening ports for the various storage services: Service Name Port Type Account service 6002 TCP Container service 6001 TCP Object service 6000 TCP Rsync 873 TCP Authentication does not happen at this level in Object Storage. If someone was able to connect to a Storage service node on one of these ports they could access or modify data without authentication. In order to secure against this issue you should follow the recommendations given previously about using a private storage network.

An Object Storage "Account" is not a user account or credential. The following explains the relations: OpenStack Object Storage Account Collection of containers; not user accounts or authentication. Which users are associated with the account and how they may access it depends on the authentication system used. See authentication systems later. Referred to in this document as OSSAccount. OpenStack Object Storage Containers Collection of objects. Metadata on the container is available for ACLs. The meaning of ACLs is dependent on the authentication system used. OpenStack Object Storage Objects The actual data objects. ACLs at the object level are also possible with metadata. It is dependent on the authentication system used. Another way of thinking about the above would be: A single shelf (Account) holds zero or more -> buckets (Containers) which each hold zero or more -> objects. A garage (Object Storage cloud environment) may have multiple shelves (Accounts) with each shelf belonging to zero or more users. At each level you may have ACLs that dictate who has what type of access. ACLs are interpreted based on what authentication system is in use. The two most common types of authentication providers used are Keystone and SWAuth. Custom authentication providers are also possible. Please see the Object Storage Authentication section for more information.

A Proxy service node should have at least two interfaces (physical or virtual): one public and one private. The public interface may be protected via firewalls or service binding. The public facing service is an HTTP web server that processes end-point client requests, authenticates them, and performs the appropriate action. The private interface does not require any listening services but is instead used to establish outgoing connections to storage service nodes on the private storage network.

The built-in or included web server that comes with Swift supports SSL, but it does not support transmission of the entire SSL certificate chain. This causes issues when you use a third party trusted and signed certificate, such as Verisign, for your cloud. The current work around is to not use the built-in web server but an alternative web server instead that supports sending both the public server certificate as well as the CA signing authorities intermediate certificate(s). This allows for end-point clients that have the CA root certificate in their trust store to be able to successfully validate your cloud environment's SSL certificate and chain. An example of how to do this with mod_wsgi and Apache is given below. Also consult the Apache Deployment Guide # apt-get install libapache2-mod-wsgi Modify file /etc/apache2/envvars with export APACHE_RUN_USER=swift export APACHE_RUN_GROUP=swift An alternative is to modify your Apache conf file with User swift Group swift Create a swift directory in your Apache document root: # mkdir /var/www/swift/ Create the file $YOUR_APACHE_DOC_ROOT/swift/proxy-server.wsgi: from swift.common.wsgi import init_request_processor application, conf, logger, log_name = \ init_request_processor('/etc/swift/proxy-server.conf','proxy-server')

You should run your Proxy service web server as a non-root (no UID 0) user such as "swift" mentioned before. The use of a port greater than 1024 is required to make this easy and avoid running any part of the web container as root. Doing so is not a burden as end-point clients are not typically going to type in the URL manually into a web browser to browse around in the object storage. Additionally, for clients using the HTTP REST API and performing authentication they will normally automatically grab the full REST API URL they are to use as provided by the authentication response. OpenStack’s REST API allows for a client to authenticate to one URL and then be told to use a completely different URL for the actual service. Example: Client authenticates to https://identity.cloud.example.org:55443/v1/auth and gets a response with their authentication key and Storage URL (the URL of the proxy nodes or load balancer) of https://swift.cloud.example.org:44443/v1/AUTH_8980. The method for configuring your web server to start and run as a non-root user varies by web server and OS.

If the option of using Apache is not feasible or for performance you wish to offload your SSL work you may employ a dedicated network device load balancer. This is also the common way to provide redundancy and load balancing when using multiple proxy nodes. If you choose to offload your SSL ensure that the network link between the load balancer and your proxy nodes is on a private (V)LAN segment such that other nodes on the network (possibly compromised) cannot wiretap (sniff) the unencrypted traffic. If such a breach were to occur the attacker could gain access to end-point client or cloud administrator credentials and access the cloud data. The authentication service you use, such as Keystone or SWAuth, will determine how you configure a different URL in the responses to end-clients so they use your load balancer instead of an individual Proxy service node.

Object Storage uses wsgi to provide a middleware for authentication of end-point clients. The authentication provider defines what roles and user types exist. Some use traditional username and password credentials while others may leverage API key tokens or even client-side x.509 SSL certificates. Custom providers can be integrated in using the wsgi model.

Keystone is the commonly used Identity provider in OpenStack. It may also be used for authentication in Object Storage. Coverage of securing Keystone is already provided in .

SWAuth is another alternative to Keystone. In contrast to Keystone it stores the user accounts, credentials, and metadata in object storage itself. More information can be found on the SWAuth website at http://gholt.github.io/swauth/.

In /etc/swift/swift.conf on every service node there is a "swift_hash_path_suffix" setting. This is provided to reduce the chance of hash collisions for objects being stored and avert one user overwriting the data of another user. This value should be initially set with a cryptographically secure random number generator and consistent across all service nodes. Ensure that it is protected with proper ACLs and that you have a backup copy to avoid data loss.