Hi Mike, I believe you can use Cloud KMS (Key Management Service) to store private keys in key rings and then encrypt the secrets before they go into your files. Privileged users with the required permissions can use the private keys to locally encrypt the secrets and copy the encrypted values manually into app.yaml whenever new secrets must be added to the app. At runtime / startup the app will authenticate with KMS and get the key to decrypt the environment variables. Additional environment variables would store the information needed to retrieve the private key (project, keyring, key-name). So the source code in the repository and the one deployed to GAE production will not contain any plain secrets. And you can have fine-grain control who has access to the private keys, separately of the source code.
There is the How-to: Storing secrets <https://cloud.google.com/kms/docs/store-secrets> that shows how to use Cloud KMS to store secrets in Cloud Storage, but the concept should work with local app.yaml or other files, too. If you prefer to use Cloud Storage, I suggest to use a project specific bucket (restricted access of course), and put all secrets (encrypted or plain) into a path with the version ID of the app, so the app can programmatically get the secrets appropriate for the current version. Since each version will have its own folder with secrets, e.g. secret-v7-4/, you can still roll-back traffic migration safely if something goes wrong with a new version in production. If the bucket isn't used for anything else you could automate this work-flow by a Cloud Function that is triggered by new (or updated) secret folders and then for example could trigger the app to load the new variables (sending an HTTP request to the app's task handler or so). See this Cloud Storage Tutorial <https://cloud.google.com/functions/docs/tutorials/storage> for such a background function. Unless of course you already use a CI/CD pipeline where you could integrate something like this. In any case, since the encryption/decryption part is a potential cause for failure (e.g. typo in key-ring name, missing secrets files, IAM misconfiguration), the tests should cover this, too. On Monday, May 14, 2018 at 9:23:48 PM UTC+2, Mike Hardy wrote: > > Bumping this. We've been storing our env_variables in app.yaml but we're > adding more team members and we don't want to expose these variables to > everyone. Does anyone have a suggestion for storing secrets in App Engine > Flexible? > > On Saturday, September 9, 2017 at 7:20:44 AM UTC-7, Alex G wrote: >> >> Moving our apps from Heroku to App Engine has been great, but there are a >> few things that we miss. In particular, having a way to define config >> variables <https://devcenter.heroku.com/articles/config-vars> in Cloud >> Console would be great. We have tried a couple of approaches but none are >> optimal: >> >> - Place config within env_variables >> >> <https://cloud.google.com/appengine/docs/flexible/nodejs/configuring-your-app-with-app-yaml#Node.js_app_yaml_Defining_environment_variables> >> >> in the app.yaml file. Not ideal to store secrets since anyone deploying >> the >> app has access to the app.yaml and those secrets. >> - Place config in Cloud Storage. Hard to edit, prone to errors (e.g. >> breaking the JSON file that might contain them) and it doesn't trigger an >> app restart with the updated config (I believe Heroku restarts the app >> every time you change a config variable). >> >> Are there any ideas on implementing a similar feature in App Engine? >> Is there a better way of currently handling those config vars? >> >> Thanks >> > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/31617464-4301-46a7-960e-d98574d9d7a5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
