cert-manager / csi-driver-spiffe Goto Github PK

From the documentation of the cert-manager we can see that csi-driver spiffe allows to use SVIDs to enable mTLS between pods within their trust domain (https://cert-manager.io/docs/projects/csi-driver-spiffe/). However, in the csi-driver documentation (https://cert-manager.io/docs/projects/csi-driver/) there is also a way to use SPIFFE IDs and it also adds the right to use dnsNames (csi.cert-manager.io/dns-names). I am wondering, what is the difference between using these two tools, so what is the csi-driver-spiffe providing additionally and why it would be useful. Can the csi-driver-spiffe also be used to validate dns names when it requests the certificate? And is there any relevant documentation for this?

Currently the namespace csi.cert-manager.io supports many different volume configuration attributes.
This set of configuration can enable for example certificate renew period using the attributes csi.cert-manager.io/duration and csi.cert-manager.io/renew-before. However I've noted that it is not implemented on spiffe.csi.cert-manager.io namespace. Instead the expiry period seem to be fixed in 1 hour like image below.

What would take to implement at least the spiffe.csi.cert-manager.io/duration and spiffe.csi.cert-manager.io/renew-before attributes to enable certificate renew for csi-spiffe-driver?

We have encountered intermittent issues where the CSI driver spiffe fails to mount the certificate on a pod.
This problem appears to occur more frequently when the CSI driver spiffe pod restarts.
Upon restarting the CSI driver spiffe pod, it seems to lose track of which pod certificates need to be renewed.
Interestingly, manually restarting the affected pod results in the correct mounting of new certificates.

We observed the following error messages in the csi-driver-spiffe log:

csi/manager "msg"="Failed to issue certificate, retrying after applying exponential backoff" "error"="waiting for request: certificaterequest.cert-manager.io \"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\" not found" "volume_id"="csi-xxxxxxxx"
.......
csi/driver "msg"="failed processing request" "error"="timed out waiting for the condition" "request"={}
"rpc_method"="/csi.v1.Node/NodePublishVolume"
.......

We have already reviewed a previously closed issue (cert-manager/csi-driver#78) and updated the CSI data directory, but this did not resolve the problem.
We are actively looking for workarounds to address this behavior. One potential solution we are considering is utilizing a liveness probe.
We are seeking guidance on how to further identify and potentially resolve this issue.
Any suggestions regarding additional information we can provide would be greatly appreciated.

subj

Currently there is no Helm chart support to include imagePullSecrets for csi-driver-spiffe

the default csiDataDir value might collide with csi-driver: https://github.com/cert-manager/csi-driver-spiffe/blob/main/deploy/charts/csi-driver-spiffe/values.yaml#L55

Loggers for the driver and the approver are currently ultimately created by klog.TODO in this section of code.

The flow control here is confusing and could be improved, and TODO is also documented as a "last resort".

In #126, we bumped test timeouts.
However, it was not clear why the test is taking that long.
This issue aims to track any similar issues that might indicate that there is an underlying issue to these timeouts.

Currently timeouts for checking for success are scattered across tests (e.g. here) and so are hard to change.

They're also quite low and could easily flake in a resource constrained testing environment.

It would be better to have a single const controlling global timeouts to make this easier to change and to make it obvious what's happening.

The above linked code block could be rewritten to:

Eventually(func() bool {
	Expect(f.Client().Get(f.Context(), client.ObjectKeyFromObject(&certificateRequest), &certificateRequest)).NotTo(HaveOccurred())
	return apiutil.CertificateRequestIsApproved(&certificateRequest)
}).WithTimeout(testTimeout).WithInterval(pollInterval).WithContext(ctx).Should(BeTrue(), "expected request to become approved in time")

Note that this also passes the context into the Eventually function which would be useful if we were to enforce a global timeout on all e2e tests in the future

Bit of a niche case but wanting to run the driver using firefly issuer- which when running in controller mode uses the certificate request annotation to determine which policy to apply to issue the certificate.

I have some code to do this globally and apply annotations to all certificate request resources, which seemed like the easiest way to configure it but could also configure it as volume attributes too if preferred