Base images and containers

Before jumping into the details, it's worth explaining what the "Base Image" term refers to. Words matter, there is some misunderstanding between the terms "Parent" and "Base" image. As defined by the Docker documentation, a parent of an image is the image used to start the build of the current image, typically the image identified in the FROM directive in the Dockerfile. If the parent image is SCRATCH, then the image is considered a base image.

However, the terms "base image" and "parent image" are often used interchangeably in the container community.

As a quick reminder, today, we're mostly going to talk about the parent image concept, but we'll be referring to them as base images.

To be more precise, there is no such thing as "base" for an image because container images can be created/built in a lot of ways, not only via Dockerfile and not only via Dockerfile that uses "FROM <image-from-a-registry>" in the last stage. To better understand the base images, we should talk about the layers concept of an image first. Container images are made up of layers, a collection of files and folders built one on top of the other and bundled together all the essentials. These layers may be inherited from another image or created during the build of a specific image as defined by the instructions in a Dockerfile or other build process. The first layer, known as the base, is the layer on which all different layers are built and provides the basic building blocks for your container environments. Base images provide a base operating system environment for your containers, whether they're built using a Dockerfile's FROM directive, or Buildpacks, configured by the run-image. Generally speaking, to save time, we make our container images based on ready-made base images available on various registries such as DockerHub, Google Container Registry (gcr.io), and many other public container repositories. But nothing comes for free, right?

Recently, a company called Chainguard the zero-trust company, researched the popular base images that so many people, including us, are using. Unfortunately, from their study, many popular base images downloaded billions of times come with tens or hundreds of known security vulnerabilities. That's a lot of security debt in your image to overcome before you've even started building your applications! To learn more about that research, you can refer to the blog post over here. In addition to that, many base images also include a fully installed operating system distribution which explicitly affects the size of the final image, on the other hand, and it also increases the attack surface of an image.

In the light of the information above, we understand that we should be careful about choosing base images for our container images. If developers don't choose this image wisely, it can lead to critical security risks. Is it enough? Of course not, security is not a static thing, security vulnerabilities pop up every day, and the image with no known vulnerabilities today suddenly becomes a vulnerable image tomorrow, you can't assume that your base images are secure forever. To overcome this issue, we should always scan our base images to identify vulnerabilities and try to make them less vulnerable by applying patches against vulnerabilities before allowing people to use them.

Today, we'll walk you through how we can prevent containers from running if they are not using one of the allowed base images and also reject them if they don't provide any build information as well, don't worry if you don't know what the build information means in the first place, we'll talk about it in detail in the upcoming sections. We'll use Kyverno for policy management on top of Kubernetes clusters and various container image builders that can provide base image information in different ways.

First, let's talk about how we can create build information that contains some valuable information, including which base images were used while building container images. But, wait a minute. We mentioned that a container image is just a collection of layers, so how do we identify which base image was used during the build? Unfortunately, for any client that pulls your image, there is no way of knowing which base image was used during the build process, which means that once your image is built, information about the base image is completely lost. Fortunately, various container image builders have come to the rescue to address the problem here, such as Buildpacks, ko, and Docker BuildKit. We'll discuss all of them and show how they can provide this information.

Let's start with ko, a simple, fast container image builder for Go
applications. Luckily, Jason Hall (@imjasonh), one of the core maintainers of the ko project, worked on an RFC for contributing to Open Containers Initiative (OCI) image-spec about adding the "Base Image" annotations concept into it. You can access the details of his work from here, and finally, OCI approved his RFC, and now, we can add these annotations above to the image-spec manifest to identify which base images were used during the build, which is precisely what ko does for us for free.

The new standard annotations are:

org.opencontainers.image.base.name: the mutable reference to the base image (e.g., docker.io/alpine:3.14)
org.opencontainers.image.base.digest: the immutable digest of the base image at the time the image was built on it (e.g., sha256:adab384…)

Let's see it in action and start with cloning the simple project and installing ko in our environment. To install ko, please refer to the installation page


$ git clone https://github.com/developer-guy/hello-world-ko
$ cd hello-world-ko

