Application-gateway-kubernetes-ingress: Pull TLS certificates from KeyVault

Created on 19 Feb 2019  路  14Comments  路  Source: Azure/application-gateway-kubernetes-ingress

Is your feature request related to a problem? Please describe.
You currently need to pull secrets from Azure Key Vault manually, transform them and then create a Kubernetes secret. Ideally this would be tightly integrated with Key Vault and certificates, with rotating in keyvault updating the certificate on the application gateway.

Describe the solution you'd like
Either:

feature AG feature parity

Most helpful comment

@akshaysngupta

This would be very helpful to have. I would like to try avoiding having to update certs in many places, so pulling from the KeyVaut would be ideal. Is this something that will be looked at in the near future, or is it months (or more) from being worked on?

All 14 comments

This needs a little bit of thought. AG v2 already supports keyvault integration, we need to think through how we will be exposing that integration here.

+1

It would be very useful to be able to use the native KeyVault support from AG V2 with something like:

  tls:
    - secretProvider: azureKeyVault
    - secretName: <myKeyVaultSecretId>

With secretProveider defaulting to "kubernetes" which would be the current way of doing it.

@asridharan shouldn't that be tagged with "AG feature parity"?

Hi any news on that feature ?

Is it maybe scheduled for some specific release?

@akshaysngupta

This would be very helpful to have. I would like to try avoiding having to update certs in many places, so pulling from the KeyVaut would be ideal. Is this something that will be looked at in the near future, or is it months (or more) from being worked on?

I am trying to solve a scenario which involves ingresses in multiple namespaces.
This setup seems to work if I create the secret my-host-com-tls in every namespace where the ingress is applied..
(https://github.com/Azure/application-gateway-kubernetes-ingress/blob/master/docs/tutorial.md#with-specified-hostname)

The downside with this approach is of course that the certificate will need to be deployed as a secret in every single namespace. A better approach would be to store the certificate in Key Vault and reference that from the ingresses as proposed. Or at least reuse a certificate in another namespace which is supported in the stable/nginx-ingress helm package:

--set controller.extraArgs.default-ssl-certificate=sharednamespace/my-host.com-tls

_Configuring multiple ingresses in multiple namespaces requires a secret in every namespace_

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: http-svc
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  tls:
    - hosts:
      - my.host.com
      secretName: my-host-com-tls
  rules:
  - host: my.host.com
    http:
      paths:
      - path: /echo
        backend:
          serviceName: http-svc
          servicePort: 80

This is a very useful feature. Do you have any plans to develop it?

Hey all - this is definitely a useful feature and is on our roadmap.

Any updates? @mscatyao

Any updates? @mscatyao

@akshaysngupta, since the PR is merged, is the issue resolved?

Yes, this issue is resolved. Please try version 1.2.0-rc1.
Here are the instructions to use the appgw-ssl-certificate annotation

Was this page helpful?
0 / 5 - 0 ratings