-1

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?

enter image description here

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

David542
  • 104,438
  • 178
  • 489
  • 842
  • Do you mean that in the same project, there is secret for each company, and you don't want the companies view the secrets of the others, right? If so, is the company must be able to create secret also? or it's for secret access only? – guillaume blaquiere Jan 29 '22 at 13:15
  • What problem are you trying to solve here? What threat(s) are you concerned with? You noted that customers don't use IAM, but IAM is the _only_ want to authenticate to Secret Manager. – sethvargo Jan 29 '22 at 15:40
  • @guillaumeblaquiere yes just as a way to store secrets for a company. – David542 Jan 29 '22 at 20:49
  • @sethvargo yes the central application uses IAM to access the data, the companies themselves (Samsung, General Motors) are only access the application but not IAM directly – David542 Jan 29 '22 at 20:49
  • @guillaumeblaquiere the company would for example, "Enter credentials to connect to a database" and we would store their database credentials in Secret Manager. So they wouldn't store a secret directly, but we would do it behind-the-scenes as necessary. That's the thinking at least... – David542 Jan 29 '22 at 21:04
  • Again, what threats are you concerned with here? – sethvargo Jan 30 '22 at 21:56
  • @sethvargo none. I'm just looking to use best practices when storing sensitive data for multiple organizations and how this is usually handled. – David542 Feb 01 '22 at 03:37
  • 1
    This would at least show the possibilities: https://cloud.google.com/identity-platform/docs/multi-tenancy-managing-tenants – Martin Zeitler Feb 01 '22 at 04:09
  • 1
    @David542 best practices are dependent on the threat model. You also haven't shared enough information to make a recommendation. Secret segmentation is provided by IAM; it doesn't matter whether you separate things at the project, folder, or organization level. – sethvargo Feb 01 '22 at 15:12
  • Since you have invested 500 bounty points, create a good question that can be answered. Do not ask for **best practices**. Instead, clearly define the problem you are trying to solve. Security is a complex topic. Understanding how and what to ask is the first step. Your question is so broad that almost any answer would be good and bad depending on your threat model. In summary, only grant the required access level to secrets for those identities that require access. In Google Cloud that is accomplished by granting an IAM role to the secret. – John Hanley Feb 02 '22 at 19:59

1 Answers1

0

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
  1. Define a name pattern for each secret
  • COMPANY_ID ?
  1. 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)
  1. Use the key ID to get the decryption key from KMS and decrypt the client credentials when you need them
  2. 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.

petrusgomes
  • 317
  • 3
  • 12