This is a straightforward Go application, there is nothing special in it, but the only thing we should mention is that you might notice that there is a .ko.yaml file, which is a configuration file for ko. The default base image config is necessary for this example because there's an issue with annotations on Docker-typed images (Docker V2 Manifest Scheme V2), Docker Manifests don't support annotations, and most base images are Docker-typed and not OCI. Hence, we should use "ghcr.io/distroless/static" as the base or specify –platform=all flag to make a manifest list that supports annotations for ko to set base image annotations successfully.

Once you clone the project, the only thing that you need to do is run the simple command below:

Quick reminder here. You can change the container registry below to one of your favorites. Also, please don't forget to replace your repository name.


$ KO_DOCKER_REPO=docker.io/devopps ko build -B --push --tags buildinfo .

Once the build is finished you can take a look at the manifest to see the base image annotations of an image with a utility called crane which is a tool for interacting with remote images and registries. To install crane, please refer to the installation page.































$ crane manifest devopps/hello-world-ko:buildinfo | jq
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 1059,
    "digest": "sha256:8034a968e1b22bb096c3ba80a35452891f58d988c85b9a18f9dc6787fe1498df"
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 130745,
      "digest": "sha256:d9ae476aa351d26969e1b9122781177e492495f1bc28086cc4240c6cc9d3dd72"
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 127,
      "digest": "sha256:250c06f7c38e52dc77e5c7586c3e40280dc7ff9bb9007c396e06d96736cf8542"
    },
    {
      "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
      "size": 1117260,
      "digest": "sha256:7e857b94ae3abc7a22c7e79bf25aceaa5f78dec8bac86e1a1acbbb1b48da0432"
    }
  ],
  "annotations": {
    "org.opencontainers.image.base.digest": "sha256:2f230f58bd5883ded11612740c3f724f5b9340d29258882eb97e21d5991d8100",
    "org.opencontainers.image.base.name": "ghcr.io/distroless/static:latest"
  }
}

As you can see from the output above, ko did what it claimed it would do and set these annotations for us.

Let's move on with the next container image builder, Docker Buildx. Docker Buildx is built on BuildKit, concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit, technology, and a CLI plugin that extends the Docker command with the full support of the features provided by the Moby BuildKit builder toolkit. To install Buildx, please refer to the installation page.

In addition, BuildKit v0.10 comes with a set of shiny new features, one of them is new build information-structure generation from build metadata. This allows us to see all sources (images, Git repositories, and HTTP URLs) and configurations passed on to your build. This information can also be stored in different ways, such as within the image config or a file. To get more detail about this topic, please refer to the official documentation of the BuildKit project here.

While this feature is automatically activated upon updating to BuildKit v0.10, we also recommend using BuildKit’s Dockerfile v1.4 to reliably capture original image names. You can do so by adding the following syntax to your Dockerfile: # syntax=docker/dockerfile:1.4.
Source: https://www.docker.com/blog/capturing-build-information-buildkit/

As we said, we can store this information in various ways. For example, to keep it in a file, we should use the “–metadata-file” flag or within the image config, which is enabled by default, to make it even more portable across registries, so you don’t have to do anything additional, this is also what we are going to use today.

To start building container images with Buildx, the recommended way is to create a new docker-container builder with Buildx that uses the latest stable version of BuildKit.

Let's create new docker-container typed builder according to the recommendation above.


$ docker buildx create --use --bootstrap --name mybuilder

Once the builder is ready, the next step is to build the project. To do so, we should clone the simple project first.


$ git clone https://github.com/developer-guy/hello-world-buildx
$ cd hello-world-buildx

You will notice that the Dockerfile is designed to be highly optimized and cache-efficient for the Go application. Don't worry if you are not familiar with all of the optimizations within the Dockerfile. There is a blog post to explain everything in detail here.

Let's build our container image with Buildx. To do so, we should run the simple command below:


$ docker buildx build -t devopps/hello-world-buildx:buildinfo . --push

Once the build is finished, let’s look at the image config, not the manifest, with the crane again. As we said, Buildx can keep this information within the image config instead of a file, and this information is stored within a new field called “moby.buildkit.buildinfo.v0” to embed build dependencies.
















