concourse / concourse-chart

Helm chart to install Concourse
Apache License 2.0
145 stars 177 forks source link

Install certificates to worker that all containers could inherit from #211

Open xtremerui opened 3 years ago

xtremerui commented 3 years ago

Currently Concourse supports specify CAs in docker resource source configure to allow the resource container to access a private registry. It also provide a flag --certs-dir to allow cert propagation.

But that is not the case for task container. A work around is to have a step to modify the task image to include the custom certs before using it. The down side is one has to either prepare that image in a different job and upload it before using it; or the step has to be ran in each individual job.

If we could find a way in helm to append custom certs to worker's certificate directory, then there is no need to either configuring --certs-dir or modifying the task image beforehand. All containers of that worker will have certs inherit from worker itself.

jknipper commented 2 years ago

I found a way to add certificates without changing any images by preparing them in an init container and share them between containers. This is even possible with the current chart. The important values for this look something like this:

worker:
  additionalVolumeMounts:
  - name: certificates
    mountPath: /etc/ssl/certs
  additionalVolumes:
  - name: certificates
    emptyDir: {}
  additionalCertificates: true
  extraInitContainers:
  - name: certificates
    image: concourse/concourse:7.4.0
    command:
    - /bin/sh
    args:
    - -ec
    - |-
      cp /worker-certs.pem/worker-certs.pem /usr/local/share/ca-certificates/sap.crt
      update-ca-certificates
      cp /etc/ssl/certs/ca-certificates.crt /certs
    volumeMounts:
    - name: certificates
      mountPath: /certs
    - name: worker-certs
      mountPath: /worker-certs.pem
secrets:
  workerAdditionalCerts: |-
    ...

Maybe the init container can be even added to the chart when additional certificates are set.

mymasse commented 2 years ago

So I've stumbled onto this issue while trying to set up additional certs we run behind a firewall with a custom CA for pretty much all resource and I couldn't get the additional worker certs to work without doing this init container. I also had to explicitly add concourse.worker.certsDir: /etc/ssl/certs for it work.

Without going the init container I don't think this will ever work because most resource will look at the /etc/ssl/certs/ca-certificates.crt file and it's not updated with the correct certs unless the init container here is run.

Other problem I found is that we provide our own secret files so we set secrets.enabled: false and without setting secrets.workerAddtionalCerts it also never works. The statefulset template doesn't work if secrets are managed externally.

ktreese commented 2 years ago

Can confirm @mymasse observation that managing secrets externally -AND- creating the worker-additional-certs secret does not work.

ktreese commented 2 years ago

Also, when secrets.enabled: true, the key within the secret is created as worker-certs, not worker-additional-certs. Typically, it would see that the secret name is the same name as the key it creates, like webTlsCert becomes web-tls-cert.

mymasse commented 2 years ago

So the latest fixed one thing, I didn't require the additional Init container to get this to work, looks like the subPath addition in the mount did the trick. Still 2 things that don't work but easy to work around:

  1. If secrets.enabled: false it will not work unless secrets.workerAddtionalCerts is also set.
  2. If concourse.worker.certsDir is not set then the CONCOURSE_CERTS_DIR env var is never set and it won't work.
mymasse commented 2 years ago

Actually just had to put back my init container, some resources rely on curl which in turns relies on the /etc/ssl/certs/ca-certificates.crt file to contain our additional certs which without the init container it does not.