Difference between revisions of "Solum/Logging"
| Line 1: | Line 1: | ||
| − | In order to prevent accidental leakage of confidential information to unauthorized Solum users, there are some guidelines to assist in isolating this confidential data for easy/accurate filtering on the back end log management tools. Logs should have a format that enables grouping of confidential data especially when logging data such as: | + | In order to prevent accidental leakage of confidential information to unauthorized Solum users, there are some guidelines to assist in isolating this confidential data for easy/accurate filtering on the back end log management tools. Why is this important? There have been several OpenStack security issues around logging recently: |
| + | * https://bugs.launchpad.net/ceilometer/+bug/1244476 | ||
| + | * https://bugs.launchpad.net/horizon/+bug/1004114 | ||
| + | * https://bugs.launchpad.net/nova/+bug/1231263 | ||
| + | etc... | ||
| + | |||
| + | Logs should have a format that enables grouping of confidential data especially when logging data such as: | ||
* '''Exceptions:''' Unless the developer is sure that an exception will never contain confidential information, exceptions should be identified as confidential. This has historically been especially problematic with database exceptions which may contain real field data. | * '''Exceptions:''' Unless the developer is sure that an exception will never contain confidential information, exceptions should be identified as confidential. This has historically been especially problematic with database exceptions which may contain real field data. | ||
Revision as of 17:24, 10 December 2013
In order to prevent accidental leakage of confidential information to unauthorized Solum users, there are some guidelines to assist in isolating this confidential data for easy/accurate filtering on the back end log management tools. Why is this important? There have been several OpenStack security issues around logging recently:
- https://bugs.launchpad.net/ceilometer/+bug/1244476
- https://bugs.launchpad.net/horizon/+bug/1004114
- https://bugs.launchpad.net/nova/+bug/1231263
etc...
Logs should have a format that enables grouping of confidential data especially when logging data such as:
- Exceptions: Unless the developer is sure that an exception will never contain confidential information, exceptions should be identified as confidential. This has historically been especially problematic with database exceptions which may contain real field data.
- Recommend parsing the specific exception or error and providing an abstracted/safe version back to the user
- Passwords: Never log plain text passwords
- PII: Minimize Personally Identifiable Information (PII) logging where possible
- Local Server State: Avoid logging local server state which may provide hints to attackers (examples: file paths, code file names, user account names, PRNG state)
- Tenant/Project ID Checking: If a user identifier (tenant/project ID) is not present in the log record or does not match the current authenticated user, do not show this log data to the user
- Log Insecure Configurations: If a Solum configuration option causes the system to enter a potentially less secure state, log a message to this effect for operators to see
OpenStack's Oslo Log is capable of creating formatted logs with a section for confidential data.
Bad Example:
(assuming value is confidential data)
LOG.debug("User set key %s and value %s" % [key, value])
Revised/Good Example:
LOG.debug("User set key %s" % [key], extra={private={value=value}})
Note that the extra->private structure is used to hold all confidential data within logs so that it may be filtered out later before a user views logs.
