Skip to content

Latest commit

 

History

History
126 lines (105 loc) · 5.68 KB

hip-0015.md

File metadata and controls

126 lines (105 loc) · 5.68 KB
Raw
hip title authors created type status
0015
Annotation for Images used by Helm Charts
Tom Runyon <tom@defenseunicorns.com>
Scott Rigby <scott@weave.works>
Andrew Block <ablock@redhat.com>
2021-10-07
feature
draft

Abstract

The images used by a Helm chart is not easily discoverable in the chart definition. When deploying Operators and CRDs, the images needed to instantate all the pods for a Helm release may not be present by templating the default values for a Helm chart, whic provides blockers when automatically discovering dependencies for Bill of Materials.

Motivation

Without a standard methodology for defining the images used by a chart, third party applications that require metadata for Helm Charts are using custom keys unique to their application, e.g. Artifact Hub or Openshift. By Standardizing metadata, charts can be built to be consumable by a varity of tools for metadata, bill of materials, airgap deployments, etc. Current solutions of dynamically discovering the images needed by templating the chart do not account for all possible templating paths for the chart, nor capture images that are deployed as part of an Operator paradigm and not defined explicitly as pods in the helm chart.

Rationale

The helm.sh prefix identifies the standard belonging to the Helm community, and the /images path clearly identifies the type of objects being identified. The annotation will define a string that can be parsed into a list that the chart maintainer will manage as they knowingly adjust the images needed for the chart's deployment. Each element of this image list will contain at least a name for the image as well as a location for the image in the image field. and an optional dependency field described in the specification. The elements may have additional properties to meet additional use cases, such as the whitelisted field used by ArtifactHub, or providing a public key for signed images. The additional fields are not part of this standard, but how they get attached to each image is.

Specification

A helm chart would be define the images in the annotations field:

apiVersion: v1
version: 6.0.0
appVersion: 6.0.0
name: podinfo
engine: gotpl
description: Podinfo Helm chart for Kubernetes
home: https://github.com/stefanprodan/podinfo
maintainers:
  - email: stefanprodan@users.noreply.github.com
    name: stefanprodan
sources:
  - https://github.com/stefanprodan/podinfo
kubeVersion: ">=1.19.0-0"
annotations:
  helm.sh/images: |
    - name: podinfo
      image: ghcr.io/stefanprodan/podinfo:6.0.0
    - name: redis
      image: dockerhub.io/_/redis:6.0.8
      whitelisted: true

When a chart contains a dependency or subchart, the expection is that the metadata of the dependency/sub chart will contain the helm.sh/images annotation to identify the images required by the dependency chart. If that isn't true, the top level chart can provide the images entry for that chart and use the optional dependency field to identify the sub chart that the image is used in. For example, the Bitnami Kafka chart would identify the images used in common and zookeeper as part of the kafka chart metadat:

annotations:
  category: Infrastructure
  images: |
    - name: kafka
      image: docker.io/bitnami/kafka:2.8.1-debian-10-r0
    - name: kubectl
      image: docker.io/bitnami/kubectl:1.19.5-debian-10-r3
    - name: shell
      image: docker.io/bitnami/bitnami-shell:10-debian-10-r199
    - name: kafka-exporter
      image: docker.io/bitnami/kafka-exporter:1.4.2-debian-10-r5
    - name: jmx-exporter
      image: docker.io/bitnami/bitnami/jmx-exporter:0.16.1-debian-10-r66
    - name: zookeeper
      image: docker.io/bitnami/zookeeper:3.7.0-debian-10-r157
      dependency: zookeeper
    - name: shell
      image: docker.io/bitnami/bitnami-shell:10-debian-10-r202
      dependency: zookeeper
apiVersion: v2
appVersion: 2.8.1
dependencies:
  - name: common
    repository: https://charts.bitnami.com/bitnami
    tags:
      - bitnami-common
    version: 1.x.x
  - condition: zookeeper.enabled
    name: zookeeper
    repository: https://charts.bitnami.com/bitnami
    version: 7.x.x
description: Apache Kafka is a distributed streaming platform.
engine: gotpl
home: https://github.com/bitnami/charts/tree/master/bitnami/kafka
icon: https://bitnami.com/assets/stacks/kafka/img/kafka-stack-220x234.png
keywords:
  - kafka
  - zookeeper
  - streaming
  - producer
  - consumer
maintainers:
  - email: containers@bitnami.com
    name: Bitnami
name: kafka
sources:
  - https://github.com/bitnami/bitnami-docker-kafka
  - https://kafka.apache.org/
version: 14.2.1

It's worth noting that the bitnami-shell image is used in both zookeeper and kafka, but with different tags.

Backwards compatibility

Since there is no existing specification, the annotation will be optional to support backwards compatibility.

Security implications

Have to think about it, but don't see any.

How to teach this

The specification can be added to documentation around building helm charts, and exmaples of tools using this feature (e.g. ArtifactHub) would facilitate adoption/clarity on how its used.

Rejected Ideas

Helm Templating Discovery

The methodology of dynamically discovering images used by a chart can work in certain situations but also has limitations with images that are only used for certain use cases, as well as operator charts that don't expose the images needed as part of the rendered manifests.