Create GOOGLE_APPLICATION_CREDENTIALS json file

I had this problem, too. I found a way to make a cred.json file in the build step.

1. Setup a build cmd
2. Prepare npm build script
3. Set the path in env variable

A tricky part is I keep failing to read the JSON file and finally comeup with the solution to encode the JSON to a base64 string and store in env variable. Then, I decode it in the npm run build script to write a JSON file.

Hello

I actually asked an almost- identical question below!!

Looking at your heroku answer it sounds like the best way is just to echo an environment variable to a JSON file during the build step

services:

• build_command: echo $GOOGLE_CREDS > google.json

Alright I spent an entire evening looking at this and I don’t think DO has a good answer. Google Cloud, AWS, Azure all offer their own solutions. Whilst DO Applications are Heroku- platformed (I think), which is hosted on AWS, you can’t make use of AWS’ solutions to this end due to lack of IAM, command line tools in the application instance, etc. So here are your options as I understand it:

1. Try and use one of the above big- platformed solutions’ credential stores OR HashiCorp Vault (Others are available) but most cost $$. They all work in a similar way (Requiring command line tools to fetch data securely from their vault) and look like a real chore to set up with IAM requirements, deploying in a Docker Container to give access to the command line tools if using DO Application, and so on. Not even sure if these would work fully with a DO Application. Not got time to try this out at the moment.

2. Launch your service in a Docker Swarm and use Docker Secrets (Not tried this) - Could be the best solution. For me it means making sure my application works in a Docker Swarm setup though.

3. [what I am doing for now] As I referenced in a previous answer create a build command that uses Bash commands to create your Google_app_creds file. In this case I am storing strings like the private key and project ID in environment variables and using sed to substitute this to the file at build time. This is definitely NOT that secure but better than having the key in a repo. I haven’t tested this end-to-end yet but I am confident it will work.

I will investigate other ways of doing this properly longer term, but for me at least, it allows me to continue development.