Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distroless image for TF operator #1124

Merged
merged 3 commits into from
Jan 18, 2020
Merged

Distroless image for TF operator #1124

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
167214a
Initial commit for a distroless image
krishnadurai Jan 3, 2020
10392b6
Changing CMD in test infra deployment
krishnadurai Jan 3, 2020
a91c401
Adds / to opt in copy
krishnadurai Jan 9, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 6 additions & 15 deletions build/images/tf_operator/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,26 +1,17 @@
FROM golang:1.10 AS build-image
FROM golang:1.13.5 AS build-image

ADD . /go/src/github.com/kubeflow/tf-operator

WORKDIR /go/src/github.com/kubeflow/tf-operator

RUN go build -o tf-operator.v1 ./cmd/tf-operator.v1

FROM registry.access.redhat.com/ubi8/ubi:latest
FROM gcr.io/distroless/base-debian10
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why base-debian as opposed to base?
https://github.com/GoogleContainerTools/distroless/blob/5a460b2310a3e2e3c0590835614860747d6e8769/examples/go/Dockerfile#L10-L12

Which one is slimmer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jlewi This is a good point.
The sizes are:
base: 60301780
base-debian10: 62581637

I observed that the CVE counts with base image are a little higher: 16 Low priority

anchore-cli image vuln docker.io/krishnadurai/distless-tfop:base all
Vulnerability ID        Package                          Severity          Fix         CVE Refs                Vulnerability URL
CVE-2007-6755           libssl1.1-1.1.0l-1~deb9u1        Negligible        None        CVE-2007-6755           https://security-tracker.debian.org/tracker/CVE-2007-6755
CVE-2007-6755           openssl-1.1.0l-1~deb9u1          Negligible        None        CVE-2007-6755           https://security-tracker.debian.org/tracker/CVE-2007-6755
CVE-2010-0928           libssl1.1-1.1.0l-1~deb9u1        Negligible        None        CVE-2010-0928           https://security-tracker.debian.org/tracker/CVE-2010-0928
CVE-2010-0928           openssl-1.1.0l-1~deb9u1          Negligible        None        CVE-2010-0928           https://security-tracker.debian.org/tracker/CVE-2010-0928
CVE-2010-4051           libc6-2.24-11+deb9u4             Negligible        None        CVE-2010-4051           https://security-tracker.debian.org/tracker/CVE-2010-4051
CVE-2010-4052           libc6-2.24-11+deb9u4             Negligible        None        CVE-2010-4052           https://security-tracker.debian.org/tracker/CVE-2010-4052
CVE-2010-4756           libc6-2.24-11+deb9u4             Negligible        None        CVE-2010-4756           https://security-tracker.debian.org/tracker/CVE-2010-4756
CVE-2015-8985           libc6-2.24-11+deb9u4             Negligible        None        CVE-2015-8985           https://security-tracker.debian.org/tracker/CVE-2015-8985
CVE-2018-20796          libc6-2.24-11+deb9u4             Negligible        None        CVE-2018-20796          https://security-tracker.debian.org/tracker/CVE-2018-20796
CVE-2019-1010022        libc6-2.24-11+deb9u4             Negligible        None        CVE-2019-1010022        https://security-tracker.debian.org/tracker/CVE-2019-1010022
CVE-2019-1010023        libc6-2.24-11+deb9u4             Negligible        None        CVE-2019-1010023        https://security-tracker.debian.org/tracker/CVE-2019-1010023
CVE-2019-1010024        libc6-2.24-11+deb9u4             Negligible        None        CVE-2019-1010024        https://security-tracker.debian.org/tracker/CVE-2019-1010024
CVE-2019-1010025        libc6-2.24-11+deb9u4             Negligible        None        CVE-2019-1010025        https://security-tracker.debian.org/tracker/CVE-2019-1010025
CVE-2019-6488           libc6-2.24-11+deb9u4             Negligible        None        CVE-2019-6488           https://security-tracker.debian.org/tracker/CVE-2019-6488
CVE-2019-7309           libc6-2.24-11+deb9u4             Negligible        None        CVE-2019-7309           https://security-tracker.debian.org/tracker/CVE-2019-7309
CVE-2019-9192           libc6-2.24-11+deb9u4             Negligible        None        CVE-2019-9192           https://security-tracker.debian.org/tracker/CVE-2019-9192

Should we stick to a lower CVE count rather than opting for lesser size?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jlewi Do you have other questions about it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the guidance here:
https://github.com/GoogleContainerTools/distroless/tree/master/base

Unless we need glibc, libssl, or openssl we should be able to use the static image.

The "-debian" suffix is explained here.
https://github.com/GoogleContainerTools/distroless#base-operating-system

So IIUC it looks like base = "base-debian9" which likely has more CVE's then "debian10" probably because it is newer.

So I think we want to use "static-debian10" ?

I checked and it looks like the static images are an order of magnitude smaller than the non static images.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jlewi it seems the go binary which we are using requires C runtime for imports like 'net' packages.

If we build and run on 'static-debian10' we run into this problem:

standard_init_linux.go:211: exec user process caused "no such file or directory"

Since go starts looking for C runtime packages which we are building against.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to build with CGO_ENABLED=0.
Could you try this?
CGO_ENABLED=0 GOOS=linux go build -o tf-operator.v1 -ldflags "-w" -a ./cmd/tf-operator.v1


# TODO(jlewi): We should probably change the directory to /opt/kubeflow.
RUN mkdir -p /opt/kubeflow/samples
COPY third_party/library/license.txt /opt/license.txt

COPY tf_smoke.py /opt/kubeflow/samples/
RUN chmod a+x /opt/kubeflow/samples/*
COPY vendor /opt/

COPY --from=build-image /go/src/github.com/kubeflow/tf-operator/tf-operator.v1 /opt/kubeflow
COPY --from=build-image /go/src/github.com/kubeflow/tf-operator/tf-operator.v1 /opt/

COPY third_party/library/license.txt /opt/kubeflow/license.txt

RUN mkdir -p /opt/kubeflow/vendor
COPY vendor /opt/kubeflow/vendor/

RUN chmod a+x /opt/kubeflow/tf-operator.v1

ENTRYPOINT ["/opt/kubeflow/tf-operator.v1"]
ENTRYPOINT ["/opt/tf-operator.v1"]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probable permission issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. Here's the pattern for moving binaries to a distroless image given by the example:

https://github.com/GoogleContainerTools/distroless/blob/5a460b2310a3e2e3c0590835614860747d6e8769/examples/go/Dockerfile#L10-L12

The idea here is to keep the distroless image with just the essentials for golang and its binaries. That leaves this system with just the user who's running this binary. So I guess setting permissions isn't necessary as advocated by the example.

2 changes: 1 addition & 1 deletion ...p/vendor/kubeflow/core@f7a68336ad7a65c2cbba8462e89d24a10626687e/tf-job-operator.libsonnet
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -102,7 +102,7 @@
containers: [
{
command: [
"/opt/kubeflow/tf-operator.v1",
"/opt/tf-operator.v1",
gaocegege marked this conversation as resolved.
Show resolved Hide resolved
"--alsologtostderr",
"-v=1",
],
Expand Down