v0.6.0

csi-driver-spiffe is a clean and simple way to get SPIFFE IDs for your Kubernetes pods with minimal dependencies and minimal fuss.

v0.6.0 includes a variety of new features which make csi-driver-spiffe easier to work with and easier to set up, as well as the usual dependency bumps and tool upgardes.

Possibly Breaking Changes: Read Before Upgrading!

• The default for the app.approver.signerName Helm value changed to allow approval for all signers by default. Previously, any built-in cert-manager ClusterIssuer was allowed. This change makes it simpler to use other types of issuer with csi-driver-spiffe.

  The impact of this change should be nonexistant for the vast majority of csi-driver-spiffe use cases but there are some very specific scenarios in which this change could have a security impact. For more information, see the relevant feature overview below.

• The name of the DaemonSet installed by the Helm chart changed from a default of "cert-manager-csi-driver-spiffe" to "cert-manager-csi-driver-spiffe-driver". We don't anticipate this should be a huge change for anyone, but it's worth noting that upgrading will change the name. This change helps with tab completion when debugging csi-driver-spiffe.

Feature Overview

Runtime Issuer Configuration

The headline feature of this release is the ability to configure which issuer to use at runtime, rather than only being able to configure at install time.

Previously, changing the issuer configuration for csi-driver-spiffe required that it be restarted, which could lead to downtime and could block pods from getting the identities they need. It also meant there was a need to install csi-driver-spiffe after cert-manager was already installed and an issuer was configured, which complicated the installation process for users who wanted to simply install a series of Helm charts and configure them afterwards.

It's now possible to configure a ConfigMap in the installation namespace of csi-driver-spiffe which specifies which issuer to use. csi-driver-spiffe will watch that ConfigMap and adapt quickly to any changes in issuer, allowing issuer updates with zero downtime.

To use the feature, set the app.runtimeIssuanceConfigMap Helm value to the name of the ConfigMap you'll use to configure issuer details.

A default issuer can still be specified using the app.issuer.* Helm values, and this default issuer be used if the ConfigMap is invalid, missing or deleted. Alternatively, to require runtime configuration these values can be manually set to be blank as in the example below. [1]

If no issuer is configured, pods mounting csi-driver-spiffe volumes will fail to start as csi-driver-spiffe won't be able to create CertificateRequests for them.

Below is an example of installing csi-driver-spiffe with runtime configuration:

kubectl create configmap spiffe-issuer -n cert-manager \
  --from-literal=issuer-name=my-issuer-name \
  --from-literal=issuer-kind=ClusterIssuer \
  --from-literal=issuer-group=cert-manager.io

helm upgrade -i -n cert-manager cert-manager-csi-driver-spiffe jetstack/cert-manager-csi-driver-spiffe --wait \
 --set "app.logLevel=1" \
 --set "app.trustDomain=my.trust.domain" \
 --set "app.issuer.name=" \
 --set "app.issuer.kind=" \
 --set "app.issuer.group=" \
 --set "app.runtimeIssuanceConfigMap=spiffe-issuer"

The logs for the csi-driver-spiffe DaemonSet pods should produce output like the following to show that the ConfigMap was picked up:

I0516 11:57:44.655854       1 driver.go:410] "Changed active issuerRef in response to runtime configuration ConfigMap" logger="csi.runtime-config-watcher" config-map-name="spiffe-issuer" config-map-namespace="cert-manager" issuer-name="my-issuer-name" issuer-kind="ClusterIssuer" issuer-group="cert-manager.io"

Simpler Install with no signerName

Previously, to use any kind of issuer that wasn't a cert-manager ClusterIssuer would require configuring not just issuer settings but also allowlisting the use of that issuer through the app.approver.signerName Helm value.

The impact of this change should be nonexistant for the vast majority of csi-driver-spiffe use cases (beyond making it easier to configure) - but there are some extremely specific scenarios in which this change could have a security impact. Specifically, if you run another approver (such as approver-policy) in the cluster and you require that the csi-driver-spiffe-approver and the other approver are allowed to approve for distinct types of issuer. In practice, most clusters won't have this requirement even if they run multiple approvers - it's easier to restrict the approvers via their own configuration rather than using RBAC.

For more information, read the rationale about why this was changed in approver-policy. If you're concerned, see also the relevant approver-policy release notes which explain what actions you might want to take. Most users should need to take no action.

Approver Simplification

In earlier csi-driver-spiffe versions, the csi-driver-spiffe-approver component would check that the issuer configured for created CertificateRequests matched the one configured for the csi-driver-spiffe DaemonSet at install time. This introduces a race condition whenever that issuer needs to be updated (such as rotation), since it wasn't possible to specify multiple issuers and it wasn't easy to ensure that both the DaemonSet and the approver could be restarted at the same time to ensure they both picked up the change.

This check didn't provide much value, and would have made runtime configuration of issuers incredibly difficult, and so it was removed in csi-driver-spiffe v0.6.0. Now, the approver doesn't look at the issuerRef field of CertificateRequest resources and instead checks for the spiffe.csi.cert-manager.io/identity annotation which the driver sets on all CertificateRequests it creates.

Together with runtime issuer configuration, this makes issuer rotation simpler, safer and less error prone.

What's Changed

New Features

• Allow runtime configuration of issuers by @SgtCoDFish in #141

Helm Chart

• ⚠️ Allow use of all signers by default by @SgtCoDFish in #131
• Add 'crds.enabled' and 'crds.keep' options to generated CRDs by @inteon in #91
• Enable helm-tool linter and schema generator by @inteon in #80
• Use same include statement for labels everywhere & add labels to pod templates by @inteon in #97
• Helm Add commonLabels option by @inteon in #98
• Added tolerations, nodeSelector, affinity, topologySpreadConstraints by @saydulaev and @maelvls in #50

Tests / CI

• Update digests of upstream busybox docker image by @inteon in #103
• Add go module and replace oci-image with oci-build and oci-publish by @inteon in #110
• Fix linters by @inteon in #111
• Fix gosec issues and enable gosec linter by @inteon in #122
• Increase timeouts for camanager test by @SgtCoDFish in #126
• Move parsing of custom annotations to testable function by @SgtCoDFish in #130
• Add env var for focusing on individual e2e tests by @SgtCoDFish in #135
• Add e2e util package to abstract common e2e tasks by @SgtCoDFish in #136
• Change approval of e2e issuer to use cmctl by @SgtCoDFish in #144
• Tweak camanager testing by @SgtCoDFish in #143

Other

• ⚠️ Rename DaemonSet for easier tab completion by @SgtCoDFish in #124
• Use exit code from recommended range by @SgtCoDFish in #95
• Add design for runtime configuration of issuers by @SgtCoDFish in #94
• Remove issuerRef from approver by @SgtCoDFish in #125
• Two minor tweaks (default container annotation!) by @SgtCoDFish in #123
• docs: add RELEASE.md documenting the release process by @ThatsMrTalbot in #146

New Contributors

• @saydulaev made their first contribution in #50
• @maelvls made their first contribution in #50

Full Changelog: v0.5.0...v0.6.0

Other Notes

[1]: A future change may set the default issuer to be blank in all cases. Today, the default is to look for a ClusterIssuer for spiffe-ca which might not be applicable as a default for many users.