Problem/Motivation
The module saves the API key in configuration. Which means that the configuration gets exported whenever someone does
drush cex
As per some recommended (debatable) best practices, it is not wise to version control the sensitive data. Which means we only would need to exclude this configuration from being version controlled.
The challenge of following this approach is that the configuration gets lost every time after deployment and after execution of
drush cim
on the server.
Proposed resolution
Use the State API to store the API key. Rest of the configuration can be saved to configuration.
Remaining tasks
Create a patch.
User interface changes
None.
API changes
None.
Data model changes
None.
Comments
Comment #2
perignon commentedState API is volatile memory and not meant to be deployed. API keys must persist for deployments to various development cycles/environments. If you put the API key into the State API then you will have to write extra code to deploy your keys. It can be done, but Drupal's Config API is built to handle this for you.
People with access to the Drupal core's configuration data should be trusted if they aren't then you have other problems. So I do not really see an issue with having the API key in Configuration. Now there has been a long-standing debate about the security of storing information in Drupal as there is no way to encrypt fields. To date, not enough people have got behind the proposals to do anything with them and push the code further for the modules (I went to a DrupalCon session on this topic in 2015). The API keys for credit card processing is stored in the same manner by the Commerce modules. Those keys are even more sensitive than an email service provider key!
Comment #3
drupov commentedMaybe a meaningful workaround:
Add and export any string (e.g. a UUID or anything) as the "apikey" in your configuration and on production add in you settings.php:
$config['sendgrid_integration.settings']['apikey'] = 'your-real-sendgrid-api-key';