How to use Existing Cert Store with EasyAuth?

[brandonsmith86]

Referring to the getting started guide, it instructs you to create cert-manager resource to encrypt easyauth endpoints. Our organization is already using a csi secret provider to encrypt our ingress endpoints. Is it currently possible to leverage this existing resource instead of having to manage a new one? If not, is this feature on the roadmap?

[jonlester]

@brandonsmith86 Thanks for submitting this issue. The EasyAuth pod requires TLS but is otherwise is provider-agnostic as far as this goes. After configuring your secret provider you can modify the ingress for EasyAuth and update the deployment. We originally used lets-encrypt as the example, given the simplicity and what was available at the time, but your call-out is probably a good reason to revisit this. We'll take a look at switching the default configuration in an upcoming release.

[karpikpl]

Hey @jonlester
the EasyAuth pod just needs TLS for itself - https://$APP_HOSTNAME/easyauth/signin-oidc so this reply URL works with AAD?
it does not depend on any other certs created by let's encrypt?

when the redirect from AAD goes through the ingress controller, isn't it enough that ingress has TLS/cert provided?

[jonlester]

Hey @jonlester the EasyAuth pod just needs TLS for itself - https://$APP_HOSTNAME/easyauth/signin-oidc so this reply URL works with AAD? it does not depend on any other certs created by let's encrypt?

• That's correct. letsencrypt was just the easiest implementation at the time to provide TLS for the whole cluster, as a working sample (including the sample app).

when the redirect from AAD goes through the ingress controller, isn't it enough that ingress has TLS/cert provided?

• Yes. It just needs to use TLS. There aren't any other constraints.

[karpikpl]

ok, so I think I understand it :)
if I don't want to use cert-manager but already have a way to secure traffic to our cluster. we would need to modify the way we deploy EasyAuth.

right now chart needs a tlsSecretName:

helm install --set azureAd.tenantId=$AZURE_TENANT_ID --set azureAd.clientId=$CLIENT_ID --set secret.name=easyauth-proxy-$AD_APP_NAME-secret --set secret.azureclientsecret=$CLIENT_SECRET --set appHostName=$APP_HOSTNAME --set tlsSecretName=$TLS_SECRET_NAME easyauth-proxy-$AD_APP_NAME ./charts/easyauth-proxy

which is used in the easyAuth ingress: https://github.com/Azure/EasyAuthForK8s/blob/master/charts/easyauth-proxy/templates/ingress.yaml

we can deploy it without ingress using ingress.enabled=false ?

helm install --set azureAd.tenantId=$AZURE_TENANT_ID --set azureAd.clientId=$CLIENT_ID --set secret.name=easyauth-proxy-$AD_APP_NAME-secret --set secret.azureclientsecret=$CLIENT_SECRET --set appHostName=$APP_HOSTNAME --set ingress.enabled=false easyauth-proxy-$AD_APP_NAME ./charts/easyauth-proxy

and create that ingress ourselves.

alternatively - a param could be added by a PR to skip TLS when it's done on the ingress controller level:

spec:
  tls:
  - hosts:
    -  {{ .Values.appHostName }}
    #{{- if .Values.ingressTlsEnabled}}
    secretName:  {{ .Values.tlsSecretName }}
    #{{- end }}

[karpikpl]

I think I overcomplicated this by a lot.
the only thing needed in our particular case (where we don't have access to tls Secret because it's managed by OPS team on the ingress controller level) is to:

1. Modify charts/easyauth-proxy/templates/ingress.yaml and comment out tls secret:

     tls:
     - hosts:
       -  {{ .Values.appHostName }}
       # secretName:  {{ .Values.tlsSecretName }}

2. Deploy

   # Go to the root of the repo before running this command
   helm install --set azureAd.tenantId=$AZURE_TENANT_ID --set azureAd.clientId=$CLIENT_ID --set secret.name=easyauth-proxy-$AD_APP_NAME-secret --set secret.azureclientsecret=$CLIENT_SECRET --set appHostName=$APP_HOSTNAME easyauth-proxy-$AD_APP_NAME ./charts/easyauth-proxy
   
   # Confirm everything was deployed.
   kubectl get svc,deploy,pod

I think this can be closed, unless you think there's value in updating the docs? (which I can do)