-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow arbitrary secret names for certificates #273
Comments
This seems like a good idea. If I can propose how we'd do this... My thought is that the annotations on a routable service could reference a secret by name, and the router would use that, if specified. (This would work nicely for people using router without Workflow.) Otherwise, the router would look for the secret using the same naming convention as it does today. @gerred how does that compare to your own thoughts on this? |
@krancour that looks great 👍 I was trying to sort out how to make our convention backwards portable, and I think that does it. I'll try to whip up a PR today. Would this be under the same annotation key you think? |
Not sure what you mean. I'm imagining a new annotation on a routable service. The value of that annotation, if present, just references the secret by name. |
We're on the same page then. I wasn't sure if we were talking about having logic to try to "guess" based on the existing annotation. |
Nope. No guessing. |
This issue was moved to teamhephy/router#18 |
https://github.com/PalmStoneGames/kube-cert-manager is opinionated in its secret name creation with its TPR, as is Deis in secret name usage for certificates. (append with -cert).
We should support any arbitrary secret name to make compatibility with other community tools easier.
The text was updated successfully, but these errors were encountered: