search

SparebankenVest / public-helm-charts

Public Helm charts provided by Sparebanken Vest
https://charts.spvapi.no
28 stars 51 forks source link

unable to read secret in kong ingress after certificate renew #122

Open ruchi1803 opened 8 months ago

ruchi1803 commented 8 months ago

Setup: CA provider - Entrust Certificate storage: AKV custom app for renew: https://github.com/shibayan/keyvault-acmebot Use Case: Kong ingress controller reading K8s secret.

Issue Description: The applications hosted in AKS are using kong ingress controller and reading the k8s secret certificate from AKV which are exported from akv deployment running in our cluster. The AzureKeyVaultSecret is not creating the k8s secret in right order I see the serverCertificate is in middle which is unable to read by kong due to in proper chain order. Even if I use chainOrder: ensureserverfirst then also kong is unable to read as it expects the server Certificate in last. I manually edit the certificate chain order and kept the server Certificate in last which solved my issue and kong was able to read the secret. But I cant do this every time.

Suggestion: Like the parameter chainOrder: ensureserverfirst can there be value ensureserverlast to ensure the server Certiticate at last.

AndersRunningen commented 8 months ago

Hi @ruchi1803,

We had some similar issues with Nginx, but managed to fix it by using the setting Acmebot:MitigateChainOrder together with chainOrder: ensureserverfirst from Akv2K8s.

ruchi1803 commented 8 months ago

Thanks @AndersRunningen I already tried chainOrder: ensureserverfirst it works with nginx but we are using kong gateway and its not working with Kong. Another one Acmebot:MitigateChainOrder I will try and verify.

wimi commented 7 months ago

Hi @ruchi1803, ensureserverfirst property has a bit misleading description "the server certificate will be moved first in the chain". It doesn't really have the logic to determine the type of certificate and the only thing it does is moving the last certificate into first position. And it works well for generators that put server certificate last, but will not do the job if chain is in different order.

If you could take a look at generator, which places pfx into azure keyvault, maybe there are some options to change this? Otherwise the only viable way is to change the logic in akv2k8s, but that might be a bit trickier than current implementation: https://github.com/SparebankenVest/azure-key-vault-to-kubernetes/blob/647b7156685907bb1c5257c9e0596f4eab355165/pkg/azure/keyvault/client/certificate.go#L190