project-stacker / stacker

Build OCI images natively from a declarative format
https://stackerbuild.io
Apache License 2.0
196 stars 34 forks source link

Bug: do not include stacker_yaml (io.stackeroci.stacker.stacker_yaml) annotation #401

Open smoser opened 1 year ago

smoser commented 1 year ago

stacker version

v1.0.0-rc1-c00511a

Describe the bug

When stacker publishes, it includes the content of the stacker yaml that built the image under the annotation io.stackeroci.stacker.stacker_yaml .

In all of our real-world stacker builds this annotation provides no added value, and could include sensitive information. In finding an example for this report, I actually stumbled upon a (encrypted) root password in an yaml that was published.

Because of this I believe this should be disabled by default.

Here is an example annotation section from a stacker-built oci image from https://github.com/project-machine/bootkit:

    "annotations": {
        "io.stackeroci.stacker.git_version": "0.0.1-dirty",
        "io.stackeroci.stacker.stacker_yaml": "config:\n  prerequisites:\n    - ../kernel/stacker.yaml\n    - ../shim/stacker.yaml\n    - ../uki/stacker.yaml\n    - ../ovmf/stacker.yaml\n\nbootkit-assemble:\n  build_only: true\n  from:\n    type: built\n    tag: build-krd\n  import:\n    - stacker://shim-build/export/shim.tar\n    - stacker://uki-build/export/uki.tar\n    - stacker://ovmf-build/export/ovmf.tar\n    - stacker://kernel-build/export/boot.tar\n    - stacker://kernel-build/export/modules.tar\n  run: |\n    #!/bin/bash -ex\n    d=$(mktemp -d)\n    trap \"rm -Rf $d\" EXIT\n\n    tar -C \"$d\" -xf /stacker/shim.tar\n    tar -C \"$d\" -xf /stacker/uki.tar\n    tar -C \"$d\" -xf /stacker/ovmf.tar\n\n    prepd=\"$d/bootkit\"\n    mkdir \"$prepd\"\n    cp \"$d/shim/shim.efi\" \"$prepd/shim.efi\"\n    cp \"$d/uki/kernel.efi\" \"$prepd/kernel.efi\"\n    cp \"$d/ovmf/ovmf-vars.fd\" \"$prepd/ovmf-vars.fd\"\n    cp \"$d/ovmf/ovmf-code.fd\" \"$prepd/ovmf-code.fd\"\n    cp /stacker/boot.tar /stacker/modules.tar \"$prepd\"\n\n    mkdir /export\n    tar -C \"$d\" -cf /export/bootkit.tar bootkit/\n\nbootkit:\n  from:\n    type: tar\n    url: stacker://bootkit-assemble/export/bootkit.tar\n"
    }

If you take the time to format the blob of text there, you see that the stacker.yaml file included looks like this:

config:
  prerequisites:
    - ../kernel/stacker.yaml
    - ../shim/stacker.yaml
    - ../uki/stacker.yaml
    - ../ovmf/stacker.yaml

bootkit-assemble:
  build_only: true
  from:
    type: built
    tag: build-krd
  import:
    - stacker://shim-build/export/shim.tar
    - stacker://uki-build/export/uki.tar
    - stacker://ovmf-build/export/ovmf.tar
    - stacker://kernel-build/export/boot.tar
    - stacker://kernel-build/export/modules.tar
  run: |
    #!/bin/bash -ex
    d=$(mktemp -d)
    trap "rm -Rf $d" EXIT

    tar -C "$d" -xf /stacker/shim.tar
    tar -C "$d" -xf /stacker/uki.tar
    tar -C "$d" -xf /stacker/ovmf.tar

    prepd="$d/bootkit"
    mkdir "$prepd"
    cp "$d/shim/shim.efi" "$prepd/shim.efi"
    cp "$d/uki/kernel.efi" "$prepd/kernel.efi"
    cp "$d/ovmf/ovmf-vars.fd" "$prepd/ovmf-vars.fd"
    cp "$d/ovmf/ovmf-code.fd" "$prepd/ovmf-code.fd"
    cp /stacker/boot.tar /stacker/modules.tar "$prepd"

    mkdir /export
    tar -C "$d" -cf /export/bootkit.tar bootkit/

bootkit:
  from:
    type: tar
    url: stacker://bootkit-assemble/export/bootkit.tar

There is no useful information to the reader because the actual work is done in the prerequisites. Including this annotation by default amounts to a waste of text in a manifest with the potential of leaking sensitive data.

To reproduce

No response

Expected behavior

No response

Screenshots

No response

Additional context

No response

smoser commented 1 year ago

To make this a larger waste of bytes and screen real estate https://github.com/project-zot/zot/issues/1145 means that I have to include an annotations section in the stacker.yaml for every layer that will be published like the following:

 annotations:
   org.opencontainers.image.url: "https://github.com/project-machine"
   org.opencontainers.image.source: "https://github.com/project-machine"
   org.opencontainers.image.version: "n/a"
   org.opencontainers.image.revision: "n/a"
   org.opencontainers.image.vendor: "project-machine"
   org.opencontainers.image.licenses: "GPLv2 and others"
   org.opencontainers.image.title: "bootkit"
   org.opencontainers.image.description: ""

That section will then be present in the image manifest both as actual annotations and as content in the included stacker.yaml.

mikemccracken commented 1 year ago

FWIW, I have found the stacker_yaml annotation useful as a clue to find out where images were built, when trying to track down images that are included in ND but not rebuilt with ND, and thus got stale and had expired certs, etc.

I agree that leaking info is a potential problem (although passwords in a stackerfile seems bad for other reasons), so I am not sure what the right thing to do here is, just wanted to point out that there is a use case here.