facing issue while installing KEDA 2.10.0 on EKS 1.25 cluster

[chaithraPadmar]

hi,

Am trying to install KEDA 2.10.0 on EKS 1.25 cluster
while installing the KEDA helm chart ; the keda-operator fails for certs related issues

could you kindly help me with below values config if i want to load a self signed certs into secrete and use it in KEDA 2.10.0 intall

certificates:
  # -- Enables the self generation for KEDA TLS certificates inside KEDA operator
  autoGenerated: true
  # -- Secret name to be mounted with KEDA TLS certificates
  secretName: kedaorg-certs
  # -- Path where KEDA TLS certificates are mounted
  mountPath: /certs
  certManager:
    # -- Enables Cert-manager for certificate management
    enabled: false
    # -- Generates a self-signed CA with Cert-manager.
    # If generateCA is false, the secret with the CA
    # has to be annotated with `cert-manager.io/allow-direct-injection: "true"`
    generateCA: true
    # -- Secret name where the CA is stored (generatedby cert-manager or user given)
    caSecretName: "kedaorg-ca"

---

My queries are as below:-
in the above values what should be kedaorg-certs and "kedaorg-ca" if am using a self signed certs
the certs should be mounted to what path; if i load a secret generated using tls; it looks for ca.crt and i get that error
if i comment the secrete name ; helm fails

so what kind of secrete one has to generate and how to implement; could you kindly brief out

Regards
Chaithra

[tomkerkhove]

Hi, 2.10 is 4 versions behind - Would you mind trying 2.13, 2.12 or 2.11 please and see if the issue persists?

[chaithraPadmar]

Hi,

Thank you for suggestion

Am been left with option to use 2.10.0, due to some other undiscloable restrictions,
Kindly help for these values, or it will be very helpful if u brief out on the combinations of these.key pair values

1.when we use self signed certs
2. When we use ca certs

[zroubalik]

Have you followed these steps? It's pretty straightforward: https://keda.sh/docs/2.13/operate/security/#use-your-own-tls-certificates

[chaithraPadmar]

Hi Yes, i followed the instructions for 2.10.0 My query is specifically for TLS part If am using autoGenerate set to false in helm values for certificate, then to ise self signed or CA certs, will the classic approach of using secrets and secreteprovider works? Or is it manadate for cluster to have Certmanager.installled Am trying to use On AWS EKS 1.25 cluster Regards Chaithra

…

On Mon, 22 Jan 2024, 18:27 Zbynek Roubalik, ***@***.***> wrote: Have you followed these steps? It's pretty straightforward: https://keda.sh/docs/2.13/operate/security/#use-your-own-tls-certificates — Reply to this email directly, view it on GitHub <#5418 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVVEPIP5X2S7P7P77G7PTRTYPZO2HAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DEMBYGMYDI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[chaithraPadmar]

Hi,

Yes, i followed the instructions for 2.10.0

My query is specifically for TLS part

If am using autoGenerate set to false in helm values for certificate, then to use self signed or CA certs, will the classic approach of using secrets and secreteprovider works?

Or is it manadate for cluster to have Certmanager.installled

Am trying to use On AWS EKS 1.25 cluster

Awaiting a reply

[JorTurFer]

Hi @chaithraPadmar
If you want to use your own certificates generated by yourself and totally unmanaged by KEDA but also not using cert-manager, you can do it just disabling the autogeneration and giving the secret name where the certificate is stored:

certificates:
  autoGenerated: false
  secretName: YOUR_SECRET_WITH_THE_CERT

