UX Unable to operate cloud with default Public TLS settings via CLI from external nodes

[Dmitry Kalashnik]

Description of the environment:
All configurations

Steps to reproduce:
1. Deploy any configuration without changing Public TLS settings
2. Add new non-admin tenant and user.
3. Install python-novaclient to any non-cluster node
4. Do any nova command with minimal set of credential in args, for example:
nova --os-username demo --os-tenant-name demo --os-auth-url http://10.109.2.2:5000/v2.0 --os-password demo list

Expected result:
+----+------+--------+------------+-------------+----------+
| ID | Name | Status | Task State | Power State | Networks |
+----+------+--------+------------+-------------+----------+
+----+------+--------+------------+-------------+----------+

Actual result:
ERROR: HTTPSConnectionPool(host='public.fuel.local', port=8774): Max retries exceeded with url: /v2/319c4bf401e44f0ea5ad4ce60a88d915/servers/detail (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known)

Workaround:
Use *_ENDPOINT_TYPE='internalURL' environment variables for every service, e.g. NOVA_ENDPOINT_TYPE=internalURL for nova.

Default fqdn that is used as part of publicURL endpoints is managed by hosts file on nodes. Obviously nodes' hosts file is not the same at any external system.

[Bogdan Dobrelya (bogdando)]

AFAIK, external access is restricted to non admin ops only, see https://bugs.launchpad.net/mos/+bug/1362641.
Please elaborate the UX impact, why it is critical?
You can always ssh to controller node and issue any CLI command from there, so there is a w/a. Hence, UX impact is a high or less.

[Dmitry Kalashnik (dkalashnik)]

You are right, please take a look at p.2 of steps to reproduce. And as non-admin user i don't have ssh access to controllers.
So it is not UX issue, it is unavailability to use publucURL endpoints from outside of cluster.

[Stanislaw Bogatkin (sbogatkin)]

Hi, Dmitry. Thank you for a report.

External environment you trying to reach cannot have an idea about external client settings, so client must to think about connection before it will try to connect.

So, there is only one way to operate a cloud with public SSL endpoints via public URLs from external machine:
1. You must have an DNS resolver properly configured. Currently nodes in cloud configures by /etc/hosts file so there are no DNS server you can point your resolver and you have to configure your client manually. If you want to have an easier way - please, propose it.
2. You must have a way to speak with SSL wrapped endpoints, cause SSL negotiation assume by design that you can confirm certificate genuineness. If you use user uploaded certificate that signed by CA your system have as trusted - it will be done automatically. If you use self-signed certificate - you must obtain it and give to your client ability to use it - or by adding it to system trusted, or by passing some parameter to client (like --os-cacert). Also you can review a way with insecure ability (when you'll use SSL connection w/o full trusted negotiation)

So, I think that your external client environment was not properly configured for managing cloud via TLS-wrapped endpoints. Please, provide additional data about your client DNS settings and actions you done to allow you client to use external certificate which cloud provides.

[Dmitry Kalashnik (dkalashnik)]

My point is that default behavior should be correct. Default Public TLS setting provides insecure tls with self-signed certificate and quasi, non resolvable with anything, fqdn.
I am pretty sure that it is not proper behavior.

[Stanislaw Bogatkin (sbogatkin)]

See, there are no such way as 'secure' or 'insecure' TLS. You or have TLS or you doesn't, that's all. If your system doesn't have an certificate site you try connect have - which side this problem is?

As regarding 'quasi' fqdn - they perfectly resolved in cloud itself, so 'non resolvable with anything' technically isn't true. I don't support this solution, actually, but there are how SSL works - you must have equal names in your HTTP header and SSL CN field, that's it. So you have to have DNS hostnames in keystone unless you have IP address in certificate.

If you sure that it is not proper behavior - just write a letter about it than all of us could think how to improve this.

[Alexander Evseev (aevseev)]

> 4. Do any nova command with minimal set of credential in args, for example:
nova --os-username demo --os-tenant-name demo --os-auth-url http://10.109.2.2:5000/v2.0 --os-password demo list

At least you should use httpS URL like https://10.109.2.2:5000/v2.0 Note: http and https!
And also as said before there is issue with certificates trust using self-signed certs…

[Dmitry Klenov (dklenov)]

Folks,

Can we disable TLS by default? I think it will resolve Dmitry's problem that external connection to the cloud does not work.

At the same time those users who need encryption will enable this feature and properly configure everything: that is adding self-signed certificate to trusted and configure DNS.

[Dmitry Kalashnik (dkalashnik)]

I have closed this bug cause it is actually not bug, just configuration issue
Thank you all.

[Nastya Urlapova (aurlapova)]

I think we have to document such functionality as minimum.