Add support for Vault UpstreamAuthority plugin - K8s Auth

[LaithLite]

This PR enables the usage of Vault as an upstream authority with the usage of Kubernetes Authentication.

This relates to #413

[faisal-memon]

@LaithLite Thanks for submitting, this will be a useful feature for a lot of people

[LaithLite]

With regards to ca_cert_path should the helm chart user:

• specify their own certificates, volume (via spire-server.extraVolumes and volume mount via spire-server.extraVolumeMounts to make this option work

OR

• Make assumptions and generate templating that creates the volume & volumeMount (which mounts a k8s secret/certificate resource) that then refers to a pre-made secret/cert resource by the helm chart user?

[faisal-memon]

With regards to ca_cert_path should the helm chart user:

• specify their own certificates, volume (via spire-server.extraVolumes and volume mount via spire-server.extraVolumeMounts to make this option work

OR

• Make assumptions and generate templating that creates the volume & volumeMount (which mounts a k8s secret/certificate resource) that then refers to a pre-made secret/cert resource by the helm chart user?

I like the 2nd option of those 2. Can also go a step further and pass in the ca cert by a variable and create the secret. We do this with external database password. The first option seems like less work so if you prefer to do that, i think thats fine too.

[kfox1111]

With regards to ca_cert_path should the helm chart user:

• specify their own certificates, volume (via spire-server.extraVolumes and volume mount via spire-server.extraVolumeMounts to make this option work

OR

• Make assumptions and generate templating that creates the volume & volumeMount (which mounts a k8s secret/certificate resource) that then refers to a pre-made secret/cert resource by the helm chart user?

I like the 2nd option of those 2. Can also go a step further and pass in the ca cert by a variable and create the secret. We do this with external database password. The first option seems like less work so if you prefer do that, i think thats fine too.

That's messy I think. How do we support the case where the user already has loaded in the cert/secret by some means? (For example: https://external-secrets.io/latest/). We could support both specifying them in values and an external reference I suppose.

[faisal-memon]

That's messy I think. How do we support the case where the user already has loaded in the cert/secret by some means? (For example: https://external-secrets.io/latest/). We could support both specifying them in values and an external reference I suppose.

Valid point @kfox1111.

[faisal-memon]

@LaithLite we discussed on the sync meeting today and agreed on option 2 as the better option. Did you need any further guidance on this?

[marcofranssen]

As an example of implementing this you might follow the same pattern as service accounts do to have a similar API for the end users of the chart.

https://github.com/spiffe/helm-charts/blob/main/charts/spire/charts/spire-server/templates/serviceaccount.yaml

[LaithLite]

@LaithLite we discussed on the sync meeting today and agreed on option 2 as the better option. Did you need any further guidance on this?

Hi, thanks for the feedback, I think I still need a bit more clarity as I am unsure of the suggested implementation.

With regards to caCertPath, would the underlying volume associated with it be similar to the service account's setup as follows:

volumes:
{{- with .Values.upstreamAuthority.vault.caCertVolume -}}
  - name: upstream-vault-ca
    {{ toYaml  . | nindent 4}}
{{- end }}

So it allows the use of externalSecrets or any other k8s volume resource, although now we provide another helm configuration here.

The alternative could be making it similar to the upstreamAuthority.disk.secret implementation, where you have defaults that mount a secret volume with a default name, otherwise the user can override and generate their own yaml/config similar to the yaml I have defined above.

helm-charts/charts/spire/charts/spire-server/templates/statefulset.yaml

Lines 270 to 274 in a167ce6

	{{- if eq (.Values.upstreamAuthority.disk.enabled | toString) "true" }}
	- name: upstream-ca
	secret:
	secretName: {{ include "spire-server.upstream-ca-secret" . }}
	{{- end }}

helm-charts/charts/spire/charts/spire-server/templates/upstream-ca-secret.yaml

Lines 2 to 16 in a167ce6

	{{- with .Values.upstreamAuthority.disk }}
	{{- if and (eq (.enabled | toString) "true") (eq (.secret.create | toString) "true") }}
	apiVersion: v1
	kind: Secret
	metadata:
	name: {{ include "spire-server.upstream-ca-secret" $root }}
	namespace: {{ include "spire-server.namespace" $root }}
	labels:
	{{- include "spire-server.labels" $root | nindent 4 }}
	data:
	{{- with .secret.data }}
	tls.crt: {{ .certificate | b64enc }}
	tls.key: {{ .key | b64enc }}
	{{- if ne .bundle ""}}
	bundle.crt: {{ .bundle | b64enc }}

[faisal-memon]

Hi @LaithLite The secret option seems a little cleaner to me than exposing a volume. @kfox1111 @marcofranssen Any thoughts on this one?

[kfox1111]

Was looking for a precedent here... We have https://github.com/spiffe/helm-charts/blob/main/charts/spire/charts/spire-server/values.yaml#L425-L430 already in tree.

That supports both secret and configmap, since some engines may put the ca pem in a configmap (safe as they are public keys only)

[marcofranssen]

@LaithLite are you planning on moving this forward? Should one of our team pull it forward? Please let us know.

[LaithLite]

@LaithLite are you planning on moving this forward? Should one of our team pull it forward? Please let us know.

Apologies I have been busy, I am intending to make this PR more active and will move this forward!

[kfox1111]

Apologies I have been busy, I am intending to make this PR more active and will move this forward!

No worries. We just wanted to make sure you weren't stuck.

[kfox1111]

Updated example link: https://github.com/spiffe/helm-charts/blob/main/charts/spire/charts/spire-server/values.yaml#L452-L457

[marcofranssen]

Thanks for the progress on this one. I have a few inline questions and suggestions. Let me know your thoughts on those.

[kfox1111]

Other then the docs needing to get fixed, it looks good to me. Thanks!

[kfox1111]

LGTM

[faisal-memon]

Thanks @LaithLite for this contribution.

[marcofranssen]

LGTM 🚀