Skip to content

Missing cert-manager.io/revision-history-limit volume attributes for CSI-Driver #241

@coldnfire

Description

@coldnfire

Description:
We have encountered an issue with the CSI-driver provided by cert-manager, specifically concerning the absence of the cert-manager.io/revision-history-limit volume attributes. This omission becomes problematic in our deployment scenarios where pods are rescheduled.

Problem:
Each time a pod equipped with cert-manager's CSI-driver is rescheduled, a new certificate request is generated. However, the historical data of previous certificate requests is preserved indefinitely due to the lack of an appropriate revision history limit. This behavior results in an unnecessary accumulation of old certificate requests, which can potentially lead to clutter and resource wastage in our Kubernetes environment.

Expected Behavior:
We expect the CSI-driver to incorporate the cert-manager.io/revision-history-limit volume attributes to limit the history of stored certificate requests. Ideally, this would allow us to specify the number of past certificate requests to retain, effectively managing the lifecycle of these objects and preventing the accumulation of outdated certificates.

Suggested Solution:
Please consider adding support for the cert-manager.io/revision-history-limit volume attributes in the CSI-driver configurations. This feature would provide significant control over the certificate request history, allowing us to maintain a cleaner and more efficient system.

Steps to Reproduce:

  1. Deploy a pod with a cert-manager CSI volume in a Kubernetes cluster.
  2. Reschedule the pod by deleting the existing pod or through deployment scaling.
  3. Observe the generation of a new certificate request while the previous requests remain preserved.

Impact:
The current behavior leads to operational inefficiencies and increased resource consumption, which could adversely affect systems with frequent pod rescheduling or deployments.

Environment:

  • Kubernetes version: v1.28.6
  • csi-driver: v0.8.0
  • Cert-manager version: 1.14.3
  • Cluster environment: vanilla

Additional Context:
Any further insights into how the CSI-driver handles certificate requests upon pod rescheduling would be appreciated. This could help us better understand the lifecycle management of certificates within our clusters.

Thank you for addressing this matter.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions