3

To reach a secret stored in GCP's Secret Manager I need a user with the permission todo that, like for instance a SA+roles/secretManages.Accessor. There's no other way we can access the secrets from secret manager. Right?

Is it safe to assume that giving a GCP default account the role above would be safe? projnumber-compute@developer.gserviceaccount.com - Compute Engine default service account

With the above I could potentially build an app to get the secret using the default account and then authenticate with the credential(pseudo-code):

project = "myproject"
# The lines below will use the default account
client = secretmanager.SecretManagerServiceClient()
request = {"name": f"projects/11111111/secrets/mysecret/versions/latest"}
response = client.access_secret_version(request)

payload = response.payload.data.decode("UTF-8")
json_acct_info = json.loads(payload)

# Then use the credential from another SA to authenticate and list buckets
credentials = service_account.Credentials.from_service_account_info(json_acct_info)
storage_client = storage.Client(credentials=credentials, project=project)
buckets = list(storage_client.list_buckets())

Is this safe? :-)

JGG
  • 304
  • 2
  • 12
  • 1
    You should use a custom service account (not the default compute service account) and attach it to your VM/Cloud Run/Cloud Function with the correct permissions. – sethvargo Jun 16 '21 at 17:22
  • Service account key files are rarely the best solution. Use custom service account on your services/compute engine. – guillaume blaquiere Jun 16 '21 at 18:23
  • Oh my, @sethvargo commented in my question. I'm honored. *. * I understand the custom SA is recommended for everything in the cloud. But could you add more info to your comment? I mean, are you recommending the custom account usage to have a really, really least privilege, to have an account with only the SM.accessor role? Thx! – JGG Jun 16 '21 at 19:41
  • @guillaumeblaquiere, what do you mean? I'm not using any key files. I'm using the default service account, without any keys, to get the credential from SM, at runtime, for a given custom SA. Then I switch context because the custom SA has the roles I need to access the resources user by the app. – JGG Jun 16 '21 at 19:47
  • Don't use the default compute service account (#-copute@developer.gserviceaccount.com). Where are you running your workload? – sethvargo Jun 16 '21 at 19:56
  • You already have a service account (you've exported it's service account key into Secret Manager). Instead of exporting the key, just run your workload as that service account. You do not need Secret Manager for this. – sethvargo Jun 16 '21 at 20:07
  • Hey @sethvargo. We run workloads everywhere. App Engine, functions, GKE, GCE... – JGG Jun 16 '21 at 20:32
  • @sethvargo Correct if I'm wrong, but the services in appengine can't use custom accounts or impersonation. Right? So ppl normally store the credentials hardcoded or in config files, if we are talking about multiple services running inside an app engine instance is even worse, we have several services, each one, running with different credentials. – JGG Jun 16 '21 at 21:24
  • @lala. Correct, App Engine is one of the rare service where you can't customize service account (and it's going to change, before or after the summer, it will be possible!). The problem is: If you have a service that require special permission, it will be able to get the key file from SM with its current credentials. however, because all App Engine services have the same "current credentials", they can all get the key file, and thus your "security" is nothing (if a secret is accessible by everyone, it's no longer a secret!!) – guillaume blaquiere Jun 16 '21 at 21:49
  • @guillaumeblaquiere We would be at least removing SA credentials from our code/config files. Avoiding as well credentials leakage when using a version control system. Just to be clear, I'm talking about several services inside an app engine instance, where each service has a connection to several other gcp projects.(please don't judge my company.. lol) – JGG Jun 16 '21 at 22:36
  • No worries, legacy exist!! Even with cloud and App Engine and its 12 years old!! I understand your concern. Storing key file in SM is the best solution compare to hardcoding, source control commit or environment variable definition. I just said that because every service can have access to all the secret (because they all have the same root (App Engin) credentials), it's a useless overload. But, when you will be able to set custom service account per service (soon I hope) your service account will already exist, and it will be simpler/easier. Start like that, change later. – guillaume blaquiere Jun 17 '21 at 06:54
  • Even with AppEngine, you don't need to download a service account key. You can give the AppEngine default service account permissions to impersonate your other service account. Given the DSA permission to "ActAs" the target service account. When you pass auth to your client, specify the `subject` (usually in client options, varies by language) to be the target service account. – sethvargo Jun 17 '21 at 14:42

1 Answers1

0

Yes, this is secure. The act of storing credentials in Google Secret Manager is the whole point of Google Secret Manager.

However, there are two things you can do in addition to this act that will improve the security of your app:

  1. Create a custom service account rather than using the default Compute Engine SA. Using a custom SA makes its name harder to guess, and harder to use in a brute force attack.
  2. If you do pull down creds into temporary JSON keyfile, make sure to delete the keyfile as part of your script as soon as you're done using it. (Obviously, don't delete the secret from GSM, or you'll have a whole other set of problems to deal with.)
ingernet
  • 1,342
  • 2
  • 12
  • 29
  • I know that storing credentials in SM is safe. The question is more like to get answers for the 'chicken and the egg dilemma' that I got into. What is the most secure way to get a credential from secret manager if I need first to have a account authenticated to gcp to read....from the secret manager. Thx for your contribution! ^^ – JGG Jun 16 '21 at 19:58
  • You should never store GCP credentials inside of Secret Manager. Doing so transforms an identity management problem into a secrets management problem. Use custom service accounts or service account impersonation instead. – sethvargo Jun 16 '21 at 20:02
  • @sethvargo I fear I wasn't clear. what I should have said, rather than suggesting that the "custom service account" step was an additional thing, is that you should use a custom SA _instead_ of using the GCP default Compute SA. TBH it never would have occurred to me to store the default SA creds in Secrets Manager because the first thing I do in any project is replace it with a custom SA. oh well! downvote's a downvote. ¯\_(ツ)_/¯ – ingernet Jun 18 '21 at 21:44