googlecontainertools / kaniko Goto Github PK

See #1 for details

See #44 #7

See #1 for details

See #1 for details

See #1 for details

Congratulations on the launch, and thank you for investing in the direction of secure builds.

From the release's blog post:

an open-source tool for building container images from a Dockerfile even without privileged root access.

Since it doesn’t require any special privileges or permissions, you can run kaniko in a standard Kubernetes cluster, Google Kubernetes Engine, or in any environment that can’t have access to privileges or a Docker daemon.

Unfortunately, running a container as root inside a Kubernetes cluster, does indeed mean giving special privileges/permissions (e.g. PodSecurityPolicy). Under certain definitions of security where state/resourceful actors are involved, running any process (e.g. kaniko) as the root user inside a Docker container, and executing arbitrary code inside that process (e.g. kaniko doing executing a RUN statement that involve 3rd party dependencies), can be considered equivalent to giving root access to the underlying nodes. At least, until userns support is added to Kubernetes, or until alternative runtime become stable (e.g. Kata containers).

Therefore, I am saddened to notice that the previous statements are a bit misleading, and that kaniko will not help us get rid of the isolated nodes/VMs we must use for Gitlab/Jenkins CI.

As an actionable to this issue, I suggest adding relevant notes regarding the security aspects in the README.

See #1 for details

See #1 for details

See #1 for details

tried to set a LABEL but the value in the config was nil so everything broke. should make sure this is fixed for all metadata commands

This is to ensure that the run commands don't inherit kaniko image level environment variables.

• Scale with k8s?
• Test that kaniko works in k8s

Currently environment variables in the executable image are set to defaults, instead they should be set to those in the base image config

From docs for ADD command:
In the case where <src> is a remote file URL, the destination will have permissions of 600

#1

See #1 for details

In many cases, mtime should be sufficient for tracking changes. We should add a flag that only looks at the mtime instead of checking the whole file.

I know MAINTAINER is deprecated and all, but should the build really crash when MAINTAINER is found as command?

See here for more information

We should use something like https://github.com/genuinetools/amicontained

More information here

Should be supported for the following commands:

• ADD

• COPY

• ENV

• EXPOSE

• FROM

• LABEL

• STOPSIGNAL

• USER

• VOLUME

• WORKDIR
  as well as:

• ONBUILD (when combined with one of the supported instructions above)

#1 #40 #41 #7 #16 #12 #11 #13 #15

This includes splitting out non-reproducible tests to a different test type.

See #1 for details

See #1 for details

See #1 for details

A similar project called the "Container Builder Interface" (with more of a slant on defining an interface) was started a while ago. Have you looked a this, and is there any overlap that could result in a collaboration between the two projects?

https://github.com/containerbuilding/cbi

See #1 for details

See #1 for details

See #1 for details

See #1 for details

FROM

• Add support for ARG with FROM

RUN

• Run command in shell form -- RUN , default prefixed by "sh -c"
• Run command in exec form
• Change default shell for RUN command with the SHELL command

CMD

• CMD in exec form
• CMD as default parameters to entrypoint
• CMD in shell form, default prefixed by "sh -c"
• If multiple CMD calls in Dockerfile, only the last should be run

LABEL

• Adds metadata to image (labels are inherited by parent/base images)

EXPOSE

• Expose a port

ENV

• Set environment variables as <key>:<value> pairs in image

ADD
Add has two forms:

• ADD [--chown=<user>:<group>] <src>... <dest>

• ADD [--chown=<user>:<group>] ["<src>",... "<dest>"]

• Copy new files, directories, or remote URLs from <src> to the <dest>

• Multiple sources may be specified, their paths are interpreted as relative to the context of the build

• Support for any <src> to contain wildcards

• <dest> is absolute path, or relative to WORKDIR command

• Specify UID/GID with --chown flag

• If <src> is local tar archive, it is unpacked to destination directory

COPY
COPY has two forms:
-COPY [--chown=<user>:<group>] <src>... <dest>
-COPY [--chown=<user>:<group>] ["<src>",... "<dest>"]

• Allow copy from multiple sources to destination
• Add support for wildcards in <src>
• Specify UID/GID with --chown flag
• Set source location to previous build stage with --from flag

ENTRYPOINT

• Set entrypoint in exec and shell form

VOLUME

• Create a mount point and mark it as holding externally mounted volumes

USER

• Set UID/GID

WORKDIR

• Set working directory

ARG

• Implement ARG

ONBUILD

• Add trigger to metadata of the image, under the key OnBuild

STOPSIGNAL

• Implement stopsignal

HEALTHCHECK

• Implement healthcheck

SHELL

• Override default shell, can effect RUN/CMD/ENTRYPOINT commands

We should scan a directory for Dockerfiles and create one test per Dockerfile instead of adding config.

Instead of looking at the entire filesystem for snapshotting, we only need to add the files changed by ADD/COPY