search

concourse / concourse-chart

Helm chart to install Concourse
Apache License 2.0
143 stars 176 forks source link

TLS secrets does not follow standard Kubernetes TLS secret format #224

Open daniellavoie opened 3 years ago

daniellavoie commented 3 years ago

Certificate created using cert manager and with kubectl create secret tls will generate a standardized secret like:

data:
  ca.crt: <redacted>
  tls.key: <redacted>
  tls.crt: <redacted>

Because the Conourse Helm Chart does not comply to this standard, it makes it impossible to have certificate provisioners automatically feed secrets to concourse. Certificate data needs to be manually duplicated and is not a safe practice.

An example would be https://github.com/concourse/concourse-chart/blob/94c54aa054fe53c5603114e881c26f38b3598d4a/templates/web-deployment.yaml#L300

- name: CONCOURSE_TLS_CERT
  value: "{{ .Values.web.tlsSecretsPath }}/client.cert"
- name: CONCOURSE_TLS_KEY
  value: "{{ .Values.web.tlsSecretsPath }}/client.key"

Sadly, I don't see an easy fix to this as it would involved refactoring all secret management for the entire helm chart. Maybe that could be considered for a future new major or minor version.

japtain-cack commented 1 year ago

I second this change. Managing certs by hand is so 5 years ago. I'm using cert manager + vault for automatically provisioned, short lived pki certs and secrets. I cannot use provisioned certs/secrets for concourse due to this.

japtain-cack commented 10 months ago

Finally got around to doing this. Still wip, but I got most of it. I doubt this will ever be approved as a PR and merged in, because it would break a lot of existing deployments. So far I have web, vault, postgres, and oidc all working with cert-manager + vault.

https://github.com/japtain-cack/concourse-chart/tree/nsnow/cert-manager