BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Managing the Software Supply Chain with the "Grafeas" Metadata API and "Kritis" Deploy Authorization

Managing the Software Supply Chain with the "Grafeas" Metadata API and "Kritis" Deploy Authorization

This item in japanese

Bookmarks

In a recent Google Cloud Platform (GCP) blog series exploring container security the GCP team has presented further details of an existing and proposed open source software supply chain project. First, Grafeas is a common API and language to store, query and retrieve metadata about software components such as build details, test status, and known security issues. Second, Kritis is a proposed software supply chain management framework that enables the use of metadata stored in Grafeas to build and enforce real-time deployment policies with Kubernetes, which can prevent the release of container images with known issues.

The GCP blog post states that container technology has made it easy to rapidly create, modify and share applications packaged within a container image artifact. However, with this potential increase in deployment velocity comes a potential trade-off against safety, such as the need to verify whether the containerised application has passed quality assurance, and whether the application and image contain any known security vulnerabilities. One way to answer these questions is to track metadata about the container, for example, who worked on it, the results of functional and nonfunctional test runs, and whether it has any known vulnerabilities.

Last October, Google and several partners announced Grafeas, an open-source project that provides a structured metadata API for container images. Grafeas simplifies the handling of metadata, including security concerns like package vulnerability scan results, and keeps track of this information:

  • "Build" metadata can be used to certify that a container image was built according to build policies using a trusted builder with checked-in source code.
  • "Package Vulnerability" metadata contains information from a vulnerability scanning service and lets an organisation create policies on deploying vulnerable containers.
  • "Image Basis" metadata contains information about the base image from which a container was derived as well as additional layers used in building the container image.
  • "Package Manager" metadata indicates which packages were installed in the container image.
  • "Deployment History" metadata allows the tracking of which resources were deployed and when.

Grafeas uses two API concepts, a note and an occurrence. The documentation states that this division allows third-party metadata providers to create and manage metadata on behalf of many customers.

  • A note is an item or condition that can be found via an analysis or something that is used multiple times in a process. For example, a CVE could be the result of a vulnerability analysis of a Linux package. In a build process, information about a builder would be stored within a note.
  • An occurrence can be thought of as an instantiation of a note and describes how the note was found in a specific cloud resource or project (e.g., location, specific remediation steps, etc.), or what the results of a specific note were (e.g., the container images that resulted from a build). For example, an occurrence might report that the heartbleed OpenSSL bug (a possible Note) was found in a specific package of a container image, and include information about how to remedy the heartbleed bug based on the customer's package.

In order to properly aggregate over metadata stored in Grafeas, each kind of information stored has a strict schema. These schemas allow normalization of data from multiple providers, giving users the ability to see meaningful insights in their components over time. The currently supported schema types can be seen in the figure below:

Grafeas metadata kinds

As new metadata types need support, new kinds can be added, each with their own schema.

Tracking Grafeas' metadata allows a team to understand what containers are stored within their environment, and also to enforce restrictions on which containers get deployed. Engineers can review Grafeas metadata for compliance with policies before deploying. An additional type of metadata, an "Attestation", which is a confirmation or authentication of a fact, is used for this purpose (in business an attestation is the process, performed by accountants or auditors, of providing independent opinion on published financial and other business information of a business, public agency, or other organization). If the metadata pulled from Grafeas is consistent with organisational policy, an attestation can be written that certifies that an image complies with deployment requirements. The image below, taken from the GCP introduction to Grafeas, summarises how this tool would fit into a typical continuous delivery pipeline:

Grafeas CI/CD workflow

In a recent whitepaper, the GCP team has proposed "Kritis", a deployment authorization framework for Kubernetes. A core part of the Kritis framework would be a Kubernetes Admission Controller that be used to check for expected attestations, and block deployment when they are not present. The whitepaper states that in addition to basic admission control, Kritis provides additional support for "workflow enforcement, multi-authority signing, breakglass deployment and more". A hosted alpha implementation of Kritis, called Binary Authorization (BinAuthz), is available on Google Container Engine (GKE) and is planned for a further open source release soon.

Key concepts of BinAuthz are the "Attestation Authority" and "Policy", realised as REST resources managed through a REST API. An Attestation Authority is a named entity which has the power to create attestations. As a REST resource, it encapsulates the location of its attestations (where to store and retrieve from), as well as verification criteria (what makes an attestation valid). A Policy then names Attestation Authorities whose attestations are required to deploy an artifact to some target. An Attestation Authority names a Grafeas Note (of Kind "ATTESTATION") which is used as an anchor for this authority's attestations, and optionally specifies public keys if attestations must be signed. Attestations by this authority are then represented as Occurrences attached to the authority's Note.

Spotify has recently discussed how they have used Grafeas and Kritis as the central source of truth for container metadata for over 6,000 container builds per day and 330,000 images in their primary container registry. This has allowed the security team to implement appropriate auditing and lifecycling strategies for the software delivered to users. During continuous integration a number of audits are performed against the containers (including the use of a homegrown tool security audit tool named kubeaudit) and attestations are generated and signed cryptographically using PGP, which ensures the identity of their builder and other attestation authorities. These attestations make up the policies that can be enforced with Kritis on Kubernetes.

Additional information on Grafeas can be found in the project's documentation and GitHub repository. Grafeas can be used to enforce many kinds of security policies, and Kelsey Hightower has provided a tutorial on how to use Grafeas to allow only container images signed by a specific private key.

Rate this Article

Adoption
Style

BT