Security/Compliance - Validate function base image signatures

Currently, the base images used for creating and deploying functions are not validated for trust-worthiness during the function build process.
However, enterprises are very security and compliance centric and hence must use images signed by well known/ trusted sources as the base image for their functions.
This trust validation mechanism can be invoked during the function build process so that if the images are not trusted then the build fails and would not generate a function image.
This is also an essential compliance requirement for all organizations that deploy code in production environments.

Expected Behaviour

faas-cli build should have a mechanism to validate the trust of base images used for creating functions by validating that the signers of the image are in the list of trusted users for an organization or department.
If the image being used has no trust signatures or if the list of the signers of the image are not in the set of known trusted users; then the build should fail.

Current Behaviour

Currently, there is no trust or signature validation of base images used in functions. Hence, a function can be built using any base image. By implementing the proposed enhancement; the build will fail for un-trusted images or when the signers of the image do not come from a defined whitelist.

Possible Solution

The solution to implement the proposed change is described below:

• The faas-cli build command now includes a new flag notarize which when used during the build process will invoke signature validation of the base image. The flow chart attached below provides a complete description of the algorithm being used to validate function base image signatures.

Context

By providing trust validation when building function images; we go one step forward towards adding the required checks in OpenFaaS to make it enterprise ready. There definitely exist ways to validate trust images offline and then provide these trusted images list to be used by developers. However, it still does not solve the problem of ensuring use of trusted images; since the function developer has to be trusted to use the correct images. By making trust verification a part of the function build process; these checks are enforced.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ): Current/Latest

• Docker version ( Full output from: docker version ):
  Client: Docker Engine - Community
  Version: 18.09.1
  API version: 1.39
  Go version: go1.10.6
  Git commit: 4c52b90
  Built: Wed Jan 9 19:33:12 2019
  OS/Arch: darwin/amd64
  Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.1
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 4c52b90
Built: Wed Jan 9 19:41:49 2019
OS/Arch: linux/amd64
Experimental: true

• Are you using Docker Swarm (FaaS-swarm ) or Kubernetes (FaaS-netes)?
  FaaS-netes

• Operating System and version (e.g. Linux, Windows, MacOS):
  N/A. General enhancement

• Link to your project or a code example to reproduce issue:
  N/A. Proposed enhancements

Start at the faas-cli build entry point and review how base images are selected and passed into the build process. Use the proposed notarize flag and attached trust-verification algorithm as requirements, then identify the project’s existing image and build tests. Done means untrusted or unsigned base images prevent a function image from being generated while trusted signers are accepted.