oidc-dex container is reporting 3 TLS errors every 10 seconds on subclouds

[Ghada Khalil]

Brief Description
-----------------
After installing the Windows AD OIDC application on the subclouds container log is reporting 3 TLS errors every 10 seconds.

$ kubectl logs -f oidc-dex-5b8d7d6f7c-nnrg2 -n kube-system

2020/04/08 18:34:14 http: TLS handshake error from 169.254.202.2:37268: remote error: tls: bad certificate
2020/04/08 18:34:24 http: TLS handshake error from 169.254.202.2:37346: remote error: tls: bad certificate
2020/04/08 18:34:34 http: TLS handshake error from 169.254.202.2:37418: remote error: tls: bad certificate

Severity
--------
Minor - doesn't seem to have a negative system impact, but floods the logs

Steps to Reproduce
------------------
-Run helm-override update "system helm-override-update oidc-auth-apps dex kube-system --values /home/sysadmin/ssl/dex-overrides.yaml"

-On Subcloud Apply AD OIDC application "System application-apply oidc-auth-apps"

-Run command "kubectl logs -f oidc-dex-5b8d7d6f7c-nnrg2 -n kube-system"

-log message "2020/04/13 13:06:44 http: TLS handshake error from 169.254.202.2:44314: remote error: tls: bad certificate" is seen every 10 seconds.

Expected Behavior
------------------
No error logs

Actual Behavior
----------------
Error logs are generated every 10 seconds

Reproducibility
---------------
Reproducible

System Configuration
--------------------
Distributed Cloud / issue is on the subclouds

Branch/Pull Time/Commit
-----------------------
Any recent stx master load

Last Pass
---------
N/A - this is likely an issue since the introduction of the active directory feature

Timestamp/Logs
--------------
See above

Test Activity
-------------
Feature Testing

Workaround
----------
Unknown

[Ghada Khalil (gkhalil)]

stx.4.0 / medium priority - this should be investigated in case it's indicative of a bigger issue

[Ghada Khalil (gkhalil)]

Moving to stx.5.0 as there hasn't been any negative system impact related to this error. The oidc-dex is fully functional.

[Ghada Khalil (gkhalil)]

Attempts to reproduce this issue were not successful in recent loads.
The suspicion is that the Kubernetes cluster kube-apiserver was perhaps not configured with the issuer_url pointing to the floating oam ip of the subcloud