Can't run openssl through Node (using execFile) on Cloud Run

[profyle]

Hi,

I'm having difficulty accessing openssl through node on Cloud Run.

The error is:

Error: spawn openssl ENOENT

The (simplified code is)

execFile("openssl", args, {}, function(error, stdout, stderr) { ... })

 And i have the full command printed to the console:

cmd: 'openssl smime -sign -binary -in /tmp/tmp-19-grWDg7XPLEts -out /tmp/tmp-19-R6SyMgPi2RL0 -signer /usr/src/app/certs/keys/pass.id.pem -certfile /usr/src/app/certs/keys/wwdr.pem -passin pass:REDACTED'

The `-in` and `-out` files exist in tmp storage and I can successfully read these files to the console, so I know they are there.  I can also read out the cert files too.  I dont think its a problem reading the files - i think its a problem accessing openssl.

This runs fine locally on my Macbook Pro.

Any help or pointers would be appreciated!

[ErnestoC]

I deployed a small Cloud Run service, and it was able to use the openSSL CLI from the container with execFile(). How are you deploying your service, are you using a Dockerfile or simply deploying from your current project structure? Are the paths to your files within the container the same as shown in your command? 

According to the documentation, files you write to the container during runtime only persist until the container is shut down, but as for your specific command, the input file and certificates should not be affected. 

[profyle]

Hi,

thanks for your response!

I am deploying directly from my node project directory using the following command:

yarn build; gcloud beta run deploy cloudrun-function-name --source .

I am reading from the files to the log at the same place as the execFile, so I’m confident that the directories are correct.  The certificate files are deployed with the source, only the in and out files are dynamically created and stored as tmp files. Originally I had tried with piping via stdin and and stdout which also didn’t work and hence why I switched to tmp files which I thought would be more reliable. 

the conmand in the original post is directly from the log file as is printed out as part of the error message. 

Any other ideas?

thanks!

[ErnestoC]

In that case, can you add a minimal reproducible example that shows this issue happening? That way I can test a more accurate container to reproduce this error.

[kolban · Accepted solution]

My gut answer is that the Docker Container that is being built is based on a Docker Image that contains NodeJS but does not contain the "openssl" package.  When using Cloud Run, you can build your own Docker Container and name that as the container to run.  However, I sense that in your environment, you aren't building your own container but instead just specifying the NodeJS source and letting Google choose a container to package it into.  Is this correct?  Is there a Dockerfile you have built?  If yes, let's see what it contains.

[profyle]

Hi @kolban you are correct - I don't have my own docker container and instead am allowing the gcloud CLI to build and deploy its own container. 

I had wondered if it was perhaps the version of Node - and therefore the container recipe was not up to date (as my package.json file had specified Node 14), but I have since updated this to Node 16 (as recommended by the Cloud Run documentation).  Unfortunately this has not made any difference.

I have also tried using the "openssl-nodejs" node module, instead of calling directly openssl via execFile - again, no joy.

This all leads me to believe that you are on to something - that its probably something to do with the container that is being built.  Is there any way to control this what this container contains?

[profyle]

Update: although my package.json specified Node 16, my Dockerfile was using node12-slim as the docker image.  I have changed this to node:16 and its working as expected 🙂