[SERVER-43348] Define a configuration file expansion mechanism compatible with Ops Manager credentialstool Created: 16/Sep/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Admin, Security |
| Affects Version/s: | Backlog |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Spencer Jackson | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Server Security
|
||||||||
| Sprint: | Security 2019-12-16 | ||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| Description |
|
We currently allow users to define commands which acquire sensitive configuration material, like passwords. However, not all environments have available secrets management solutions. Ops Manager has provided something called credentialstool which manages a local file containing an encryption key, which is used to decrypt configuration entries. A similar mechanism, or especially a compatible mechanism, would be convenient for these environments. This would allow system administrators to define keys and restrict access to them with filesystem permissions. Casual viewers of the MongoDB configuration file would be able to perform diagnostics, but wouldn't have the ability to learn protected values. |
| Comments |
| Comment by Sara Golemon [ 25/Sep/19 ] |
|
In terms of built-in support for credentialstool encrypted passwords, that would require that the mongod process have access to the encryption key used by credentialstool. That means either including the key in the config itself (bad), opening the keyfile up to being readable by the mongod process (bad in a different way), or running mongod as root (really bad). Alternatively, cloud could extend credentials tool to support decrypting passwords, then use the __exec support already present in config expansions. Such a tool would still have the same set of options for making the encryption key available as above, but would have the additional option of applying /etc/sudoers rules to allow specific non-root users (e.g. uid:'mongo') to run the decrypt command without an interactive password prompt. |