CLI exiting with error code 133 on AWS Lambda

magnusboye

Dear One password

I'm currently trying to get the CLI up and running on in a AWS Lambda function running docker.

I'm running Alpine Linux v3.14 in a docker container. And locally everything seems to be working fine. However when pushed to AWS Lambda which is running in a read only mode, then the CLI is exiting with Error code 133 (Trace/breakpoint trap).

I've tried moving the CLI executable to the /tmp directory which is not readonly, and also providing a --config param pointing to /tmp, but that doesn't seems to change anything.

Is this something you've experienced before?

---

1Password Version: 1.11.3 (386)
Extension Version: Not Provided
OS Version: Alpine Linux v3.14

magnusboye

I'm just now seeing that a deamon is used in the CLI, could this have something to do with it?

Ben_1P

Hi @magnusboye

Thanks for writing in! My name is Ben, and I'm one of the developers on the team responsible for the command-line tool.

Would you be willing to share a little more about how you have op set up in your lambda environment? Such as what version of op you're using what is your base docker image, and any additional details that may be relevant.

Also we have a docker image for op https://hub.docker.com/r/1password/op that may help you in getting your script running.

magnusboye

Yes ofc.

I'm running Alpine Linux v3.14
With OP 1.11.3 (386) - Tried multiple versions, and none of them seems to be working.

I've created a repo with a docker container that is pretty easy to deploy to lamda and test out :)
1) git clone https://github.com/whistleblowersoftware/op-test
2) Create Amazon ECR repo
3) Push the docker build up Amazon ECR
4) Create Lambda function from Amazon ECR repo
5) Run test on function and see it fail

Locally it can be testes and works:
1) Git clone
2) "docker build -t test-one-password . --file=.Dockerfile && docker create -i test-one-password"
3) Run the docker command

Docker local response:

Lambda response:

Locally it works just fine ("op --version" returns the version number), but when deployed on Lambda none of them work - maybe because Lambda is running in a read only environment (except for /tmp).

Ben_1P

Hi @magnusboye,

We are looking into this and going to do some testing in AWS Lambda. But in the mean time can you validate you have everything set up according to the aws docs for custom container images. https://docs.aws.amazon.com/lambda/latest/dg/images-create.html#images-create-from-alt

magnusboye

Hi @Ben_1P

Thanks for the response.
I've went ahead and created a backup of the main branch (alpine linux)

The new updates to the master branch makes use of one of AWS's base container images and follows the "normal" lambda Dockerfile structure.

On aws Lambda where it fails
1) git clone https://github.com/whistleblowersoftware/op-test
2) Create Amazon ECR repo
3) Push the docker build up Amazon ECR
4) Create Lambda function from Amazon ECR repo
5) Run test on function and see it fail

Locally it can be testes and works:
1) git clone https://github.com/whistleblowersoftware/op-test && cd op-test
2) docker build -t test-one-password . --file=.Dockerfile && docker create -i test-one-password
3) docker run -p 9001:8080 test-one-password
4) curl -XPOST "http://localhost:9001/2015-03-31/functions/function/invocations" -d '{}'

Ben_1P

Hi @magnusboye,

Thanks for the extra information we are still looking into running op in a lambda environment. Thanks for your patience!

Ben

magnusboye

Hi @Ben_1P

Sorry to be pushy, but any news on this issue?

Best regards
Magnus

artem1P

Hi @magnusboye,

My name is Artem and I work on the same team with Ben. We are still working to have a test environment setup that we will use to test op in AWS Lambda.

Thank you again for your patience and we will make sure to update you as soon as we have something to report!

• Artem

magnusboye

Perfect!

If you need any help regarding setting the test environment up, then I can easily jump in a call - feel free to reach out!

Best regards
Magnus

artem1P

Will do, Thank you Magnus!

Artem

magnusboye

Any updates on this yet? It has soon been 2 months

Best regards
Magnus

artem1P

Hi Magnus,

I apologize for the delay from our side. Our devops team is in the process of setting up an environment that will allow us to use Lambda within the company. They are reviewing the process now and once it is ready we will attempt to reproduce this exact issue. Unfortunately this has been out of our hands, but we hope to have it ready soon.

Thank you again for your patience,

Artem

magnusboye

Just checking in again. Soon to be 3 months.

Again, please - please reach out if you need any help!

We're blocked due to this not working...

Best regards
Magnus

artem1P

Hi Magnus,

We have gotten access to AWS Lambda and have been able to reproduce the same issue in our own environments. Thank you for your detailed instructions on how to reproduce this issue, it really helped speed up the process. My first impression is that this may be caused by the interaction of node with the way in which Lambda runs its processes. However I do not have a solution to propose to you at this time. We will continue to look into this to try and help you alleviate this blocker.

Thank you and I hope to have more details for you soon,

Artem

magnusboye

Hi Artem

Thanks for the response, happy to hear that you are able to reproduce the issue!

My initial problem was actually running it through PHP, node was just easier to set up for reproducing the problem.

Looking forward to hearing more!

magnusboye

A possible problem is that Lambda runs in READONLY mode for all directories except for /tmp directory. Meaning if any script attempts to create new files etc. it won't be able to unless it is in the /tmp directory.

This could be a problem for config files etc.

magnusboye

Any updates?

magnusboye

Bump

simon_1P

Hi @magnusboye,

I'm sorry that you're running into this for so long without a solution.

When signing in to a new account, the CLI stores the account configuration in a configuration file. By default that's stored in ~/.op/config. Could you try overwriting the configuration directory using the --config flag to a directory in /tmp that is writable?

If this doesn't solve it, yes, let's jump on a call together and get it sorted out. I want to help you get up and running with this.

Cheers,
Simon

magnusboye

Hi @simon_1P

Thanks for the response!

I did retry setting it all up again and actually got it running. Not sure if it is due to AWS making changes in Lambda or just updating to the newest version of the CLI

The issue can be closed now :-)

simon_1P

@magnusboye

Awesome, glad this is now working for you!

We'll be here to help in case anything else pops up