Allow Vault CR service to use run on a different port than the pod API

[dhohengassner]

Is your feature request related to a problem? Please describe. I cannot configure Vault CR to create a service available under port 443 pointing to the pod API on a different port.
Vault per default exposes its HTTPS endpoint under port 8200.

The k8s service I like to create would need to look like this:

spec:
 ports:
 - name: api-port
   port: 443
   protocol: TCP
   targetPort: 8200
 - name: metrics
   port: 9091
   protocol: TCP
   targetPort: 9091
 - name: statsd
   port: 9102
   protocol: TCP
   targetPort: 9102
 selector:
   app.kubernetes.io/name: vault

With the fields available in the Vault CR I can define:

  servicePorts:
    api-port: 8200
    external-port: 443

But the resulting k8s svc only provides:

spec:
 ports:
 - name: api-port
   port: 8200
   protocol: TCP
   targetPort: 8200
 - name: external-port
   port: 443
   protocol: TCP
   targetPort: 443
 - name: metrics
   port: 9091
   protocol: TCP
   targetPort: 9091
 - name: statsd
   port: 9102
   protocol: TCP
   targetPort: 9102
 selector:
   app.kubernetes.io/name: vault

The Vault pods also do not start if they are configured to run the API directly on port 443 (probably does make sense):

Error initializing listener of type tcp: listen tcp4 0.0.0.0:443: bind: permission denied
2021-05-19T15:18:14.067Z [INFO]  proxy environment: http_proxy= https_proxy= no_proxy=

Describe the solution you'd like The CR should support configuration like:

  servicePorts:
    api-port:
      port: 8200
      targetPort: 443

Describe alternatives you've considered Until this is supported I do not use the Vault Service created from the CR and create another one next to it.

Thanks for looking into this!

[universam1]

Second that Vault should be possible to access on the default ports like 80/443

[gw0]

I am wondering... Which problem does this solve? Just an aesthetic one -- that the URL does not need to specify the port :8200? Or am I missing something?

[universam1]

Couple of policy reasons and requirements that come into play. First we can safely say there is no benefit in running at a high port, it causes human confusion and requires documentation overhead deviating from the standards. Nevertheless, in our company the firewall policy does not permit other random high ports for http/https for firewall rules zone transitions other than the approved default ports. So kind of a hard requirement, and we don't want to treat access differently whether it's in- or cluster external.