Amazon ECR reports vulnerabilities for the dart development image about dart-docker

[graphicbeacon]

@athomas Thanks for your guidance/advice. I think for AWS I could live with alpine as its just 1 low vulnerability. Perhaps for other platforms like GCP scratch will do just fine.

I resolved the MongoDB connection issue I was having. I just had to close and reopen the connection :) Now I can proceed to creating my next Dart tutorial

[mit-mit]

Hi @graphicbeacon have you tried to build a serving image rather than using the development image for serving?

Here's the suggested Dockerfile from dart create -t server-shelf serverapp:

# Use latest stable channel SDK.
FROM dart:stable AS build

# Resolve app dependencies.
WORKDIR /app
COPY pubspec.* ./
RUN dart pub get

# Copy app source code (except anything in .dockerignore) and AOT compile app.
COPY . .
RUN dart compile exe bin/server.dart -o bin/server

# Build minimal serving image from AOT-compiled `/server`
# and the pre-built AOT-runtime in the `/runtime/` directory of the base image.
FROM scratch
COPY --from=build /runtime/ /
COPY --from=build /app/bin/server /app/bin/

# Start server.
EXPOSE 8080
CMD ["/app/bin/server"]

[athomas]

I didn't go through all of the results, but mostly this is just a scan of what's in Debian buster right now:

buster (misc): 2.28-10
Binary packages: [show 29 binary packages]
bullseye (misc): 2.31-13+deb11u2
Binary packages: [show 28 binary packages]

Per https://dart.dev/get-dart#linux we should upgrade to bullseye anyway, so I created #77.

[graphicbeacon]

@mit-mit Thanks for getting back to me Michael. I have tried the AOT compilation route but ECR throws the following exception when scanning the docker image:

UnsupportedImageError: The operating system and/or package manager are not supported.

@athomas Thanks for creating the PR. I can try this out once merged

[graphicbeacon]

After further investigation the exception appears to be caused by the scratch image

FROM scratch
COPY --from=build /runtime/ /
COPY --from=build /app/bin/server /app/bin/

Works when I disable those lines (still including the vulnerabilities)

[athomas]

ECR just doesn't support scanning FROM scratch images:
https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning-troubleshooting.html

[athomas]

@graphicbeacon Without FROM scratch images can be huge. If you use a full dart image you get about ~750MB. Whether the ECR image scanning is worth the size hit is up to you. You could also use another base image instead of scratch (and similarly the size will be that image + the dart files copied over from the build image). See https://medium.com/google-cloud/build-slim-docker-images-for-dart-apps-ee98ea1d1cf7 for additional context (this is an older version of what we did here, but it informed our decisions for the official image).

Dart provides a full featured development image and instructions to create a minimal production image.

[graphicbeacon]

@graphicbeacon So used the alpine base image which gave me 6MB with just 1 vulnerability(low)!

FROM dart:stable
RUN apt -y update && apt -y upgrade

WORKDIR /app
COPY pubspec.* .
RUN dart pub get
COPY . .
RUN dart pub get --offline
RUN dart compile exe bin/server.dart -o bin/server

FROM alpine
COPY --from=0 /app/bin/server /app/bin/server
# COPY any other directories or files you may require at runtime, ex:
COPY --from=0 /app/public/ /app/public/
EXPOSE 12021
ENTRYPOINT ["/app/bin/server"]

Only problem is that now I have issue connecting to MongoDB database from the running binary.

MongoDart Error: No master connection

Might be unrelated but, is there anything I need to be aware about outgoing connections from the compiled binary?

[athomas]

@graphicbeacon 1 is more than 0 :)

Even with base alpine you still get more of an OS (and therefore a bigger attack surface) than you'll get with a scratch image. But it's a good compromise and there's nothing wrong with going that way. Alpine's also a minimal image and it will grow if you add more packages to it (and it will bring the vulnerabilities of those packages with it). So using alpine for the dart development image isn't a silver bullet. For a minimal production image, it's probably a pretty good choice but not necessarily superior to scratch.

I'm not an "alpine networking" expert, so I'm afraid I don't know the answer to the outgoing connection. I'd try to open a connection to MongoDB with some standard MongoDB client to see if this is a general issue with your setup or a Dart specific issue. If that doesn't help, stack overflow is probably a better place to ask.

[graphicbeacon]

@athomas 1 low vulnerability is less than 114 :)

The Mongo issue is not happening when the Dart server is running in JIT mode. It just might be an edge case with the AOT binary. This ain't your problem however so will go to StackOverflow

[athomas]

The vulnerability report was created using the dart development image (by removing the FROM scratch). This isn't the recommended setup for production where these vulnerabilities don't apply (because they largely refer to code that isn't in the production image, only in the development image).

The development image was upgraded to the latest stable Debian in #77 which addresses some of them (it is still a fully featured image with a lot of dependencies and there are no plans to change that).