You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Yes, the current requirement for the conjur_ssl_certificate in the CyberArk Secrets Provider for Kubernetes poses a challenge for users who need to regularly rotate SSL certificates. Each time the certificate is updated, it necessitates modifying the config map and restarting the pod, which can lead to downtime and operational overhead. This is particularly cumbersome in environments where certificate rotation is a common practice, as it disrupts the deployment process and increases the risk of human error.
Describe the solution you would like
I would like to see a feature that allows the CyberArk Secrets Provider to either not require the conjur_ssl_certificate at all or to automatically populate this variable based on the provided appliance URL. This would streamline the configuration process and reduce the need for manual updates and pod restarts, thereby improving the overall user experience and operational efficiency.
Describe alternatives you have considered
One alternative could be to implement a mechanism that allows for dynamic retrieval of the SSL certificate from the CyberArk appliance itself, rather than requiring it to be stored in a config map.
Additional context
This feature would greatly enhance the usability of the CyberArk Secrets Provider in Kubernetes environments, particularly for organizations that prioritize security and compliance through regular certificate rotation.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Yes, the current requirement for the conjur_ssl_certificate in the CyberArk Secrets Provider for Kubernetes poses a challenge for users who need to regularly rotate SSL certificates. Each time the certificate is updated, it necessitates modifying the config map and restarting the pod, which can lead to downtime and operational overhead. This is particularly cumbersome in environments where certificate rotation is a common practice, as it disrupts the deployment process and increases the risk of human error.
Describe the solution you would like
I would like to see a feature that allows the CyberArk Secrets Provider to either not require the conjur_ssl_certificate at all or to automatically populate this variable based on the provided appliance URL. This would streamline the configuration process and reduce the need for manual updates and pod restarts, thereby improving the overall user experience and operational efficiency.
Describe alternatives you have considered
One alternative could be to implement a mechanism that allows for dynamic retrieval of the SSL certificate from the CyberArk appliance itself, rather than requiring it to be stored in a config map.
Additional context
This feature would greatly enhance the usability of the CyberArk Secrets Provider in Kubernetes environments, particularly for organizations that prioritize security and compliance through regular certificate rotation.
The text was updated successfully, but these errors were encountered: