-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Hono] Fix service names in example certificates #252
Comments
FMPOV it would be great if hostname verification could be enabled at least for the internal connections (i.e. between the components running in a Kubernetes cluster in the same namespace). |
I agree that this is not optimal and I also agree that we could assume (or better require) that there is only one Hono installation per kubernetes namespace. That would allow us to remove the release name from the service names (and all other artifacts that we deploy to the namespace). |
Removing the release name from the names of services, deployments, etc. would lead to an error if you try to deploy Hono a second time to a namespace. FMPOV this would be sufficient. Or are you thinking of additional explicit checking? |
No, kubernetes throwing that error should be ok FMPOV. |
The configuration for creating example certificates defines Subject alternative names for the service names, like eg. "hono-service-auth.hono". The service names are prefixed during deployment with the release name. The release name in the documentation for deploying only Hono is "eclipse-hono", in the documentation of the cloud2edge package it is "c2e", but only "hono" would match.
All client configuration I found disables hostname verification, so there is no real consequence during runtime. But FMPOV the configuration is misleading and does not serve as a good example.
The easiest solution would probably be to remove the release name prefix from the service names. The impact should be small because in practice probably no one will deploy Hono multiple times into the same Kubernetes namespace.
Another solution could be to define a "standard release name" and create the certificates for this name. This could be accompanied by informing the user via the
NOTES.txt
about the release name to be used, or even by a check that requires the release name.The text was updated successfully, but these errors were encountered: