Add release workflow

[chipzoller]

Signed-off-by: Chip Zoller chipzoller@gmail.com

What does this PR change?

• Adds a new release workflow using ko and provides software supply chain security by default.
  • This workflow publishes images to gcr.io/kubecost1 automatically upon new tagged releases.
  • Uploads as release assets the SBOM, vuln scan, image signature, and a version of install.yaml with the digest from the release process.
  • Uses all modern software supply chain security techniques including image signing and attestations of SBOM, vulnerability scan, and SLSA provenance.
  • Uses OIDC and GCP Workload Identity Federation to support keyless access for all operations against GCR.
• Removes the Dockerfile
• Adds a new SECURITY.md describing what security assets are available and how to perform verification.
• Lints/normalizes the install.yaml manifest as well as updates the image string to use the latest tag which will become available after the first and any subsequent release actions.
• Minor typo fix in README
• Comments out main build recipe in Justfile for later refactoring to use ko

Does this PR rely on any other PRs?

No

How does this PR impact users?

CI only but allows users to verify modern software supply chain security for this project.

Links to Issues or tickets this PR addresses or fixes

Closes #7

What risks are associated with merging this PR? What is required to fully test this PR?

The first release build needs to be triggered after this is accepted so the new image and its assets are pushed into the correct repository.

How was this PR tested?

In a separate repo.

[chipzoller]

~Not to self: once merged and the first release cut, need to update manifest to use latest tag. Also, try fail on vuln types if detected.~ I went ahead and update the image in the install.yaml manifest to go ahead and point to the new repo and latest tag. We'll just want to build as soon as this gets merged so the image ref is valid.

[chipzoller]

@avrodrigues5, can we add ldflags s and w to further reduce build size? Just may be impacted if needing to run a debugger. Any concerns there?

Let me know what other questions you have about this releaser workflow. I realize that ko is probably new to you so glad to address any concerns.

[avrodrigues5]

@chipzoller high level this looks good.

Few questions:

1. Where are SBOM, vulnerabiliy scan etc available for each image? I see a note saying also available offline, can i go check it or its during the build process the output get emitted in the build logs?
2. Ko looks good just by reading it . is build size reduction a P0, im not sure what impact -s and -w ldflags would have in future debugging. I recommend holding it off if build size reduction is not a priority at the time wdyt?

[chipzoller]

1. SBOM and vuln scans are attached as attestations to the image in the registry and also available as release assets.

2. Use of those flags drops the size by about 50%, and since we probably don't need a tice debugging at this point my suggestion would be to add them until we see a case where this presents a problem.

[chipzoller]

@avrodrigues5, I added the .ko.yaml with the ldflags set.

[chipzoller]

All green. Release 0.0.18 is live.