Description of problem: So the documentation https://docs.openshift.com/enterprise/3.1/install_config/cluster_metrics.html#metrics-deployer-secrets specifies that if you want to get a proper CA signed cert, it needs to contain the "When supplying your own certificate for the Hawkular Metrics service, it must contain both the host name specified for the route as well as the internally used hawkular-metrics host name." this is posing a problem as more or less no CA I know of will actually take and process a CSR that has a SAN of a non internet routable name. For example our CA (inCommon/comodo) has the following to say about this https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/722/16/ So now I am not sure how to go about getting a properly setup metrics + SSL solution. mwringle has mentioned that there are ways to get around this possibly by changing the SSL termination policy on the OSE end, but that doesnt seem to be documented. As it stands now, as far as I can see/tell the only way to get a CA signed cert in front of this is to have the route use the CA cert/have it use the valid cert I already have in front of my router and then use a self signed cert for its internal communications? Version-Release number of selected component (if applicable): 3.1.1 How reproducible: Deploy metrics, try getting a CA signed cert with required: hawkular-metrics name
There are a few work arounds here 1) change the 'hawkular-metrics' hostname in the heapster rc to point to the external hostnam instead of the internal one 2) as mentioned, use a re-encrypting route. We should probably update the docs on how to do these steps if required. We should probably also provide something to generate the re-encrypting routes for people. The re-encryption route should probably be used by default in a future update.
I thought when we were discussing this on IRC that you said changing the hawkular-metrics hostname would break people upstream and thus wont be making that change? I am all for trying to change the hostname!
I think there may have been some confusion about my statement. We shouldn't enable an out of the box configuration where the Heapster container uses the external hostname. This is mainly because the internal hostname should always be available to the heapster instance while there is no guarantee the external hostname will be. The external hostname requires the router to be installed and the system configured so that it uses the router to resolve hostnames. An admin may also want to expose the hostname via some other mechanism rather than using the router. So making a change where the project uses the external hostname instead of the internal one for heapster would break the setup for some people. Which is why it doesn't do this by default. Now if you have already configured your external hostname and it is resolvable to the heapster instance, then it is a possibility to configure your instance to use the external hostname. But we can't make it do this by default. We do need a better solution going forward.
That makes sense, I guess I always assumed that we needed the metrics url to be "routable" and thus required the OSE router to be in place. Do you have any instructions on how to "properly" set the internal hostname to something else?
Having the OSE router in place and using that is definitely the proper way of doing it. The internal hostname comes from the OpenShift DNS and is based on the name of the service. Its not something you can change.
PR created for the OpenShift documentation on how to set a re-encrypting route: https://github.com/openshift/openshift-docs/pull/1615 This will allow people to use their own certificates without having to include the internal hostname.
Above PR merged. There is a followup PR to simplify under 3.2: https://github.com/openshift/openshift-docs/pull/1983 Regardless, this is documented now.
Yes and I have used the docs as they exist right now to create a re-encrypt and it works. A couple of comments: 1. The docs should probably throw a note somewhere that you need to pull out the self signed CA cert any time you re-deploy metrics. Its probably obvious in general but it can bite people. 2. It is still unclear to me what the performance impacts are at large scale for doing re-encrypt vs terminating at the router 3. Still doesnt solve the main issue with the docs/setup: "no CA I know of will actually take and process a CSR that has a SAN of a non internet routable name". As the docs read at the moment, re-encrypt is an "optional" way to deploy a certificate rather than the main/only truly valid way to do it other than self-signed.
For 1) we will most likely just be changing how things work so that the re-encrypt endpoint is generated as part of the deploy process if a certificate is passed as a secret. For 2) As for the performance hit, I am not sure how much this will impact things. For 3) there is still nothing stopping an individual from getting their own intermediate CA and using that to sign their certificates. But yes, its a bit of an issue that you cannot just get a certificate directly in this case. This is one of the main reasons why we are moving from allowing a user to replace the internal certificates to having those certificates be used in a re-encrypting route.