Using secret manager across multiple client organizations

Question

Let's say I have an application that is used by two companies. These companies have database (and other) connections that will be stored in Secret Manager:

• Company: General Motors

  • Resource: Oracle Database Credentials
  • Resource: SSH Key XYZ

• Company: Samsung

  • Resource: Postgres Database Credentials
  • Resource: Encryption Key ABC

The companies themselves would never use an IAM to access their secrets, basically we're just trying to use the Secrets Manager as a way to securely store credentials, rather than handling this on our end.

What is the suggested best practice for holding secrets across multiple organizations. Is there a way to physically separate secrets by "client account", or what's the suggested way to set up secrets across multiple client organizations? (Note: I don't mean how to access the secrets or make sure that one client can't see another client's secrets, I mean its implementation on the Google-side and best practices for that).

I suppose one way is to have a Folder for each client organization -- would that help at all?

I suppose this might be a good usage for Multitenancy with GCP ?

Answer 1

Since Secret Manager doesn't offer options to organize the secrets by itself, I don't think it's the best alternative to what you need. But you could do it like:

One Secret per company, using Secret Manager

1. Create a dedicated GCP project for your secrets

• more control over what service accounts and users can access the secrets
• isolate client secrets from your product secrets

2. Define a name pattern for each secret

• COMPANY_ID ?

3. Define a format and contract for your secrets

• Enforce this in your API/SecretService
• I'd suggest a JSON like:

{
  company_id: string,
  secret1: {
    user: string,
    password: string
  }
}

4- Create a CRUD API/SecretService to manage your secrets and enforce the format.

Save secrets in your database using Cloud KMS

1. Use GCP KMS to generate an encryption key for your SecretService
2. Encrypt your client credentials and save them to your regular database

• Save your encryption key ID to the database, with the client credentials (so you can rotate keys)

3. Use the key ID to get the decryption key from KMS and decrypt the client credentials when you need them
4. Rotate keys as needed (there are a few alternatives on how to do this)

Conclusion

I'd go with the second alternative, since it's cheaper (Secret Manager charges per secret), more organized and easier to enforce the credential format.