$ crane config devopps/hello-world-buildx:buildinfo | jq -r .'"moby.buildkit.buildinfo.v1"' | base64 -D | jq
{
  "frontend": "dockerfile.v0",
  "sources": [
    {
      "type": "docker-image",
      "ref": "docker.io/library/golang:1.17.8-alpine",
      "pin": "sha256:95abb5d5c780126d12a63401acddc9fe0748fab7c5bd498f9961ed5736393049"
    },
    {
      "type": "docker-image",
      "ref": "docker.io/tonistiigi/xx:latest",
      "pin": "sha256:23ca08d120366b31d1d7fad29283181f063b0b43879e1f93c045ca5b548868e9"
    }
  ]
}

Unlike with your metadata file results, build attributes aren’t automatically available within the image config. Attribute inclusion is currently an opt-in configuration to avoid troublesome leaks.

As you can see from the output above, Docker Buildx did what it claimed it would do and keep this information within the image config.

Finally, our next container image builder that provides the build metadata is Clod Native Buildpacks (CNB), Buildpacks for short. Cloud Native Buildpacks transform your application source code into images that can run on any cloud in the simplest form. Cloud Native Buildpacks embrace modern container standards such as the OCI image format. To get more detail about Buildpacks, please refer to the official website here. There are some concepts around Buildpacks that we need to be aware of: "Build" and "Run" images.

Build image: A base image used to construct the build environment in which the buildpacks will run.
Run image: A minimal base image used for the final application image.

Source: https://aws.amazon.com/blogs/containers/creating-container-images-with-cloud-native-buildpacks-using-aws-codebuild-and-aws-codepipeline/

Next, we'll try to find the Run image information within the image config because it's the base image that Buildpacks set for us.

The remote image will have an image digest reference in the runImage.reference field in the io.buildpacks.lifecycle.metadata label
The local image will have an image ID in the runImage.reference field in the io.buildpacks.lifecycle.metadata label if it was created locally

Source: https://buildpacks.io/docs/features/reproducibility/

Before deeping too much dive, let's look at building a container image with the pack, which is a CLI for building apps using Cloud Native Buildpacks. To install pack, please refer to the installation page.

Again, let's start by cloning the simple project:


$ git clone https://github.com/developer-guy/hello-world-buildpack
$ cd hello-world-buildpack

Again, this is a simple Go application, and there is nothing special in it. Therefore, to build it with a pack, the only thing we need to do is use a builder that supports Go applications, and we are going to use "Paketo Tiny Builder" for this purpose.

You can access this information by typing "pack config trusted-builders" command.




$ pack build devopps/hello-world-buildpack:buildinfo \
             --buildpack paketo-buildpacks/go \
             --builder paketobuildpacks/builder:tiny \
             --publish

Once the build is finished, let's look at the image config, not the manifest, with crane again.


$ crane config devopps/hello-world-buildpack:buildinfo | jq -r '.config.Labels."io.buildpacks.lifecycle.metadata"' | jq -r '.stack.runImage.image'
index.docker.io/paketobuildpacks/run:tiny-cnb

As you can see from the output above, Cloud Native Buildpacks did what it claimed it would do and kept this information within the image config.

Last but not least, now we come to the section where we'll discuss how this information can be used. This is also where policy management tools like Kyverno come to the rescue.

Kyverno is a policy engine designed for Kubernetes. Kyverno policies can validate, mutate, and generate Kubernetes resources plus ensure OCI image Supply Chain Security. Today, we'll use Kyverno to validate the base image metadata information of the images we've built with several techniques.

To do so, first, we should install Kyverno v1.7.0 in our Kubernetes clusters:





$ helm install \
    --namespace kyverno \ 
    --create-namespace \
    --repo https://kyverno.github.io/kyverno
    kyverno kyverno

Once the Kyverno pods are ready, the next step would be to apply the previously mentioned policies. These are requiring-base-image for validating the build information, which means that every container image should provide valid build information and allowed-base-images for validating the base image information against the allowed ones to ensure it is a good base image.

Let's apply require-base-image policy first and test it:




