httpd-container
                                
                                 httpd-container copied to clipboard
                                
                                    httpd-container copied to clipboard
                            
                            
                            
                        Allow SSL certificate to be sourced at runtime from a Secret
I try to use this image on multiple Openshift 4.7 platforms, where the httpd service handles the SSL termination (each cluster coming with different domain).
In order to achieve this I'd like to provide the SSL key/cert pair at pod runtime using a Secret of type "kubernetes.io/tls", coming with tls.crt and tls.crt keys
Unfortunately, because of the current way certs are sourced in the httpd-container, I can't mount this secret to any pod folder and get the pair picked up by the container at runtime.
--> Would it be possible to change the way SSL cert/key pair are sourced so that Secrets can be used? Thanks
- Ref: https://github.com/sclorg/httpd-container/tree/master/2.4#source-to-image-framework-and-scripts ./httpd-ssl Can contain user's own SSL certificate (in the certs/ subdirectory) and a key (in the private/ subdirectory)
- Ref2: https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets
Are the secrets available as files during the s2i assemble process? I'm not sure how this works.
Hello @notroj There is no build/s2i process involved here, I'm actually trying to avoid building a new image here, but rather use the httpd-container image directly (using registry.access.redhat.com/ubi8/httpd-24:latest) in my deployment.
Rationale for this is to keep binaries/images alignment between multiple clusters, and only provide specific runtime configuration on a per cluster basis using Secrets / ConfigMaps mounted at pod runtime. (This requirement comes from our release process, involving testing in non-prod clusters and then deployment in multiple production clusters.)
This is mostly the same issue as sclorg/s2i-php-container#369. Would you consider a pull request that adding this?