Jump to: navigation, search

Nova-security-updates

Summary

Make several changes to improve the security of the Nova implementation: 1. Enable HTTPS on the Nova API server, 2. Sign messages between Nova components, 3. Encrypt sensitive user data stored in the database, 4. Implement component type specific access privileges to the database.

Rationale

Provides improved security of the Nova implementation.

Design

1. Nova API Server SSL Configuration

Currently the Nova API Server only supports HTTP communications, not HTTPS, i.e. SSL (SecureSocket Layer) is not used to encrypt network traffic. Having the option to enable SSL would provide improved security.

We propose to add changes to enable SSL in the API servers. No changes to client tools is required, the use of SSL is automatically implemented by using a URL starting with HTTPS instead of HTTP. command line clients use the URL specified in environmental variables.

Proposed changes:

  • SSL enabled/disabled via option in nova.conf
  • Certs/keys also specified via nova.conf/glance-registry.conf
  • Unit test changes to verify both http/https
  • Changes to 'glance' cli command to support connecting to both http/https servers.

2. Implement signing of messages submitted to Message Queue

Currently any Nova component can access any message queue and submit any request. This means that any attacker who gains access to any Nova component could submit a request to any other Nova component.

We propose to add signatures to messages sent to the message server and verification of the signature by the receiver. The receiver can restrict the types of requests to be accepted based on the identity of the sender.

Proposed changes:

  • Add flag to nova .conf to enable message signing.
  • Each component in Nova is issued with a signing key (specified in nova.conf)
  • Sign messages submitted to the message queue
  • Message consumer verifies signature
  • Message consumer determines if sender is authorized to make this request
  • Timestamps or nonce values used to prevent replay attacks
  • Unit test changes to verify signed and unsigned messages

3. Encryption of access/secret keys in the database (may not be needed with Keystone)

Currently user access and secret keys are stored in the database unencrypted.

We propose to encrypt these keys before storing them in the database.

Proposed changes:

  • Add flag to nova .conf to contain encryption key. (Note that access to the nova.conf must be carefully controlled.)
  • Modify database access routines to encrypt the keys when writing to database and decrypt when reading from database
  • Provide database upgrade/downgrade support

4. Implement component type specific database server access privileges

Currently all Nova components share the same user identity when accessing the database.

We propose to implement different user identities for each type of Nova component.

Proposed changes:

  • Each Nova component will obtain different user identity and credential to use for database access (from nova.conf)
  • Modify the database privileges to restrict the access afforded to each user to the subset that they require to perform their intended function
  • Provide database upgrade/downgrade support

UI Changes

No changes are required to the UI.

Code Changes

TBD

Migration

TBD

Test/Demo Plan

TBD

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.