pingidentity-devops-getting-started
pingidentity-devops-getting-started copied to clipboard
privateCert: generate: true does not update pingfederate admin SSLServer certificate
Describe the bug If this switch is enabled: privateCert: generate: true it seems that newly generated certificates are not used / updated to pingfederate admin SSL certificate
To Reproduce Steps to reproduce the behavior: on Openshift 4.9, apply this yaml:
pingfederate-admin: enabled: true ingress: annotations: route.openshift.io/termination: "passthrough" defaultDomain: apps.test.clusters.example.com enabled: true hosts: - host: pingfederate-admin._defaultDomain_ paths: - backend: serviceName: https path: '' pathType: ImplementationSpecific tls: - hosts: - pingfederate-admin._defaultDomain_ secretName: team-cyse-pf-ns-cert privateCert: generate: true format: "PKCS12" additionalHosts: [zima] additionalIPs: [] envs: SERVER_PROFILE_URL: https://github.com/pingidentity/pingidentity-server-profiles.git SERVER_PROFILE_PATH: getting-started/pingfederate pingfederate-engine: enabled: true envs: SERVER_PROFILE_URL: https://github.com/pingidentity/pingidentity-server-profiles.git SERVER_PROFILE_PATH: getting-started/pingfederate global: workload: securityContext: null externalImage: pingtoolkit: securityContext: null
Expected behavior it should update ssl certificate on pingfederate admin listener
Screenshots /run/secrets/private-keystore/keystore.env is created and secret team-cyse-pf-pingfederate-admin-private-cert with keys are generated but not exposed on pod filesystem(maybe there is no intention of that)
Environment: Openshift 4.9
Additional Info how values from this file keystore.env or team-cyse-pf-pingfederate-admin-private-cert secret are used to substitute SSL of pingfederateadmin SSL listener(port 9999) how this can be referenced to custom openshift secret, previously generated by, as example, certmanager operator?
The logic for generating a private cert creates that keystore.env file, and then exports those values for the scripts to use. But those variables have to actually be referenced to be applied. Currently in our default profiles, only PingAccess uses those values - see https://github.com/pingidentity/pingidentity-server-profiles/blob/fa8ffb09d69cb4eb62b40b1714c43e92e467f4c9/baseline/pingaccess/instance/data/start-up-deployer/data.json.subst#L203 .
If you'd like to make a modification to the pingfederate profile to do the same, you can use those values in the data.json.subst file. See https://github.com/pingidentity/pingidentity-server-profiles/blob/fa8ffb09d69cb4eb62b40b1714c43e92e467f4c9/baseline/pingfederate/instance/bulk-config/data.json.subst#L257 . For a workaround you can copy our pingfederate profile to your own git repo and make the modifications as necessary. We'll look at updating our default profiles to do this automatically.
Also - the secret you mentioned (...-pingfederate-admin-private-cert) only gets mounted to the initContainer, not to the running PingFederate container. The initContainer uses the tls.crt and tls.key files to generate the keystore file.
https://github.com/pingidentity/pingidentity-server-profiles/pull/113