Solum/Security
Note: This page is deprecated in favor of a more comprehensive wiki at: https://wiki.openstack.org/wiki/Solum/SecurityRequirements
Contents
- 1 Overview
- 2 Security Best Practices
- 2.1 Logging
- 2.2 Default Secure Configuration
- 2.3 Log Potentially Insecure Configurations
- 2.4 Authentication Backoff
- 2.5 Prevent Authentication Timing Attacks
- 2.6 Secure Storage
- 2.7 Session Management
- 2.8 Cryptographic Algorithms
- 2.9 Clearing Memory
- 2.10 Network Isolation
- 2.11 Digital Signatures
- 2.12 Key Revocation
- 2.13 Execute with Least Privilege
- 2.14 Request Load Management
Overview
This is currently a "living" non-approved discussion of potential security measures that Solum may incorporate. Once we get alignment on the high level topics, blueprints may be created for specific topics.
Security Best Practices
Logging
Identify confidential data which should not be disclosed to end users/customers and flag it in the logs for easy filtering on the backend. Recently Ceilometer had a security issue where logs (INFO level) contained backend database credentials as an example of why this is important. It is strongly recommended to utilize a structured log format such as JSON to hold log data. Caution should be exercised when dealing with personally identifiable information (PII), authentication credentials, local system state (file paths, database schema, etc) and such data.
Default Secure Configuration
The default Solum installation must be placed into a highly secure mode by default. It will be up to the Solum operator to change that configuration.
Log Potentially Insecure Configurations
If there is a configuration option that could potentially expand the attack surface of Solum in a meaningful way, log the configuration option in question and a brief description of the potential results.
Authentication Backoff
In order to prevent dictionary attack spam, failed authentication should trigger backoff times where a user must wait an increasing amount of time before attempting re-authentication. The backoff time should be configurable by the operator.
Prevent Authentication Timing Attacks
There should be no easily discernible difference in response to a valid vs a failed authentication attempt in order to prevent attackers from using timing attacks to locate valid accounts in Solum.
Secure Storage
Confidential data such as credential information should not be stored unencrypted in non-volatile storage. This is a defense in depth topic to place a barrier in front of attackers in the event that they gain access to some of the Solum control plane. Where possible, distribute security responsibilities to user application storage / execution environments. Even encrypted data in non-volatile storage is potentially valuable (especially given the possibility bugs in implementation), creating a high value target. Pushing secure data out as far as possible reduces the value of any individual data store to an attacker.
Session Management
Sessions must timeout and require the user to re-authenticate (suggest making this time configurable by the operator). A logout must cancel all other sessions.
Cryptographic Algorithms
When possible, Solum must use SHA-256 or stronger hashing, RSA-2048 or stronger asymmetric algorithms and AES-128 or stronger symmetric algorithms.
Clearing Memory
It is recommended that confidential data be held in memory the smallest amount of time possible and then zero'ed out as a defense in depth measure. Also clear environment variables which hold confidential data as soon as possible.
Network Isolation
A goal for Solum should be complete network isolation of components that need to communicate with each other while completely denying any other access. This would include entities such as Trove databases which to my understanding is not easy to isolate at this time.
Digital Signatures
It is recommended that any image or component of the system that could affect the security posture be digitally signed and authenticated before usage. RSA-2048 and SHA-256 is the recommendation.
Key Revocation
The system must implement a key revocation system to quickly deactivate potentially compromised keys.
Execute with Least Privilege
All code must run in the least privileged mode and most restricted configuration possible as a defense in depth measure.
Request Load Management
A number of proposed Solum operations are computationally/resource expensive. The fulfilment of those operations should be predictable and linear, and resist denial-of-service or amplification attacks on a per user / project / service basis as needed. This may involve queueing requests, having high water marks for these queues (where additional requests are rejected until existing requests clear), throttling delays on queue processing, separate work pools, or other load management techniques. The system must remain available for other tenants even if a subset are targeted or malicious.
