2. April 2024

[kailun-qin]

Agenda

(please write your proposed agenda items in comments under this discussion)

• Mikko @mythi: present and discuss Gramine integration with CoCo
• Dmitrii: Tracking [common/protected_files] Add support for arbitrary truncation #1785 for inclusion in v1.7?
• Dmitrii: Plan to sign tarballs, see [Request] Signed binary tarball as part of new releases #235?
  • Dmitrii recalls that Woju only wanted to have the signature of the Debian/Ubuntu repo, but packages are not signed.
  • Dmitrii not sure if tarballs (on GitHub) are a legit target for signing.
  • This is all in the context of OpenSSF Best Practices silver badge.

Mikko: present and discuss Gramine integration with CoCo

[ Mikko presents his work ]

• Goal of work: run unmodified containers in K8s using Gramine, build on secure software supply chains; also demonstrate how CC could benefit from SBOMs (Software Bill of Materials).

• GSC creates a NEW container image which must be pushed to the container registry.

  • Challenges: (1) image size increases, (2) extra provider that publishes the Graminized image. For the former, GSC installs some tools (which we try to rm later, but still leftovers are there); so Mikko's approach is to do the tooling separately and add only Gramine binaries + .manifest.sgx + .sig files in the complete final image.

• Idea 1: Add Gramine LibOS as runtime overlay (during container runtime). E.g. Gramine is pre-installed on each K8s node, and Gramine files are bind-mounted into the container.

• Idea 2: Rely on pre-existing container image SBOM (in-image binaries) + Gramine runtime SBOM (Gramine binaries).

  • Syft tool: with ad-hoc templating, can output sgx.trusted_files entries from an arbitrary container image.
  • This Syft tool collects all files from the container image. Similar to GSC's finalize_manifest.py code.

• Part of the SPDX specification includes the requirements for per-file integrity information in the SBOM.

• Snapshotter for containerd runtime: an overlay mount at runtime. But an easier way is to just use spec::volumeMounts::<Gramine files> of Kubernetes config file.

• Woju: we could add the SHA256 hashes of PAL + LibOS + RA-TLS (+ ?) as part of the package build process. And publish on GitHub or on some other public web site.

  • Need reproducible builds though first. Woju will look into this after April.

• Mona: what's next, what's the plan for this work?

  • Mikko: no specific plan yet. Looking for customers/interested parties.

• Woju: Scaffolding project's way of building the manifest + sig:

  1. Create the container image, then apply gramine-manifest inside of this container image to render the manifest template.
  2. Copy the manifest and all files out, use gramine-sgx-sign --chroot /path/to/extracted/files on the host, copy the final .sgx and .sig files back into container image.

• Mikko does a similar thing.

Dmitrii: Tracking #1785 for inclusion in v1.7

• Michal: it's almost done, and Michal wants to finish the reviews today/tomorrow.

Dmitrii: Plan to sign tarballs, see [Request] Signed binary tarball as part of new releases #235

• Dmitrii recalls that Woju only wanted to have the signature of the Debian/Ubuntu repo, but packages are not signed.

• Dmitrii not sure if tarballs (on GitHub) are a legit target for signing.

• This is all in the context of OpenSSF Best Practices silver badge.

• Woju: this is a long discussion. First we should agree what "release artifacts" are. Maybe "release artifacts" are not meant to be the GitHub tarballs.

  • Current state: tag the commit on GitHub, now it is signed (by Woju's personal key). GitHub's assets are NOT signed. Then Woju builds packages -- binary and source ones, both are signed (in sense that the repo itself is signed).

• Looking at "Secure release" requirement at https://www.bestpractices.dev/en/criteria (for silver badge), we are already complying. Just need to document this. Woju is/will be working on documenting.