Secrets Sync

Example scenario

Consider this situation: You need to provide credentials, such as database credentials or API keys, to multiple applications provisioned across various cloud providers. These applications already consume secrets from the secrets manager within their respective cloud environments, or the credentials are hard-coded into the application code. Each application development team needs to manage their own secrets while also having them stored centrally for organizational auditing. Each development team is assigned a tenant namespace in your organization's Vault Enterprise deployment.

The recommended organizational layout would be as follows:

• Root administrators
  • Enable the secrets sync feature.
  • Set up tenant namespaces.
• Application A
  • Resides in AWS and GCP.
  • Managed by application development team A.
• Application B
  • Resides in Azure.
  • Managed by application development team B.
• Application development team A
  • Responsible for the development and integration of application A.
  • Namespace users: Can read and update K/V secrets and associate these secrets with a sync destination.
  • Namespace admins: Have elevated admin rights and can set up and configure sync destinations.
• Application development team B
  • Responsible for the development and integration of application B.
  • Namespace users: Can read and update K/V secrets and associate these secrets with a sync destination.
  • Namespace admins: Have elevated admin rights and can set up and configure sync destinations.

This structure allows each development team to manage their secrets independently, while ensuring centralized auditing and control through Vault Enterprise.