ejbca-k8s-csr-signer
An implementation of the Kubernetes CSR signing API that routes Certificate Signing Requests from the cluster to the EJBCA Enrollment API
Integration status: Production - Ready for use in production environments.
About the Keyfactor API Client
This API client allows for programmatic management of Keyfactor resources.
Support for ejbca-k8s-csr-signer
ejbca-k8s-csr-signer is open source and supported on best effort level for this tool/library/client. This means customers can report Bugs, Feature Requests, Documentation amendment or questions as well as requests for customer information required for setup that needs Keyfactor access to obtain. Such requests do not follow normal SLA commitments for response or resolution. If you have a support issue, please open a support ticket via the Keyfactor Support Portal at https://support.keyfactor.com/
To report a problem or suggest a new feature, use the Issues tab. If you want to contribute actual bug fixes or proposed enhancements, use the Pull requests tab.
EJBCA Certificate Signing Request Proxy for K8s
]()
The EJBCA Certificate Signing Request Proxy for K8s forwards certificate signing requests generated by Kubernetes to EJBCA for signing by a trusted enterprise certificate authority. The signer operates within the K8s CertificateSigningRequests API and implements a Controller that uses the the V1 CertificateSigningRequests informer to handle associated resources. CSRs are only enrolled if they are approved using an approver.
Community supported
We welcome contributions.
The cert-manager external issuer for Keyfactor command is open source and community supported, meaning that there is no SLA applicable for these tools.
To report a problem or suggest a new feature, use the Issues tab. If you want to contribute actual bug fixes or proposed enhancements, see the contribution guidelines and use the Pull requests tab.
Migration from EJBCA CSR Signer v1.0 to v2.0
The EJBCA CSR Signer v2.0 has breaking changes from v1.0. To migrate from v1.0 to v2.0, uninstall the v1.0 deployment and install the v2.0 deployment. The v2.0 deployment uses the same configuration as v1.0, but the configuration is now stored in a Kubernetes ConfigMap. See the Getting Started to install the v2.0 deployment.