We have an important customer who wants to : - create a mysql user for each openstack component and each openstack controller node. ie : neutron[1..3], cinder[1..3], nova etc. - Restrict the origin (ip address) of connection for each mysql user according to the openstack node from where this account is used. This is a restriction from ANSSI (french security agency). Is it something "doable", but more than "doable" don't you think that this may break lifecycle. As this is not a PoC but will be in production.
I haven't tried it but I think we would need to change <service_name>::db::mysql::allowed_hosts to use a list of IPs where the service is running instead of mysql_bind_host value. I'm assigning the BZ to PIDONE for now as it's purely how we configure MySQL resources. Let me know if you need help from DFG:DF.
Created attachment 1307247 [details] moves openstack services to talk to a local haproxy -> galera server I've tested this once so far and will be running it a few more times on some tripleo deployments to learn more about it.
Created attachment 1307808 [details] account_per_controller.sh, skips services that aren't DB configured
Created attachment 1308526 [details] account_per_controller.sh, writes entries to a per-controller cnf file the latest, which uses the approach of writing out usernames, passwords, and ip numbers to /etc/my.cnf.d/account_per_controller.cnf. The URLs inside of each openstack .conf file now name only the database name and the name of an entry inside of account_per_controller.cnf. This makes the URLs in the openstack conf files controller-agnostic, and safe for storage in the database itself where they can be consumed by any controller; the local controller then provides context to the URL that contains controller-specific usernames and passwords. This is not unlike the idea of using datasource names (DSNs) as in ODBC. The usernames are also themselves numbered from the controller itself, e.g. openstack-controller-0 would grant nova0, keystone0, etc.
Created attachment 1308527 [details] sample_output.txt from controller 2 this is a test run from controller2. The lines with plus signs show when it is making changes to things. Note that you don't see the DROP USER commands here because they were already run on controller0, and most of the work in this particular run is adding new "<username>2" user accounts, e.g. nova2, nova_api2, neutron2, etc. as well as the entries to account_per_controller.cnf local to controller2. The script has many checks for if it's been run already and needs to only refresh things, or if parts of its work are already done, etc. The yum install of openstack-utils gives us the openstack-config command, which is a front-end to a tool called crudini which allows us to read and write ini files.
Created attachment 1308528 [details] sample account_per_controller.cnf file this is a sample of the .cnf file itself which contains an entry for every distinct openstack-service mysql username encountered in the overcloud, and within it defines controller-local aspects including a new username, password, and the local ip number with port 3307, which will refer to the local haproxy service. The use of this file replaces the use of the tripleo.cnf file, which was added in ocata to implement the "bind_address" setting in a controller-agnostic way. This bind_address is replicated in the new account_per_controller.sh file; however note that it isn't actually necessary in this configuration, since the purpose of the bind_address was to allow the TCP connection to close properly when pacemaker moves the galera VIP around; however we're no longer using a galera VIP so this is no longer needed.
Created attachment 1321013 [details] account_per_controller.sh, writes entries to a per-controller cnf file does a curl download of the openstack-config app and runs directly from the python command, rather than installing from any repos. checks for URLs that aren't MySQL (like mongodb) and skips.
We are closing this bug because we have not received sufficient information to make progress. Please feel free to open this bug again when you are able to provide the required information we requested.
Per Comment 42 I'm going to close this BZ. We understand that this is a feature request that has important implications for customers who need to pass security certifications, but I think this BZ is already old enough and long enough and covered the development of the post-deployment script. To re-iterate what I said before, I believe this should now be pursued via Product Manager channels to scope this properly as a multi-team project for a future OSP release.