Added custom ca chain to deployments

[b1schumacher]

Description

Added the custom CA Chain variables to the values.yaml and added the ca to services and jobs.

Related Issue

• Fixes #403

Motivation and Context

Custom CA chains are required for multiple services, which require that ocis is trusting these ca's

How Has This Been Tested?

• Tested the deployment with custom CA Chains

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

[d7oc]

Would be good to have this fragment templated so we don't have these lines in all deployments.yml file but only one with a call here.

suggestion

{{/*
oCIS ca mount

@param .path          The path to mount
@param .scope.      The current scope
*/}}
{{- define "ocis.caPath" -}}
            {{- if .scope.Values.customCAChain.enabled }}
            - name: custom-ca-chain
              mountPath: {{ .path }}
            {{- end }}
{{- end -}}

Usage afterwards with {{- include "ocis.caPath" (dict "scope" . "path" /etc/ssl/certs) }}

[b1schumacher]

I changed all the entries to a template and fixed also the issue that the customCAChain was overwriting the other CA files.

Now there are two different directories, one with the default files and one with the custom CA chain. Both are added to the SSL_CERT_DIR variable.

[wkloucek]

@b1schumacher I applied some formatting and added enabled this feature in the linting process.

So far I didn't get the pattern for which services the custom CA has been configured / skipped. Could you maybe elaborate why it's not on all services?

Also what's missing are the CronJobs, some of them only talk to NATS but even for this, we could make use of this feature.

[b1schumacher]

@wkloucek I added the missing services and the jobs.

[wkloucek]

I changed this to point to stable-5 instead of main which is now tracking ocis rolling releases

[wkloucek]

Is there a particular reason for the CA chain to be put in a secret? From what I know, a CA chain is public information and would therefore also be suitable for a ConfigMap.

[wkloucek]

I changed it to a ConfigMap in e344382

[wkloucek]

@d7oc From my side this PR is ready for review / merge now.

You can give it a try by running the newly added deployment example. It'll create a CA and trust it on the oCIS side. It also will use the CA for generating a certificate for the Ingress and use this instead of the default dummy certificate (generated by most ingress controllers). Therefore we can actually skip enabling the insecure.oidcIdpInsecure and insecure.ocisHttpApiInsecure options and still login / upload files .

[d7oc]

LGTM aside the typo. Also verified locally via k3d.

[d7oc]

LGTM