Allow specifying different issuers for different Services

[dan-j]

Taken from a discussion on Slack: https://knative.slack.com/archives/C0186KU7STW/p1644261780362609

I'd like to have a way to use a different cert-manager issuer for particular services. This could be achieved in one of two ways:

1. overridden by an annotation on my service
2. multiple configs provided in config-certmanager with a label selector

Option 1) seems easier to implement, although option 2) is more similar to how domain mapping is performed for overriding cluster-domain.

[dprotaso]

cc @nak3 @carlisia

[dprotaso]

/good-first-issue
/kind feature

[knative-prow-robot]

@dprotaso: The label(s) kind/feature cannot be applied, because the repository doesn't have them.

Details

In response to this:

/good-first-issue
/kind feature

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[knative-prow-robot]

@dprotaso:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

Details

In response to this:

/good-first-issue
/kind feature

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dan-j]

@dprotaso @nak3 @carlisia

Do any of you have a preferred approach on how to implement this? Not sure how much time I can spare but I'd be willing to try and fit this in.

[nak3]

Thank you @dan-j !

I prefer to option-2. I am assuming that users want to specify different issuers for different domains so it would be better to align with the cluster-domain's label selector way.

With said, Red Hat's OpenShift Serverless (Knative) does not use net-certmanager so I am not so familiar with the use case. Any other thoughts @dprotaso @carlisia @ZhiminXiang ?

[nak3]

And I guess the code for option-2 will not be so complicated if we use contour's this data structure as a reference - https://github.com/knative-sandbox/net-contour/blob/aa1a8a4cc22f8ddd09ab154f9af07b1ded994959/config/config-contour.yaml#L51-L57 and around https://github.com/knative-sandbox/net-contour/blob/aa1a8a4cc22f8ddd09ab154f9af07b1ded994959/pkg/reconciler/contour/config/contour.go#L54-L57

IIRC, the code around config-domain is a little bit complicated 😅

[carlisia]

/assign @carlisia

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[carlisia]

/remove-lifecycle stale