$ curl -sSLO https://github.com/kyverno/policies/raw/main/other/require-base-image/require-base-image.yaml && \
sed -i "" 's/audit/enforce/g' require-base-image.yaml && \
kubectl apply -f require-base-image.yaml
clusterpolicy.kyverno.io/require-base-image created

To ensure whether the cluster policy state is ready before moving to the next step:



$ kubectl get clusterpolicies require-base-image
NAME                 BACKGROUND   ACTION    READY
require-base-image   true         enforce   true

Now, it's time to test this with a proper image. Let's choose one of the images that we have built above, and it should succeed:


$ kubectl run hello-world-buildpack --image=devopps/hello-world-buildpack:buildinfo
pod/hello-world-buildpack created

What if I try to run an image without building information? Let's see:








$ kubectl run busybox --image=busybox
Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/busybox was blocked due to the following policies

require-base-image:
  check-base-image: 'validation failure: Images must specify a source/base image from
    which they are built.'

Voilà This is what we expected.

Let's move on to the next policy but before that we should create a ConfigMap that holds the allowed base image list inside of it.













$ kubectl create namespace platform
namespace/platform created

$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: baseimages
  namespace: platform
data:
  allowedbaseimages: '["ghcr.io/distroless/static:latest"]'    
EOF
configmap/baseimages created

We created this ConfigMap with the name of "baseimages" because the policy that we're going to apply is using this name store the base images within a variable.

Let's apply the policy:



$ curl -sSLO https://github.com/kyverno/policies/raw/main//other/allowed-base-images/allowed-base-images.yaml && \
sed -i "" 's/audit/enforce/g' allowed-base-images.yaml && \
kubectl apply -f allowed-base-images.yaml

To ensure whether the cluster policy state is ready before moving to the next step:



$ kubectl get clusterpolicies allowed-base-images
NAME                 BACKGROUND   ACTION    READY
allowed-base-images  true         enforce   true

Let's test this again:












$ kubectl run busybox --image=busybox
Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/busybox was blocked due to the following policies

allowed-base-images:
  check-base-image: 'validation failure: This container image''s base is not in the
    approved list or is not specified. Only pre-approved base images may be used.
    Please contact the platform team for assistance.'
require-base-image:
  check-base-image: 'validation failure: Images must specify a source/base image from
    which they are built.'

As we expected, it failed, let's see what will happen when we try to create a valid pod that contains valid container image:


$ kubectl run hello-world-ko --image=devopps/hello-world-ko:buildinfo
pod/hello-world-ko created

We used an image we have built with ko because if you take a closer look at the "check-base-image" policy, you will notice that
it's gathering build information through OCI image-spec annotations, and ko is considering this approach while providing build information.

Whee!

Build Reproducibility

It is very difficult to rebuild the same container image that you built maybe a month ago using the same Dockerfile. Container image build reproducibility is kind of getting exact same digest over and over again for each new build. It means that image builders produce identical layers given the same input could be said to be a reproducible container image. We can think of it as pinning the digests of the image tags we referenced at the time of building our images since we trust digests. Digest values are used to construct immutable addresses to the objects. This process is called content-addressable storage. BuildKit has been discussing a new concept called Dockerfile.pin for pinning the digests. It will use this file while reconstructing the original image to ensure build reproducibility. On the othe other hand, there is also support for Reproducible Builds made available in The Cloud Native Buildpacks project too.

Day 2 Container Base Image Operations

Out-of-date software is a major factor in security breaches. All base images should be continually updated and aim for zero known vulnerabilities. New vulnerabilities are constantly being discovered and pop up every day. You want to update base image to get rid of some vulnerabilities but don't want to rebuild from scratch? Fine! Luckily, we can rebase our images to enable them to use newer base images. Let's get into to details of how we can accomplish this.

Rebasing

Rebasing is kind of updating your old base image onto a new base image. During rebasing, layers above the original base image layers are snipped out, placed on top of the new base image layers, then pushed back to the registry. The rebased image can be tagged over the original image, or given a new tag. Fortunately, we have various options that supports rebasing images such as crane, Buildpacks.

