Skip to main content
Aggregate Drupal.org Planet Drupal 16 Sep 2026 - 21:03

Metadrop: How to eliminate manual credential sharing in Drupal integrations with a Vault service

RSS 官方收录 · 可信分层展示

关键摘要

Credentials still travel by email and by Slack on projects that are otherwise carefully built.…

  • Every integration with an external service needs them, and forwarding …
  • That habit is avoidable, and avoiding it changes who holds the secrets…
  • The habit of sharing passwords over email or Slack Receiving a passwor…

规则摘要 · 来源可核验

正文提要

Credentials still travel by email and by Slack on projects that are otherwise carefully built. Every integration with an external service needs them, and forwarding them from one party to the next is so routine that the risk rarely gets questioned. That habit is avoidable, and avoiding it changes who holds the secrets and who never has to see them.

The habit of sharing passwords over email or Slack

Receiving a password in plain text over email or Slack is a common occurrence on any Drupal project. It happens because every integration with an external service, whether a payment gateway, a CRM, or a third-party API, requires access credentials. Username and password pairs, tokens, private URLs, and other sensitive data that at some point need to travel from one place to another.

These credentials should never go into a code repository or into Drupal's YAML configuration files. The exposure risk is too high. The most common alternative, however, does not solve the underlying problem.

The burden of provisioning credentials in a project

The most widespread practice is to store secrets in a file outside the webroot, or to define them as environment variables accessible only to PHP. This works, but carries an operational cost that becomes apparent as soon as a password needs to change: those files must be edited by hand, and if environment variables are used, reloading Apache or Nginx may be required.

The deeper problem is the…

打开官方原文 站点原文页 可信分区 本信源更多 今日简报 分享图 RSS 稍后再看列表