| Summary: | Not able to request a valid SSL from CA with internal hawkular-metrics name | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Boris Kurktchiev <kurktchiev> |
| Component: | Hawkular | Assignee: | Matt Wringe <mwringe> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | chunchen <chunchen> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.1.0 | CC: | aos-bugs, lmeyer, wsun |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-05-05 15:19:49 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Boris Kurktchiev
2016-02-10 16:06:41 UTC
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. |