Add support for spire-server ingress

[kfox1111]

This patch enables the spire-server to be exposed outside the cluster utilizing an ingress controller that supports ssl passthrough such as ingress-nginx. It also adds tests to ensure that an agent can reach it through an ingress.

Resolves #61

[kfox1111]

Ingress object comes right from "helm create"

[marcofranssen]

My main concern is how we can guarantee we don't introduce vulnerabilities from allowing to expose insecure ingress configurations. Maybe we should also consider a opiniated out of the box secure setup. I'm fine with both, but I think we need to discuss this and agree collectively on the solution design.

[kfox1111]

My main concern is how we can guarantee we don't introduce vulnerabilities from allowing to expose insecure ingress configurations. Maybe we should also consider a opiniated out of the box secure setup. I'm fine with both, but I think we need to discuss this and agree collectively on the solution design.

Hmm..... Yeah, I understand trying to save the user from themselves.... how to do it though, since that part of the k8s api was never standardized....

We could force the annotations in unless they disable them, but its still not guaranteed another ingress controller would honor them. in fact, aws seems to do it quite differently: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.2/guide/tasks/ssl_redirect/#example-ingress-manifest

It would be a pretty ugly game of wack a mole...

One option might be to need an extra value when enabling ingress that states: IHaveReadTheInstructions:true before it allows the chart to be installed with ingress.enabled true? Then they have the opportunity to review the instructions, and if they set it without looking, its on them?

[kfox1111]

Actually, I thought we were talking about the other pr...

In this one, the only way to pass it through ingress is with sni. So it can't be insecurely passed through.

[kfox1111]

gotta do this sort of thing: https://github.com/spiffe/helm-charts/pull/68/files#diff-8d33a0cb93c24fe8f2967716c7f6caef6fc2ba4854597ecf6cb7ec0d1f2c46ebR6-R7

[marcofranssen]

My main concern is how we can guarantee we don't introduce vulnerabilities from allowing to expose insecure ingress configurations. Maybe we should also consider a opiniated out of the box secure setup. I'm fine with both, but I think we need to discuss this and agree collectively on the solution design.

Hmm..... Yeah, I understand trying to save the user from themselves.... how to do it though, since that part of the k8s api was never standardized....

We could force the annotations in unless they disable them, but its still not guaranteed another ingress controller would honor them. in fact, aws seems to do it quite differently: kubernetes-sigs.github.io/aws-load-balancer-controller/v2.2/guide/tasks/ssl_redirect/#example-ingress-manifest

It would be a pretty ugly game of wack a mole...

One option might be to need an extra value when enabling ingress that states: IHaveReadTheInstructions:true before it allows the chart to be installed with ingress.enabled true? Then they have the opportunity to review the instructions, and if they set it without looking, its on them?

Yeah, difficult topic, I think for this PR due to the SNI part it is less of an issue. I think we can still add the annotations I suggested here and then merge it if other maintainers agree.

@faisal-memon what is your thoughts on this? Or should we check with the SSC?

[faisal-memon]

Thinking about this one and how it relates to the [same thing done with the oidc](https://github.com/spiffe/helm-ch
/arts/commit/cc7121e021cf8f569ced4a6dd767f9fdf5c32da9). If both are deployed will we be then deploying 2 ingress controllers?

Im wondering if a better way to do this would be to do this would be for people to use the [official ingress nginx chart]~~ (https://artifacthub.io/packages/helm/ingress-nginx/ingress-nginx) and provide the config to link with that. Similar to how we do with external databases. Then you can just have a single nginx to expose whatever ingress you want.

Im also concerned about maintaining an embedded nginx subchart and having to maintain versions, testing, api changes, etc

[faisal-memon]

Nm, disregard the above. We are just deploying the ingress resource, not the controller.

[faisal-memon]

Overall this looks good to me. There is some duplication with the 2 ingress templates? Is there any ways to condense that down with a helper?

[marcofranssen]

Few suggestions.

[mrsabath]

Once the ingress support is merged, we should work on instruction documentation on helping setup ingress in major cloud providers in context of the SPIRE deployment. See the issue #293

[marcofranssen]

LGTM