crane, a registry interaction tool, have a rebase sub command to take care of this stuff. This command also avoids the need to fully rebuild the app. You can take a look mutate.Rebase function to learn what's happening under the hood.



# We've specifically built the `distroless` tag of an image with the base image `gcr.io/distroless/static` for this purpose.
$ crane rebase devopps/hello-world-ko:distroless --old_base gcr.io/distroless/static --new_base ghcr.io/distroless/static --tag devopps/hello-world-ko:rebased
2022/06/13 21:56:59 devopps/hello-world-ko:rebased: digest: sha256:ed9ff1e64abf2a6225364fbf720e9bda18b050276e224155c797e981a751c005 size: 939

pack, on the other side, have also rebase sub command allows you to quickly swap out the underlying OS layers (run image) of an app image generated by pack build with a newer version of the run image, without re-building the application. Running the following will update the base of devopps/hello-world-buildpack:buildinfo with the latest version of pack/run:


$ pack rebase devopps/hello-world-buildpack:buildinfo --publish

Conclusion

To summarize, we’ve learned that base images are a crucial part of securing container images because we are building our container images on top of them. Therefore, we should always be careful while choosing them because if we don’t pick them wisely, we can encounter security problems. According to that, we should be determining which base images can be used and which of them cannot before allowing them to run on production systems. This is where Kyverno comes into play. To do so, we should access the base image information of the container images first. This is where the build information concept comes into the picture. Thanks to ko, Buildpacks, and Docker Buildx, we can quickly provide build information while building container images. As you can see, you can enable end-to-end security for your base images easily and quickly with the help of a bunch of open-source projects.

Sambhav Kothari

2022/05/24 18:18:22

e other and bundled together all

This may not necessarily be true for all cases. For eg. buildpacks build on a "build" image and then switch the base image to a "runtime" image. We might also confuse people with the term "layer" - typical base images may have multiple layers. I think the more appropriate definition of base image we may want to include is the base operating system image used during runtime and give a few examples - such as ubuntu:focal, alpine etc. (Edited)

2022/05/24 18:23:16

ng sections. We'll use Kyverno for policy management on top of Kubernetes clusters and various container image builders that can provide base image information in different ways

I think another important think we might want to tackle here is the solution to vulnerable base images. Blocking is one thing, but the final is something like a rebase - https://buildpacks.io/docs/concepts/operations/rebase/ (Edited)

Batuhan Apaydın

2022/05/24 18:31:15

Yeah maybe but the main goal of this article is that using kyverno to block containers that are using vulnerable base images, or not providing any build information, so, What about adding the information you are talking about as a separate note in article? (Edited)

Chip Zoller

2022/06/08 15:07:46

Of course not, security is not a static thing, security vulnerabilities pop up every day, and the image with no known vulnerabilities today suddenly becomes a vulnerable image tomorrow, you can't assume that your base images are secure forever.

Run-on sentences here. (Edited)

2022/06/08 15:08:21

scan our base images to identify vulnerabilities and try to make them less vulnerable

Scanning a base image does not itself result in making them less vulnerable. Clarify. (Edited)

2022/06/08 15:08:49

Run-on sentences. (Edited)

2022/06/08 15:09:25

This sentence is confusing. Suggest rewording. (Edited)

2022/06/08 15:11:25

Unfortunately, for any client that pulls your image, there is no way of knowing which base image was used during the build process, which means that once your image is built, information about the base image is completely lost.

You're implicitly referring to things like a Dockerfile's FROM directive, however there IS a way of knowing which base image was used, but it requires explicit authorship to include this as metadata. It's probably important to call that out somewhere so your readers don't think the only way to get this is change their build tooling. (Edited)

2022/06/08 15:12:09

We'll discuss all of them and show how they can provide this information.

"We'll discuss all of them and show how they can provide this information." (Edited)

2022/06/09 07:19:56

nice, thank you.

2022/06/08 15:13:31

and finally, OCI approved his RFC

Probably can remove. It's a non sequitur. (Edited)

2022/06/09 07:25:37

I added a sentence at the end of it, now, it looks better, wdyt?

2022/06/08 15:14:02