Just with these lines, KEDA won't generate its own certs, and you are the responsible for generating them.
The secret needs to have at least these keys (they aren't configurable):

• tls.crt
• tls.key
• ca.crt

In this scenario, you are also the owner of the certs and the support for them. This means that you will have to patch the ApiService and ValidatingWebhookConfiguration to include the caBundle with your certificate CA. If you don't do this, although KEDA components will be able to work together, the API Server will fail calling KEDA (metrics server and webhooks) because it doesn't trust in KEDA certificates.

If you prefer to use your own CA but you don't want to be responsible for rotating the cert and patching the resources, you can use cert-manager with your own CA, but it's just optional to help handling the process, not mandatory at all

[chaithraPadmar]

Hi Thank you for your email I could being up operator and metrics server Will tryout scaled jobs for azure pipelines and in case of any further queries, will reach out to you Thanks a lot Regards Chaithra

…

On Wed, 7 Feb 2024, 05:51 Jorge Turrado Ferrero, ***@***.***> wrote: Hi @chaithraPadmar <https://github.com/chaithraPadmar> If you want to use your own certificates generated by yourself and totally unmanaged by KEDA but also not using cert-manager, you can do it just disabling the autogeneration and giving the secret name where the certificate is stored: certificates: autoGenerated: false secretName: YOUR_SECRET_WITH_THE_CERT Just with these lines, KEDA won't generate its own certs, and you are the responsible for generating them. The secret needs to have at least these keys (they aren't configurable): - tls.crt - tls.key - ca.crt In this scenario, you are also the owner of the certs and the support for them. This means that you will have to patch the ApiService and ValidatingWebhookConfiguration to include the caBundle with your certificate CA. If you don't do this, although KEDA components will be able to work together, the API Server will fail calling KEDA (metrics server and webhooks) because it doesn't trust in KEDA certificates. — Reply to this email directly, view it on GitHub <#5418 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVVEPINESEVFXQV32XIE7JTYSLCIZAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGOBZGQZTA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chaithraPadmar]

Hi, I have a question related to metrics server I will be using the azure-pipelines in triggers My keda-metrics-server has error related to ×509 certa handshake In keda metrics server deployment, could you pleasd suggest the complete --args parametrs Regards Chaithra

…

On Fri, 9 Feb 2024, 21:55 chaithra bhat, ***@***.***> wrote: Hi Thank you for your email I could being up operator and metrics server Will tryout scaled jobs for azure pipelines and in case of any further queries, will reach out to you Thanks a lot Regards Chaithra On Wed, 7 Feb 2024, 05:51 Jorge Turrado Ferrero, ***@***.***> wrote: > Hi @chaithraPadmar <https://github.com/chaithraPadmar> > If you want to use your own certificates generated by yourself and > totally unmanaged by KEDA but also not using cert-manager, you can do it > just disabling the autogeneration and giving the secret name where the > certificate is stored: > > certificates: > autoGenerated: false > secretName: YOUR_SECRET_WITH_THE_CERT > > Just with these lines, KEDA won't generate its own certs, and you are the > responsible for generating them. > The secret needs to have at least these keys (they aren't configurable): > > - tls.crt > - tls.key > - ca.crt > > In this scenario, you are also the owner of the certs and the support for > them. This means that you will have to patch the ApiService and > ValidatingWebhookConfiguration to include the caBundle with your > certificate CA. If you don't do this, although KEDA components will be able > to work together, the API Server will fail calling KEDA (metrics server and > webhooks) because it doesn't trust in KEDA certificates. > > — > Reply to this email directly, view it on GitHub > <#5418 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AVVEPINESEVFXQV32XIE7JTYSLCIZAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGOBZGQZTA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[JorTurFer]

I will be using the azure-pipelines in triggers

I'd suggest using ScaledJobs instead of ScaledObjects for it

My keda-metrics-server has error related to ×509 certa handshake

Does your certificate contain the domain keda-operator.keda.svc.cluster.local? It's the default host used for the connection, if your certificate doesn't include it, the metrics server will fail the connection

[chaithraPadmar]

Hi Yes, we are going to use scaled jobs We could apin up the sample scaled jobs as well One error that still persissts is in metrics pod logs for certs It says something like this Remote error:tls :bad certificate Many ways i tried to add the local host and DNS mentioned above ( keda-operator.keda.svc.cluster.local) Or keda-operator.(mynamespace).svc.cluster.local Kindly note, since i donot have a keda namespace, i have deployed keda in Mynamespace Awaiting a reply Thanks Chaithra

…

On Thu, 15 Feb 2024, 13:55 Jorge Turrado Ferrero, ***@***.***> wrote: I will be using the azure-pipelines in triggers I'd suggest using ScaledJobs instead of ScaledObjects for it My keda-metrics-server has error related to ×509 certa handshake Does your certificate contain the domain keda-operator.keda.svc.cluster.local? It's the default host used for the connection, if your certificate doesn't include it, the metrics server will fail the connection — Reply to this email directly, view it on GitHub <#5418 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVVEPIPL25YOINOVWTFITCLYTXA7FAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINZWGQ3DM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JorTurFer]

Have you tried using default self generated certificates? I mean, if KEDA works using the certificates that KEDA generates, the problem is in the something related with the certs

[chaithraPadmar]

In addition to this, Do i need to use unsafessl in scaledjobs Also, in metrics api server.. Which one i should use? Insecureakipverify or insecureskiptlsverify?

…

On Sat, 17 Feb 2024, 14:41 chaithra bhat, ***@***.***> wrote: Hi Yes, we are going to use scaled jobs We could apin up the sample scaled jobs as well One error that still persissts is in metrics pod logs for certs It says something like this Remote error:tls :bad certificate Many ways i tried to add the local host and DNS mentioned above ( keda-operator.keda.svc.cluster.local) Or keda-operator.(mynamespace).svc.cluster.local Kindly note, since i donot have a keda namespace, i have deployed keda in Mynamespace Awaiting a reply Thanks Chaithra On Thu, 15 Feb 2024, 13:55 Jorge Turrado Ferrero, < ***@***.***> wrote: > I will be using the azure-pipelines in triggers > > I'd suggest using ScaledJobs instead of ScaledObjects for it > > My keda-metrics-server has error related to ×509 certa handshake > > Does your certificate contain the domain > keda-operator.keda.svc.cluster.local? It's the default host used for the > connection, if your certificate doesn't include it, the metrics server will > fail the connection > > — > Reply to this email directly, view it on GitHub > <#5418 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AVVEPIPL25YOINOVWTFITCLYTXA7FAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINZWGQ3DM> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[JorTurFer]

Do i need to use unsafessl in scaledjobs

What do you mean?

ScaledJobs don't use HPA or the metrics server. I mean, although you wouldn't fix the issue, ScaledJobs should work

[chaithraPadmar]

Hi, I donot have namespace by name keda to enable autogenerate certs In values if i overwrite with Mynamespace, the autogenerate cert looks for namespace Keda Can you please help to overwrite the namespace in autogeneration.. i will try that Regards Chaithra

…

On Sat, 17 Feb 2024, 20:23 Jorge Turrado Ferrero, ***@***.***> wrote: Have you tried using default self generated certificates? I mean, if KEDA works using the certificates that KEDA generates, the problem is in the something related with the certs — Reply to this email directly, view it on GitHub <#5418 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVVEPIP3FXT7HODIJISJOVLYUC74ZAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKMBRGE4TQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JorTurFer]

There were a bug in helm chart v2.10.0 which produced wrong generated manifests, but if you use latest v2.10 version, the certificate will be generated correctly. This was the fix: kedacore/charts@06ce12c

[JorTurFer]

(Maybe you need to delete the previously auto generated cert (in the namespace where KEDA is), I'm not 100% sure

[chaithraPadmar]

Hi Sorry to bother you again, From my experience of instaling keda in a different namespace named application-1 Is possible and am able to do it But, could you please help me to understand, which key value in values file will help to overwrite the cert generation namepace to any other values other than namespace keda Reagards Chaithra

…

On Sat, 17 Feb 2024, 21:33 Jorge Turrado Ferrero, ***@***.***> wrote: (Maybe you need to delete the previously auto generated cert (in the namespace where KEDA is), I'm not 100% sure — Reply to this email directly, view it on GitHub <#5418 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVVEPIODK3YY4HTHMUSRMCLYUDIELAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKMBRGU2DQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chaithraPadmar]

Hi.. We could install keda in a different namespace named application-1 But, could you please help me to understand, which key value in values file will help to overwrite the cert generation namepace to any other values other than namespace keda Auto generate certs is causing issue in Release.namespace other than keda Reagards Chaithra

…

On Sat, 17 Feb 2024, 21:33 Jorge Turrado Ferrero, < ***@***.***> wrote: > (Maybe you need to delete the previously auto generated cert (in the > namespace where KEDA is), I'm not 100% sure > > — > Reply to this email directly, view it on GitHub > <#5418 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AVVEPIODK3YY4HTHMUSRMCLYUDIELAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKMBRGU2DQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[JorTurFer]

I sent you, this commit released as part for helm chart v2.10. solves it: kedacore/charts@06ce12c

Could you confirm that you are using AT LEAST the chart v2.10.1? (and not v2.10.0)

[chaithraPadmar]

Hi, Thank you for your email I could progress to deploy on a env Could you please help with below query Do we need to specify any specific proxy settings in scaled jobs for azure-pipeline triggers in EKS? Am unable to open discussion.hence am emailing Thanks and regards Chaithra

…

On Sat, 24 Feb 2024, 02:03 Jorge Turrado Ferrero, ***@***.***> wrote: I sent you, this commit released as part for helm chart v2.10. solves it: ***@***.*** <kedacore/charts@06ce12c> Could you confirm that you are using AT LEAST the chart v2.10.1? (and not v2.10.0) — Reply to this email directly, view it on GitHub <#5418 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVVEPIIOBEN256BNNEEKLJ3YVD4K5AVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKNZSG4ZDO> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JorTurFer]

Do we need to specify any specific proxy settings in scaled jobs for
azure-pipeline triggers in EKS?

It depends on your business configuration. I mean, if your EKS can reach AzDo server without the proxy, you don't need a proxy, if your network enforces a proxy in the middle, you will need it

[chaithraPadmar]

Team, When we use azure pipeline trigger in scaledjob ON EKS, any issues reported with cluster controller And how to de register this. Regards Chaithra

…

On Sat, 16 Mar 2024, 04:21 Jorge Turrado Ferrero, ***@***.***> wrote: Do we need to specify any specific proxy settings in scaled jobs for azure-pipeline triggers in EKS? It depends on your business configuration. I mean, if your EKS can reach AzDo server without the proxy, you don't need a proxy, if your network enforces a proxy in the middle, you will need it — Reply to this email directly, view it on GitHub <#5418 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVVEPIIH46347QL5IOTNLQDYYN3QDAVCNFSM6AAAAABCC6DJW6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DQMBYGAZTK> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JorTurFer]

And how to de register this.

Do you mean how to uninstall KEDA? As you have used helm, you can just execute helm uninstall keda -n keda (updating values accordingly to yours)