Description of problem: When FIPS is enabled, generating the RSA private key for the CA fails Version-Release number of selected component (if applicable): 4.6 How reproducible: Install and configure the metering operator Steps to Reproduce: 1. Install the operator 2. Create a MeteringConfig 3. Actual results: Configuration fails with the following error: FAILED! => {"changed": false, "module_stderr": "Traceback (most recent call last):\n File \"/tmp/.ansible-/tmp/ansible-tmp-1605634267.8428476-419-58193365444516/AnsiballZ_openssl_privatekey.py\", line 102, in <module>\n _ansiballz_main()\n File \"/tmp/.ansible-/tmp/ansible-tmp-1605634267.8428476-419-58193365444516/AnsiballZ_openssl_privatekey.py\", line 94, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/tmp/.ansible-/tmp/ansible-tmp-1605634267.8428476-419-58193365444516/AnsiballZ_openssl_privatekey.py\", line 40, in invoke_module\n runpy.run_module(mod_name='ansible.modules.crypto.openssl_privatekey', init_globals=None, run_name='__main__', alter_sys=True)\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_openssl_privatekey_payload_jm341_63/ansible_openssl_privatekey_payload.zip/ansible/modules/crypto/openssl_privatekey.py\", line 692, in <module>\n File \"/tmp/ansible_openssl_privatekey_payload_jm341_63/ansible_openssl_privatekey_payload.zip/ansible/modules/crypto/openssl_privatekey.py\", line 676, in main\n File \"/tmp/ansible_openssl_privatekey_payload_jm341_63/ansible_openssl_privatekey_payload.zip/ansible/modules/crypto/openssl_privatekey.py\", line 303, in generate\n File \"/tmp/ansible_openssl_privatekey_payload_jm341_63/ansible_openssl_privatekey_payload.zip/ansible/modules/crypto/openssl_privatekey.py\", line 545, in _get_fingerprint\n File \"/tmp/ansible_openssl_privatekey_payload_jm341_63/ansible_openssl_privatekey_payload.zip/ansible/module_utils/crypto.py\", line 164, in get_fingerprint_of_bytes\nValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1} Expected results: Configuration succeeds Additional info: This looks similar to a previously fixed bz: https://bugzilla.redhat.com/show_bug.cgi?id=1787745. That bz was fixed with a vendored crypto.py. Upstream is now fixed in a different way: https://github.com/ansible/ansible/pull/67515.
It looks like the 4.7/master fixes were verified, but the cherrypick to the release-4.6 branch failed due to merge conflicts. I'll manually open a PR against that branch next week with the proposed fixes to get the ball rolling on this BZ again.
Going to bump the severity on this to `high` as the 4.6 backported PR is waiting for patch manager approval for a couple of weeks now and this BZ will block all metering 4.6 installations on FIPS-enabled clusters until those fixes have merged.
verified with 4.6.0-0.nightly-2021-01-30-211400 # install metering $ oc get pods NAME READY STATUS RESTARTS AGE hdfs-datanode-0 1/1 Running 0 13m hdfs-datanode-1 1/1 Running 0 12m hdfs-datanode-2 1/1 Running 0 11m hdfs-namenode-0 1/1 Running 0 13m hive-metastore-0 2/2 Running 0 13m hive-server-0 3/3 Running 0 13m metering-operator-758c6fbbd6-7rlgk 1/1 Running 0 61m presto-coordinator-0 2/2 Running 0 12m reporting-operator-5689d4bd48-h68qs 2/2 Running 1 12m # check for FIPs $ oc debug node/pruan-461-s5jm4-worker-a-jrdbt.c.openshift-qe.internal Creating debug namespace/openshift-debug-node-cmghz ... Starting pod/pruan-461-s5jm4-worker-a-jrdbtcopenshift-qeinternal-debug ... To use host binaries, run `chroot /host` chroot /host Pod IP: 10.0.32.2 If you don't see a command prompt, try pressing enter. chroot /host sh-4.4# sh-4.4# sh-4.4# cat /proc/sys/crypto/fips_enabled 1
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 (Moderate: OpenShift Container Platform 4.6.16 extras security update), 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-2021:0310
Hello Team, I could see the v4.6.16 added to the fast channel. We have a cu who is curious to know the timeline we can expect it to be added to the stable channel? Thanks, ApoorvaJ
Hey Apoorva -- we have zero control over when errata get tagged into the stable channel. IIRC it's typically (note: not always a guarantee) around 48 hours, but we have a dedicated team that makes that decision.
Hi Tim, I see. Thanks for letting me know.