Problem/Motivation

Drupal doesn't encourage best practice when storing secrets. For example:

  • Database passwords are stored in plain text in settings.php
  • API keys often end up in configuration which is stored in plaintext in the database and the file system when exported

Other frameworks have secret management baked into the core capabilities. For example, https://symfony.com/blog/new-in-symfony-4-4-encrypted-secrets-management

There is work in contrib, notably https://www.drupal.org/project/key

Proposed resolution

We could follow Symfony's lead and leverage the fact that PHP since 7.2 ships with lib-sodium support so generating a public private key pair and encrypting/decrypting information no longer requires PHP extensions.

The plan could be:

  1. Leverage the dotenv symfony component and allow settings and config overrides to be set from the environment or a .env file.
  2. Add a secrets vault that is also checked for overrides (after the environment)

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

alexpott created an issue. See original summary.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

I'm pretty sure there are existing issues around reading config from environment variables. Going to flesh out the plan and create / or find matching existing tasks.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

Should this go in the ideas queue first for product manager sign-off

Pretty sure there's existing issues in that queue for encryption

Plus one from me

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

I couldn't find one myself, though that doesn't mean there isn't one amongst the 22,000 open core issues.

This would be useful for allowing people to encrypt API passwords, security tokens, etc.
(keywords to make it easier to find via the search)

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mcdruid’s picture

mcdruid commented
Related issues: +#3061798: Provide alternative storage options besides configuration

Sorry to add little more than a +1 but this is definitely a problem; I've seen a variety of secrets of varying degrees of sensitivity end up in public repos as a result of being stored in config that ends up being exported and committed.

API keys for things like the recaptcha module are a frequent flyer; linking an issue about that which was closed some time ago but remains valid IMHO.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

encrypted storage variables data API.

(adding more keywords to make this more findable)

solideogloria’s picture

solideogloria commented

I agree that this would be incredibly useful. Accidently committing keys is a concern, and developers with less experience are more likely to assume that the default is secure, when it's not.

pwolanin’s picture

pwolanin commented

There are interesting ideas from symfony about what to support. Their style of key rotation doesn't seem great for us where values are likely in the database an prod rotation happens only on the live site.

prudloff’s picture

prudloff commented
Issue tags: +Security improvements
mxr576’s picture

mxr576
Primary language Hungarian
Location Hungary
commented

FYI, we are working on providing an easy to use and as secure as possible within the given constraints solution for Drupal CMS here. We are waiting for a review from the Drupal Security Team before we would tag a release. Symfony's Vault feature was an inspiration when we made a vote on Sodium sealed box design, but of course, we had Drupalize a couple of things.

https://www.drupal.org/project/easy_encryption
https://project.pages.drupalcode.org/easy_encryption

ghost of drupal past’s picture

ghost of drupal past
he/him
commented

This would be great but I have a hard time imagining how would this work well without lifting Key wholesale from contrib to core.

Now, of course, an argument can be made that in 2026 any self respecting CMS should have that functionality... but I am not making it, I am just raising the potential idea.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

mxr576’s picture

mxr576
Primary language Hungarian
Location Hungary
commented

This would be great but I have a hard time imagining how would this work well without lifting Key wholesale from contrib to core.

Two months passed and since then Easy Encryption has changed and improved a lot.

Easy Encryption uses the Key module under the hood (the default Sodium sealed box encryptor resolves its key material through it), and it also provides integration for storing encrypted data as Key entities. Outside of those two touchpoints, though, the module stands on its own. It has grown into a standalone, pluggable encryption abstraction for Drupal that can work independently of the Key module entirely.

It introduces its own domain for
* Encryption: https://project.pages.drupalcode.org/easy_encryption/architecture/domain...
* Key Management: https://project.pages.drupalcode.org/easy_encryption/architecture/domain...
* even Key Transfer (was a Drupal CMS need): https://project.pages.drupalcode.org/easy_encryption/architecture/domain...

These foundations could be good examples for an Encryption API that could be also added to Drupal core, with or without leveraging Sodium Sealed box design as default encryption, which just works :tm:.

If this idea makes sense, I can update the IS with ideas on how similar low level APIs could provide the secret storage foundations in Drupal core.