auto-generate SSL config

[rickducott]

If I am deploying a service that uses TLS, an upstream automatically gets generated for that service but the upstream doesn't have ssl configured and I have to edit the resource to enable encryption. Is there an annotation or something I can add to the service so that the ssl config is added automatically?

EDIT: this request came in from a user.

[ilackarms]

as an alternative to putting annotations inside the kube service, i would propse creating an UpstreamProfile CRD which essentially contains the whole UpstreamSpec minus the UpstreamType field. instead, it can point to a kube service, and we can attach it to the generated upstream

[yuval-k]

not sure what's the advantage of UpstreamProfile over just an Upstream, as it is something that needs be created in addition to the service either way. i.e. what's the advantage of this approach over disabling discovery and creating upstreams manually?

[rickducott]

Agreed, not seeing the logic of UpstreamProfile for this particular issue. The original request for an annotation seems (a) is easier to write than an upstream, and (b) means the SSL config won't be lost if the upstream is accidentally deleted.

I should note that even though I'm the author of this issue, the request came in from a user.

[mitchdraft]

The UpstreamProfile concept seems well aligned with the offerings of our discovery service. It could allow users to specify a single value that would be used on all "n" upstreams. This seems better than telling them to disable discovery entirely. To generalize, we might call it DiscoveryHook with one type being custom ssl configs that are applied when a service matches a given selector. Another hook could be a selector that tells discovery not to create an upstream from the matching services.

Annotations are appealing for their simplicity: localizing the effect, and reducing the number of APIs involved in specifying the behavior. It would be nice to offer something like this if we expect users to want this behavior on a small number of services.

Having both would be nice: allow simple specs through annotations, provide more advanced features in a dedicated CRD. Each "user interface" would use the same underlying logic. We could begin with whichever is quickest to implement.