The security.trust.certManager fields are marked +optional in the API, but the controller currently requires cert-manager at runtime (scheme registration, CRD watches).
This creates a gap between what the API says and what the implementation expects.
The +optional markers were a simplification for the initial implementation, not an intentional design choice.
For MVP, cert-manager is a hard requirement, so we should probably make the API reflect that.
Thoughts on what to do now:
- Mark
security.trust.certManager.issuerRef.name as required in the CRD
- Update the design doc field table to match
- Update tests to always provide
issuerRef
Looking ahead: BYO CA
At some point we might want to support users bringing their own CA certificates instead of going through cert-manager.
That would mean the controller needs to handle both paths and start cleanly without cert-manager installed.
Worth discussing whether this is something we want to support, but probably out of scope for now. Curious what others think.
The
security.trust.certManagerfields are marked+optionalin the API, but the controller currently requires cert-manager at runtime (scheme registration, CRD watches).This creates a gap between what the API says and what the implementation expects.
The
+optionalmarkers were a simplification for the initial implementation, not an intentional design choice.For MVP, cert-manager is a hard requirement, so we should probably make the API reflect that.
Thoughts on what to do now:
security.trust.certManager.issuerRef.nameas required in the CRDissuerRefLooking ahead: BYO CA
At some point we might want to support users bringing their own CA certificates instead of going through cert-manager.
That would mean the controller needs to handle both paths and start cleanly without cert-manager installed.
Worth discussing whether this is something we want to support, but probably out of scope for now. Curious what others think.