Red Hat Bugzilla – Bug 1444367
ansible doesn't allow to set challenge true for Openid and gitlab
Last modified: 2017-11-28 16:53:29 EST
Description of problem: When using ansible to configure the openID-connect provider we got an error when setting 'challenge' to true. This happens because of the validate function not allowing this [2]. [2] https://github.com/openshift/openshift-ansible/blob/7496b1235f72bd4241e4917f50df722174bf90fa/roles/openshift_master_facts/filter_plugins/openshift_master.py#L348 Support for the resource owner password grant flow was added in 3.3 (https://github.com/openshift/origin/pull/8732) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: It gives an error when setting challenge=true Expected results: It should allow challenge true for openid and gitlab providers. Additional info:
https://github.com/openshift/openshift-ansible/issues/4417 upstream issue open too
PR Created: https://github.com/openshift/openshift-ansible/pull/5828
Re-test this bug with openshift-ansible-3.7.0-0.189.0.git.0.d497c5e.el7.noarch, still failed. openshift_master_identity_providers=[{'name': 'github', 'challenge': 'true', 'login': 'true', 'kind': 'GitHubIdentityProvider', 'clientID': 'xxx', 'clientSecret': 'xxx' }] TASK [openshift_master : set_fact] ********************************************* Thursday 02 November 2017 07:06:18 +0000 (0:00:01.460) 0:07:46.683 ***** fatal: [ec2-54-234-90-16.compute-1.amazonaws.com]: FAILED! => {"failed": true, "msg": "|failed provider GitHubIdentityProvider does not allow challenge authentication"}
It seems the validation code was being applied in two separate places. New PR Created: https://github.com/openshift/openshift-ansible/pull/5988
Fix should be in openshift-ansible-3.7.0-0.196.0
Re-test with openshift-ansible-3.7.0-0.196.0.git.0.27cd7ec.el7.noarch, FAIL. Though installer does not refuse the setting, master is forbidding chanllenge set to true. RUNNING HANDLER [openshift_master : restart master api] ************************ Tuesday 07 November 2017 05:49:51 +0000 (0:00:00.016) 0:13:11.566 ****** fatal: [ec2-34-230-15-172.compute-1.amazonaws.com]: FAILED! => {"changed": false, "failed": true, "msg": "Unable to restart service atomic-openshift-master-api: Job for atomic-openshift-master-api.service failed because the control process exited with error code. See \"systemctl status atomic-openshift-master-api.service\" and \"journalctl -xe\" for details.\n"} # journalctl -f -u atomic-openshift-master-api Nov 07 00:59:50 ip-172-18-7-188.ec2.internal systemd[1]: Starting Atomic OpenShift Master API... Nov 07 00:59:51 ip-172-18-7-188.ec2.internal atomic-openshift-master-api[23908]: I1107 00:59:51.437606 23908 start_api.go:104] Using a listen address override "0.0.0.0:8443" Nov 07 00:59:51 ip-172-18-7-188.ec2.internal atomic-openshift-master-api[23908]: I1107 00:59:51.438334 23908 plugins.go:77] Registered admission plugin "NamespaceLifecycle" Nov 07 00:59:51 ip-172-18-7-188.ec2.internal atomic-openshift-master-api[23908]: W1107 00:59:51.439442 23908 start_master.go:290] Warning: assetConfig.loggingPublicURL: Invalid value: "": required to view aggregated container logs in the console, master start will continue. Nov 07 00:59:51 ip-172-18-7-188.ec2.internal atomic-openshift-master-api[23908]: W1107 00:59:51.439466 23908 start_master.go:290] Warning: assetConfig.metricsPublicURL: Invalid value: "": required to view cluster metrics in the console, master start will continue. Nov 07 00:59:51 ip-172-18-7-188.ec2.internal atomic-openshift-master-api[23908]: W1107 00:59:51.439474 23908 start_master.go:290] Warning: oauthConfig.identityProvider[0]: Invalid value: "null": no organizations or teams specified, any GitHub user will be allowed to authenticate, master start will continue. Nov 07 00:59:51 ip-172-18-7-188.ec2.internal atomic-openshift-master-api[23908]: W1107 00:59:51.439481 23908 start_master.go:290] Warning: aggregatorConfig.proxyClientInfo: Invalid value: "": if no client certificate is specified, the aggregator will be unable to proxy to remote servers, master start will continue. Nov 07 00:59:51 ip-172-18-7-188.ec2.internal atomic-openshift-master-api[23908]: Invalid MasterConfig /etc/origin/master/master-config.yaml Nov 07 00:59:51 ip-172-18-7-188.ec2.internal atomic-openshift-master-api[23908]: oauthConfig.identityProvider[0].challenge: Invalid value: true: A GitHub identity provider cannot be used for challenges Nov 07 00:59:51 ip-172-18-7-188.ec2.internal systemd[1]: atomic-openshift-master-api.service: main process exited, code=exited, status=255/n/a Nov 07 00:59:51 ip-172-18-7-188.ec2.internal systemd[1]: Failed to start Atomic OpenShift Master API. Nov 07 00:59:51 ip-172-18-7-188.ec2.internal systemd[1]: Unit atomic-openshift-master-api.service entered failed state. Nov 07 00:59:51 ip-172-18-7-188.ec2.internal systemd[1]: atomic-openshift-master-api.service failed.
(In reply to Johnny Liu from comment #10) > Re-test with openshift-ansible-3.7.0-0.196.0.git.0.27cd7ec.el7.noarch, FAIL. > > Though installer does not refuse the setting, master is forbidding > chanllenge set to true. Johnny, this bug affects GitLab, not GitHub. Can you verify with GitLab? It should be supported for challenge auth, GitHub is specifically not supported with challenge auth.
PR Created to re-implement github and google check: https://github.com/openshift/openshift-ansible/pull/6046
Verified this bug with openshift-ansible-3.7.0-0.198.0.git.0.16275e5.el7.noarch, and PASS. Setting the following line into inventory host file: openshift_master_identity_providers=[{'name': 'gitlab', 'challenge': 'true', 'login': 'true', 'kind': 'GitLabIdentityProvider', 'clientID': 'xxx', 'clientSecret': 'xxx', 'url': 'https://gitlab.com/'}] installation is completed successfully, and login succeed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:3188