fix(build): include CA certificates in Docker image

[obazoud]

Ensure the image contains trusted CA certificates so the app can establish secure HTTPS connections to AWS services. Without them, TLS handshakes fail with x509: certificate signed by unknown authority:

failed to check if infra exists: operation error SQS: GetQueueUrl, exceeded maximum number of attempts, 3, https response error StatusCode: 0, RequestID: , request send failed, Post "https://sqs.eu-west-1.amazonaws.com/": tls: failed to verify certificate: x509: certificate signed by unknown authority

[vercel]

@obazoud is attempting to deploy a commit to the Hookdeck Team on Vercel.

A member of the Team first needs to authorize it.

[Copilot]

Pull Request Overview

Fixes Docker image TLS certificate verification issues by including CA certificates in the final scratch image. This resolves AWS service connection failures caused by missing trusted root certificates.

• Adds CA certificates from the builder stage to the scratch-based runtime image
• Enables secure HTTPS connections to AWS services (SQS, etc.)

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[alexluong]

Hi @obazoud, thank you for opening the PR, really exciting to see a new face on this project and please let me know if you would like any help or insights with the codebase. I know Outpost is still early and the onboarding process for a new developer is not as seamless as it should be.

For the PR, I think your fix may work for you but I want to understand the context a bit. I assume you tried to build a new Outpost image and the existing build/Dockerfile is insufficient?

First, my local workflow is that I run goreleaser locally to build the Docker image which is as close to the released version as possible.

goreleaser release -f ./build/.goreleaser.yaml --snapshot --clean

Now, if you want to use build/Dockerfile, that would work too but I wonder if it's better to use the same base image as build/Docker.goreleaser which is gcr.io/distroless/base.

Let me know what you think and happy to figure out the right solution to the problem you're running into!

[obazoud]

I had some changes in my fork of the repository and wanted to deploy my local version on my development cluster in AWS. To do this, I used this Dockerfile and built the image directly, which is my usual approach since I have a script that automates the build and deployment of a local Dockerfile to ECS, making the process simple and efficient (for me).

However, while testing on my dev cluster, I encountered certificate issues when making calls to AWS services, I created this pull request to address this problem. And another one to cache dependency downloads.

[alexluong]

Thanks for the clarification @obazoud, understood from my end. From the high level, I see 2 main options for us:

1. Outpost removes this Dockerfile and potentially adds a gitignore for build/Dockerfile or build/Dockerfile.local, so you can maintain a local version
2. Outpost continues supporting a Dockerfile like this, but it will be fairly low in terms of priority from the maintainers perspective as it's not part of our workflow.

I personally would prefer option 1 if that works for you, but option 2 works as well. We can certainly merge this PR as well as #482.

For this PR, have you tried gcr.io/distroless/base as base image instead of scratch? I'd like to give that a try so it's more consistent with the official Outpost Docker image.