As part of the implementation guidelines, CONJUR_SSL_CERTIFICATE is one of the key parameters while configuring as environmental variables for the conjur using summon-provider, however we have tested without without providing the DAP follower certificates on VM’s, working without errors, so what is the role of DAP follower certificates and why it is working even when we removed it ?
Hey @gautamkanithi, CONJUR_SSL_CERTIFICATE / CONJUR_CERT_FILE is used to set the certificate pool for the summon-conjur endpoint verification through the API module. When you use that variable, you are asserting that the presented certificate is signed by that certificate only. When you omit these variables, you are using the default system CA store and all of its root certificates to verify that one of those has signed your Conjur endpoint.
In essence:
When you use CONJUR_SSL_CERTIFICATE (or CONJUR_CERT_FILE):
Conjur endpoint server SSL certificate must be signed by this certificate (and other validity checks like NotAfter must pass).
If a certificate from Conjur endpoint server is not signed by this exact certificate or the validity conditions fail, connection will fail.
When you omit both CONJUR_SSL_CERTIFICATE and CONJUR_CERT_FILE:
Default SSL certificate store is used as a CA pool.
If Conjur endpoint server certificate is signed by one of those certificates (and other validity checks like NotAfter pass), connection will succeed. This means usually that if a browser will think that this is a valid certificate, summon-conjur will consider it valid too.
If a certificate from Conjur endpoint server is not signed by any of those root certificates or validity conditions fail, the connection will fail.
Hope that helps. Let us know if the behavior you see does not match the one I described here.
Would like to know can we use the same principle of adding CA root in the openshift hosts as well. Do we need to specifically mention the DAP follower certificate or a root and intermediate CA’s to the openshift images for the hosts.
Would like to know can we use the same principle of adding CA root in the openshift hosts as well. Do we need to specifically mention the DAP follower certificate or a root and intermediate CA’s to the openshift images for the hosts.
We have placed the Root and Intermediate CAs on the path /etc/pki/ca-trust/source/anchors as a configmap and update the pod with the respective volume mount configuration, however during the start up of the PODS, we are getting the below error, this shows K8S secrets provider is explicitly checking for DAP follower certificates on the POD to connect to DAP.
INFO: 2020/09/29 08:20:51 main.go:23: CSPFK008I CyberArk Secrets Provider for Kubernetes v1.1.0-dev starting up
DEBUG: 2020/09/29 08:20:51 main.go:115: CSPFK001D Debug mode is enabled
ERROR: 2020/09/29 08:20:51 config.go:90: CAKC007E At least one of CONJUR_SSL_CERTIFICATE and CONJUR_CERT_FILE must be provided
ERROR: 2020/09/29 08:20:51 config.go:74: CAKC021E Failed to read SSL Certificate. Reason: CAKC007E At least one of CONJUR_SSL_CERTIFICATE and CONJUR_CERT_FILE must be provided
ERROR: 2020/09/29 08:20:51 main.go:107: CSPFK008E Failed to instantiate authenticator configuration
Hmm… I have not worked with the Secrets Provider previously. Let me see if I can find someone to answer that for you but it looks like it’s asking for a certificate even though it should probably be able work without one specified (and use the system CA store).
I’ve spent a lot of time looking into your issue this morning and I got some more info for you which I will break down into sections since there is a lot of it:
Most DAP/Conjur tools’ use of system store
When you omit both CONJUR_SSL_CERTIFICATE and CONJUR_CERT_FILE, the fallback will be to system store so my original answer to your question about summon-conjur here was accurate.
conjur-authn-k8s-client (“authn-k8s client”)
This is the client that validates pod information and gives you a token that other Conjur tools can use to fetch secrets. This particular product usually runs as a sidecar in its own container and has no access to app container’s system CA store so it does not natively support use of system CA store. You might be able to run this product from the app container itself and this is a very unusual deployment scenario but it should be supported so I’ve opened an issue for it on GitHub.
Secrets provider
Secrets provider uses conjur-authn-k8s-client (“authn-k8s client”) as the base logic to retrieve the authentication token from Conjur and also runs in it’s own container (or pod depending on the version you are running) so it has the same limitations. Because of this, use of system store of the app is not possible at this time and we recommend using CONJUR_SSL_CERTIFICATE and CONJUR_CERT_FILE for it.
@sgnn7 Dear appreciate your work here, this needs to be addressed at the earliest since the DAP follower certificates will/ have to be renewed or updated in our ecosystem based on security rules.
Hence this makes dependencies of the product to deploy in application environment where management of the SSL certificates is a tough task.
Hi @gautamkanithi,
There may be options for this but we will need to know your full infrastructure setup to make recommendations for which this forum is not the best communication path. Can you open a case in SalesForce so that we can track it better and have more support resources to assist you?