support custom ca chain

[butonic]

In some deployments a self signed root CA is used to verify eg the certificate of S3. There are multiple ways to make ocis aware of one or more custom root CAs:

1. build a custom container to include the correct CA chain
2. set the SSL_CERT_DIR=/etc/ssl/certs env var and mount a certificate chain to eg. /etc/ssl/certs/custom.pem.

SSL_CERT_DIR will cause golang to read all certificates in that dir.

[wkloucek]

CA chain is already partly supported for eg. LDAP.

we need a clear strategy how to deal with this:

• HTTP clients
• Store / Caches
• Message Bus
• Office Integrations / WOPI
• Email Server
• Tika

So far we only have a option to switch of certificat validation.

Related:

• add option to enable encrypted communication #109

[butonic]

Workaround in #420 (comment)

[butonic]

SSL_CERT_DIR is read by golang to pick up custom certificates. We can use it to make every pod containing a golang binary read a a custom CA.

[dj4oC]

@d7oc we need to prioritize this, because it is blocking currently @b1schumacher

[dj4oC]

@b1schumacher does @butonic - solution not work?
#420 (comment)
If not, may I ask you to create a pull request to overcome this limitation?

[b1schumacher]

The problem we are facing now, is that this is not just a S3 Problem but rather a global problem. We need the chain in every pod that needs to communicate with a service that is secured by the custom ca chain.

[dj4oC]

So basically all service definitions need to be extended by these 10 lines?

[d7oc]

There are common templates for all services. There might be one which can be used so just the template is enhanced and you get all for free.

[dj4oC]

There are common templates for all services. There might be one which can be used so just the template is enhanced and you get all for free.

Does that mean we have a even faster implementation?

[wkloucek]

How do other Helm Charts solve this challenge? I'd always prefer to stick to practices that are also used by charts like bitnami / grafana.

EDIT: also I'd need to read up on how to properly manage CAs / certificates in Kubernetes for such a case.

@b1schumacher can you maybe describe your current solution for non-oCIS deployments?

[wkloucek]

Seems like Bitnami charts have something like this:

## TLS configuration
##
tls:
  ## @param tls.enabled Enable TLS traffic
  ##
  enabled: false
  ## @param tls.authClients Require clients to authenticate
  ##
  authClients: true
  ## @param tls.autoGenerated Enable autogenerated certificates
  ##
  autoGenerated: false
  ## @param tls.existingSecret The name of the existing secret that contains the TLS certificates
  ##
  existingSecret: ""
  ## @param tls.certificatesSecret DEPRECATED. Use existingSecret instead.
  ##
  certificatesSecret: ""
  ## @param tls.certFilename Certificate filename
  ##
  certFilename: ""
  ## @param tls.certKeyFilename Certificate Key filename
  ##
  certKeyFilename: ""
  ## @param tls.certCAFilename CA Certificate filename
  ##
  certCAFilename: ""
  ## @param tls.dhParamsFilename File containing DH params (in order to support DH based ciphers)
  ##
  dhParamsFilename: ""

(taken from Bitnami Redis Chart values.yaml)

[wkloucek]

My question is also if we will have one CA or allow to have multiple, since there might be systems managed by different parts of a organisation:

• HTTP clients
• Store / Caches
• Message Bus
• Office Integrations / WOPI
• Email Server
• Tika

(from #403 (comment))

[b1schumacher]

@wkloucek We had not yet had the issue with other applications, most of the time there was a parameter to use.

I will make a merge request for this issue and add one CA. I think this will be sufficient for most the use cases. If not we can add something to the documentation to explain how to change this to multiple CA's.

# Custom CA chain
# If a custom CA chain is needed for the communcation with other services like S3 or notification services.
# The secret needs to be manually created.
customCa:
  # Adds custom CA to pods
  enabled: false
  # Name of existing secret
  existingSecret: ""

[b1schumacher]

@wkloucek @d7oc
I made a pull request.
It is possible to add multiple ca chains to the secret and with that add them all to the deployments. This will also solve the problem with different chains for different services.

[wkloucek]

It is possible to add multiple ca chains to the secret and with that add them all to the deployments. This will also solve the problem with different chains for different services.

Will it continue to use the CA certificates shipped by the OS in the container?

[b1schumacher]

Good point.
Right now this would overwrite the certificates, as all of them are already in /etc/ssl/certs

So there are to options.

1. Add another dir to SSL_CERT_DIR with the default /etc/ssl/certs, but would break with changed default paths from the container
2. Mount the CA chain as file, but then the key would have to be configured and only one would be possible

[b1schumacher]

I would prefer option 2 with a good documentation and in future an option for multiple CA chains

[wkloucek]

I saw that one can provide multiple paths separated by :, see also golang/go#35325

Which means we could support the default path and our custom one!?

[b1schumacher]

I implemented now a second path with the custom certificate and added the custom chain ca there. So now it should use both directories.

[wkloucek]

was solved in #599