Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default chart values break outbound HTTPS in Istio clusters #500

Closed
jhuffman-wyn opened this issue Jul 26, 2023 · 6 comments
Closed

Default chart values break outbound HTTPS in Istio clusters #500

jhuffman-wyn opened this issue Jul 26, 2023 · 6 comments
Labels
bug Something isn't working

Comments

@jhuffman-wyn
Copy link

Discovered a weird one today. If you have the following setup:

  1. Keda installed with admission webhook (default settings)
  2. Istio installed with applications using Istio sidecar containers

...all outbound HTTPS traffic will be blocked with mysterious "SSL protocol failure" and similar errors. This is due to an unpleasant interaction between keda and Istio, and while the onus may be on Istio to fix, keda can also proactively avoid contributing to it.

Expected Behavior

HTTPS traffic is able to reach external endpoints without issue.

Actual Behavior

All HTTPS traffic on pods with Istio sidecars is blocked with TLS/SSL protocol errors.

Steps to Reproduce the Problem

  1. Install Istio (any recent version) with default settings.
  2. Install current keda version with default settings.
  3. Have at least one pod with an Istio sidecar.
  4. From within that pod, attempt to reach any external HTTPS endpoint.
  5. You will get a TLS/SSL error.

Note that this blog is what informed me of the issue: https://fable.sh/blog/istio-port-443-and-ssl-errors./

That's not specific to keda, but it is apparent that the Istio fix did not account for every scenario: istio/istio#16458

This is being logged as a keda bug as changing the admission webhook service can easily avoid causing this problem:

apiVersion: v1
kind: Service
metadata:
  name: keda-admission-webhooks
spec:
  ...
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: http
    port: 443 
    protocol: TCP
    targetPort: 9443
  selector:
    app: keda-admission-webhooks
  sessionAffinity: None
  type: ClusterIP

The specific combination of the port name being http and the port being 443 causes this. Changing either of those values will avoid this. Calling it http-web, for instance, will do the job just fine.

Specifications

  • KEDA Version: 2.11.1
  • Platform & Version:
  • Kubernetes Version: GKE 1.24
  • Scaler(s): N/A
@jhuffman-wyn jhuffman-wyn added the bug Something isn't working label Jul 26, 2023
@JorTurFer
Copy link
Member

Interesting...
Are you willing to contribute with the fix?

@congzhegao
Copy link
Contributor

congzhegao commented Oct 19, 2023

nvm

@zroubalik
Copy link
Member

@congzhegao you need to open a PR from your fork, so fork this repo, commit the change there to some branch and then open PR from the branch on your fork.

@zroubalik
Copy link
Member

btw, this should be also fixed on the core https://github.com/kedacore/keda/blob/main/config/webhooks/service.yaml

@congzhegao
Copy link
Contributor

@JorTurFer
Copy link
Member

Both PRs are merged, so I close the issue as solved. Changes will be released soon (we plan to cut a release these weeks)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants