Description of problem: Security related post install tasks for domain currently manifests only to default host.xml configuration file. Remaining host-master.xml and host-slave.xml files remain untouched by the installation. This way we completely lose advantage of automatic installation (using auto.xml file) when creating domain. User will have to make the configuration himself by directly editing relevant host configuration files, because domain will fail to start. Host-master.xml and host-slave.xml files are specially configured for running domain over multiple nodes, which is the actual meaning of domain, so they shouldn't be omitted. Affected configuration tasks are: - Install password vault - Enable SSL security - Enable LDAP authentication Version-Release number of selected component (if applicable): EAP 6.2.0.ER6 How reproducible: Always Steps to Reproduce: 1. Create a vault.keystore ([1]) 2. Run GUI installer, go to Post-Install Configuration screen using default values 3. Check to Install password vault, and Install JDBC Driver with Datasource 4. On Password Vault configuration use vault.keystore from step 1 5. Setup JDBC driver (you can use postgresql driver from [2]) 6. On Datasource Setup screen choose 'Username + Password' as Security type 7. Finish the installation Now you can see that database connection is secured with password masked by Vault <password>${VAULT::ds_myNewDatasource::password::1}</password>, but Vault is initialized only for host.xml file. Starting host using other host files will fail: 1. export IP=aaa.bbb.ccc.ddd // use IP address of your machine 2. Navigate to INSTALLATION_TARGET 3. start DC with: ./jboss-eap-6.2/bin/domain.sh --host-config=host-master.xml -bmanagement=$IP & 4. start HC with: ./jboss-eap-6.2/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=$IP Actual results: HC launch will fail with java.lang.SecurityException: JBAS013322: Vault is not initialized Expected results: Both DC & HC will start successfully. Additional info: [1] - http://documentation-devel.engineering.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Security_Guide/Create_a_Java_Keystore_to_Store_Sensitive_Strings.html [2] - http://jdbc.postgresql.org/download.html
Hi Petr, We are looking at what is required to make these changes and have some questions: - Do we modify both host-master and host-slave with the vault/ldap/ssl configuration? Or just the host-master? And if we do add to both host-master and host-slave, will that cause a problem? - What properties does the host-slave inherit directly from host-master vs which properties need to be defined separately? Can you point us to documentation that explains the use case for host-master/host-slave configurations? Thanks.
Hi Francisco, I've spend some time digging requested information, but documentation is quite shallow on these topics. - ssl: We manage to configure ssl for two host, but once you secure host-master's management interface with SSL, host-slave is unable to authenticate. One must create new security-realm containing truststore with accepted certificate and add it to domain-controller remote element in host-slave.xml file (see [1]). Securing of management-interfaces would be as usual. - ldap: I am really not sure here. - vault: According to [1],[2] and [3] it should be enough to add vault element to both host files. There are some plans to use one Vault per domain, but this seem to be the music of future. The documentation for creating domain on more than one physical machine is missing, I created some BZ974127) for this some time ago, but it is still unresolved. To be honest I thought this issue will be the peace of cake, but after spending some time trying to configure this I think, we may postpone this to some future release (as next release is CR1) or wait for requirement from PM/customer. If you however decide to implement this you may try asking for help from devs or people around security (as there is no more, regarding security, I can help you with :/). I believe that none of properties are inherited between host.xml files. The only shared preperties are inside DC's domain.xml file. Petr [1] - http://documentation-devel.engineering.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Security_Guide/Using_2-way_SSL_for_the_Management_interface_and_the_CLI.html [2] - https://issues.jboss.org/browse/WFLY-1191 [3] - https://issues.jboss.org/browse/PRODMGT-332 [4] - https://docspace.corp.redhat.com/docs/DOC-148154
This enhancement is worthy of inclusion. However, there is not enough time before CR release to implement it. Thus, barring explicit PR request, we will post-pone this til a further release. This BZ should be reopened and added to the next release.
Moving to NEW as a part of CLOSED/DEFERRED bz cleanup.
Hi Petr, I've been looking at this with Tom and we were able to manually fix the error by adding the vault definition to host-slave.xml alone. Adding the vault definition to host-master had no effect on it - it worked both times. Do you know why this is? Other than that, the feature is doable.
Hi Andrew, I'll try to check this out tomorrow and let you know if I find something.
Hey Petr, We're close to having this done. The LDAP security realm needs to be defined for host-slave as well for use with the native-interface. I have a few questions about the 2-way SSL link: I always assumed that the user will be providing us with a keystore containing their certificate; is this not the case? It seems as though with 2-way we need to add fields for two keystores instead of one, as well as a field for the aliases for both keys. We can do this, but it's a pretty involved change. We could also generate the keystores, but I'm not sure we want to head down that route. The way we currently perform ssl configuration seems like it would need to change, at least for the host-slave / host-master files. Or should the changes here be performed in all server descriptors? I'd like to connect on IRC tomorrow if you have time to discuss this issue :) Thanks, Tom
Hi guys, to be honest 2-way SSL is beyond my knowledge as I never had a time to make it actually work (just checking that correct values were written to the xml here during tests). We still don't have DR4 bits, but once they arrive I'll notice the guys from security team to check the feature out and they should be able to answer any your questions. Regarding to comment 7 (very sorry for delay in response), this is just a limitation of example I used in description, because no servers are running on master host by default (host-master.xml), however user can use vault to mask other configuration values (e.g. LDAP, network interface etc.) so host-master.xml should contain the vault definition as well. Petr
Hi Petr, Any feedback from the security guys regarding how to enable / support 2-way SSL between the host-master / host-slave? Thanks, Tom
Hi Tom, I let them know to check it out.
Hi Thomas, In case you want to use "2-way SSL for the Management interface and the CLI" according to [1], you may need 2 keystores for master and 2 keystores for each slave -- a keystore for server identity certificate and a keystore for trusted certificates. These keystores are used by security realms -- in case host-master.xml such realm is used by native interface (see [1]), in case host-slave.xml such realm is used by remote element in domain-controller element. Hope this helps. I was able to setup domain using hints described above. [1] https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/html-single/Security_Guide/index.html#Using_2-way_SSL_for_the_Management_interface_and_the_CLI
This feature won't be available in DR8.
Hye Petr, Do you think we should implement the changes needed for 2-way SSL? We'd need to make many changes to the UI for the many new keystores we'd need - 3 more passwords and 3 more file browser UIs - 4 more paths / passwords to create said keystores. If we want to go ahead and add this, we can. However, it won't be ready for DR12.
I've implemented the 1-way SSL by adding a truststore entry to the existing ManagementRealm security-realm.
All configuration tasks mentioned in description are now working as expected. Verified on EAP 6.4.0.ER1 installer.