et's see it in action and start with cloning the simple project and installing ko in our environment. To install ko, please refer to the [installation](https://github.com/google/ko/#install) page

2022/06/08 15:14:23

This is a straightforward Go application, there is nothing special in it, but the only thing we should mention is that you might notice that there is a **.ko.yaml** file, which is a configuration file for ko.

2022/06/08 15:14:51

The default base image config is necessary for this example because there's an issue with annotations on Docker-typed images (Docker V2 Manifest Scheme V2), Docker Manifests don't support annotations, and most base images are Docker-typed and not OCI.

2022/06/08 15:31:05

"Quick reminder here. You can change the container registry below to one of your favorites. Also, please don't forget to replace your repository name." (Edited)

2022/06/09 07:27:02

thanks a lot :pray:

2022/06/08 15:31:32

nce the build is finished you can take a look at the manifest to see the base image annotations of an image with a utility called crane which is a tool for interacting with remote images and registries. To install crane, please refer to the [installation](https://github.com/google/go-containerregistry/tree/main/cmd/crane#installation) page.

Multiple run-on sentences. (Edited)

2022/06/09 07:27:44

tried to fix, wdyt?

2022/06/08 15:34:01

As we said,

Need to be consistent with your voicing here. You say a combination of "I" and "we" in this article. Should be one or the other. (Edited)

2022/06/09 07:44:28

done, thank you

2022/06/08 15:34:37

store this inf

Your two dashes were converted to an em dash here. Watch for things like this, because it creates failures for users who copy-and-paste these commands to their own terminals. (Edited)

2022/06/08 15:34:51

2022/06/08 15:36:04

More run-on sentences. "Once the builder is ready, the next step is to build the project. To do so, we should clone the simple project first." (Edited)

2022/06/09 07:38:11

ah nice example, thank you.

2022/06/08 15:37:07

to explain ev

Really not necessary because you're not "selling" anything. Perfectly respectable to link to your other writings as it's quite helpful. (Edited)

2022/06/09 07:38:44

it makes a lot of sense, thank you.

2022/06/08 15:37:21

RUN-ON SENTENCES!! (Edited)

2022/06/09 07:40:07

://

2022/06/09 11:25:30

Good

2022/06/08 15:37:51

we said, Buildx can keep this information within the image config instead of a file, and this information is stored within a new field called “moby.buildkit.buildinfo.v0” to embed build dependencies.

RUN-ON SENTENCES (Edited)

2022/06/08 15:39:09

Build image:** A base image used to construct the build environment in which the buildpacks will run. * **Run image:** A minimal base image used for the final application image.

Too many spaces between bulleted items. Looks odd. (Edited)

2022/06/08 15:43:12

runImage.reference

It's really best to use mono-spaced fonts for code formatting such as this and `io.buildpacks.lifecycle.metadata` labels. This visually distinguishes between canonical code and prose. (Edited)

2022/06/09 08:21:21

totally agree, thanks for the suggestion

2022/06/09 11:27:17

Must be consistent in writing. Now you've established this precedent, you must use it elsewhere in the document.

2022/06/08 15:47:35

fore deeping too much dive, let's look at building a container image with the pack, which is a CLI for building apps using Cloud Native Buildpacks. To install pack, please refer to the [installation](https://buildpacks.io/docs/tools/pack/#install) page.

2022/06/08 15:50:17

build it with a pack, the only thing we need to do is use a builder that supports Go applications, and we are going to use "[Paketo Tiny Builder](https://github.com/paketo-buildpacks/tiny-builder)" for this purpose.

Run-on (Edited)

2022/06/08 15:53:57

run-on (Edited)

2022/06/09 08:32:35

fixed.

2022/06/09 11:30:20

Not fixed

2022/06/08 15:54:59

This ending seems really abrupt. You should have a closing or conclusion section that recaps what you discussed and how it is designed to help users. Some closing greeting is also in order. (Edited)

2022/06/09 07:16:01

any suggestion would be great here (Edited)

2022/06/09 07:19:01

I've added a sentence to the beginning "for any client that pulls your image", does it make sense? (Edited)

Dentrax

2022/06/09 08:12:54

```shell= $ helm install \ --namespace kyverno \ --create-namespace \ --repo https://kyverno.github.io/kyverno kyverno kyverno ```

shouldn't atomic may breaks something? in the last poc we tried, pods had been crashed (Edited)

2022/06/09 11:29:41

--wait, --timeout, and --atomic really aren't necessary

2022/06/09 13:13:35

removed, thanks folks.

2022/06/09 08:17:46

age Supply Chain Sec

Supply Chain Security (Edited)

2022/06/09 11:29:01

"supply chain security" is not a proper noun or phrase in English. It should not be initial caps.

2022/06/09 11:22:31

"We'll use Kyverno to provide policy for these inside of a Kubernetes cluster. We'll also illustrate how different container image builders can provide base image information to be used in policy." (Edited)

2022/06/09 11:23:29

Still isn't clear. If I pull your image in which you built in the necessary metadata which names your base, I can know what base image you used. (Edited)

2022/06/09 13:11:31

I'm not sure because I don't understand the relation between the two, would you mind giving a little bit more detail? Dockerfile.fin AFAIK will be used for pinning the digests while building the image itself with buildx (Edited)

2022/06/13 09:35:00

At the beginning of the sentence, should we explain why we can update the base image? I think we should talk about vulnerabilities with a few words first. (Edited)

2022/06/13 18:13:20

I don't think that these two concepts are the same. AFAIK, the concept of the reproducible build is more related to binaries but our topic is related to image builds. WDYT? (Edited)

Jason Hall

2022/06/14 13:37:32

company called [Chainguard](https://chainguard.dev/) the zero-trust company, r

This might read better as just "Recently, Chainguard researched" with a link to the blog post, or just to chainguard.dev (Edited)

2022/06/14 13:40:21

The first layer, known as the base, is the layer on which all different layers are built and provides the basic building blocks for your container environments.

How about "The lowest layers" -- since there can be multiple layers in a base image, and "first" can be tricky since it depends from which direction you're counting. (Edited)

2022/06/14 13:40:33

An illustration might help here too. (Edited)

2022/06/14 13:51:01

Luckily, Jason Hall (@imjasonh), one of the core maintainers of the ko project, worked on an RFC for contributing to Open Containers Initiative (OCI) image-spec about adding the "Base Image" annotations concept into it. You can access the details of his work from [here](https://github.com/imjasonh/ImJasonH/tree/main/articles/oci-base-image-annotations), and finally, OCI approved his RFC, and now, we can add these annotations above to the image-spec manifest to identify which base images were used during the build, which is precisely what ko does for us for free.

This feels out of place this early in the doc. Are we talking about base images, or ko? How about: "The Open Containers Initiative (OCI) specifies standard annotations that can be set to describe base images: - org.opencontainers.image.base.name: ... - org.opencontainers.image.base.digest: ... You can learn more about these [here](...) <- link to my article about it" Then in a new paragraph, talk about ko and how ko sets these for you automatically if it can. (Edited)

2022/06/14 13:52:23

```shell= $ KO_DOCKER_REPO=docker.io/devopps ko build -B --push --tags buildinfo . ```

You don't need `--push` here, it pushes by default. Why `-tags buildinfo`? (Edited)

2022/06/14 13:54:09

et's

It might be helpful to break this up with section headers, so folks can scan quickly to see the outline of the post. It looks like there's an Introduction section, a ko section, buildx, and buildpacks, and a section about enforcing policies using Kyverno. (Edited)

2022/06/14 13:56:36

ild Reproducibility

This section feels out of place in a post about base images and policy enforcement. It doesn't really matter if the build is reproducible, you'll be using the same base image anyway. Pinning is great, but the Kyverno policy you describe doesn't care if it's pinned. This might be a good topic for a blog post of its own. (Edited)

Guest Zimmerman2022/06/16 11:19:39

the image is considered a base image

I think a base image is one that you're expected to build on top of, regardless of how many layers it has. (Edited)

Adrian Mouat

2022/06/16 11:21:06

Hmm, don't think I can delete this comment, but for the purposes of this blog it may make sense to define base images more narrowly

2022/06/16 11:26:06

fully installed operating system distribution

Perhaps "full linux distribution". You could also call out "package managers" and "shells", which are two of the biggest items that distroless removes. (Edited)

Jim Bugwadia

2022/06/23 13:48:00

efore jumping into the details,

Would be good to summarize upfront what the reader will gain from this blog, before the explanation on base images. For example, "Base images are essential to understand and secure. In this post, we will ...." (Edited)

2022/05/24 18:32:00

Maybe we should change the word “first” with “top”, makes sense? (Edited)

2022/06/08 15:05:16

right

Question mark (?) rather than exclamation (!). (Edited)

2022/06/08 15:05:34

hainguard

Doesn't need quotes for proper nouns. Provide link to Chainguard site. (Edited)

2022/06/08 15:07:10

on the other hand, and it

"and" (Edited)

2022/06/08 15:09:48

But, wait a minute

"Wait a minute" in English is a command, not a question. (Edited)

2022/06/08 15:11:41

BuildKit

Docker BuildKit (Edited)

2022/06/09 07:19:32

done

2022/06/08 15:12:23

Link (Edited)

2022/06/09 07:20:22

opps

2022/06/08 15:30:29

"run" (Edited)

2022/06/08 15:32:24

[installation](https://github.com/docker/buildx/#installing)

Missing open bracket. (Edited)

2022/06/09 07:28:06

thanks for your eagle eyes

2022/06/08 15:32:48

is new build information-structure generation from build metad

Got a link? (Edited)

2022/06/09 07:31:17

done.

2022/06/08 15:35:12

docker-container builder

"docker-container builder"? (Edited)

2022/06/09 07:36:51

link added, thank you

2022/06/08 15:35:21

BuildKit.

Run-on sentence. (Edited)

2022/06/08 15:36:41

Eliminate (Edited)

2022/06/08 15:37:33

ane ag

Eliminate "the" (Edited)

2022/06/08 15:38:31

uildpacks for short.

"...or Buildpacks for short." (Edited)

2022/06/09 07:46:06

fixed, thank you.

2022/06/09 11:26:06

Not fixed.

2022/06/08 15:50:06

a simple Go application, and there is nothing special in it. Therefore,

2022/06/08 15:50:34

Remove (Edited)

2022/06/08 15:51:17

2022/06/08 15:51:23

used. Th

No dash. (Edited)

2022/06/09 07:02:15

Thank you Chip (Edited)

2022/06/09 07:03:04

Thank you Chip, gotcha. (Edited)

2022/06/09 07:04:04

Thank you Chip. (Edited)

2022/06/09 07:16:30

Okay, fixed, thank you for letting me know. (Edited)

2022/06/09 08:09:25

should we mention new Dockerfile.pin proposal here too? https://github.com/moby/buildkit/pull/2816 (Edited)

2022/06/09 08:16:51

agree, some closing notes / conclusion would be great to have here as such: what we learned, whats the next steps, or smth like that (Edited)

2022/06/09 11:24:02

Run-on sentences (Edited)

2022/06/09 11:25:56

lod

"Cloud" (Edited)

2022/06/09 11:28:03

The article "a" is not needed. Pack is a computer systems proper noun. (Edited)

2022/06/09 14:03:23

done (Edited)

2022/06/13 09:33:05

it'd better to mention in cases of vulnerability discover in the title of the section. (Edited)

2022/06/13 09:34:15

this may be misinformation in the first place for the reader. had better to get some quotes from https://reproducible-builds.org/ (Edited)

2022/06/13 09:35:59

We can add additional examples from other container image builders like Cloud Native Buildpacks. https://buildpacks.io/docs/concepts/operations/rebase/ (Edited)

2022/06/13 09:40:58

Let's add a couple of examples of how people can use this, wdyt? (Edited)

2022/06/13 19:13:16

yes (Edited)

2022/06/13 19:13:23

done! (Edited)

2022/06/14 13:38:19

SCRATCH

nit: Just "scratch", or maybe `FROM scratch` so it's clearer that's how it's specified in a Dockerfile (Edited)

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`	在筆記中貼入程式碼
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.