Invalid external auth provider config prevents istio-proxy starting

Stono commented 2 months ago

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description

I've been fiddling with the external http auth provider in meshconfig, eg:

    extensionProviders:
    - name: platform-identity-provider 
      envoyExtAuthzHttp:
        service: app.platform-identity-provider.svc.cluster.local 
        port: 80
        timeout: 1.5s
        includeRequestHeadersInCheck: ["authorization", "cookie"]
        headersToUpstreamOnAllow: ["x-forwarded-access-token", "authorization", "path", "x-auth-request-user", "x-auth-request-email", "x-auth-request-access-token"]
        headersToDownstreamOnDeny: ["content-type", "set-cookie"]
        failOpen: false 
        statusOnError: '403'
        pathPrefix: /oauth2/istio
        includeAdditionalHeadersInCheck:
          x-auth-request-client-id: '%ENV(ISTIO_META_WORKLOAD_NAME)%'

The problem in the config above is on the x-auth-request-client-id, i can't get it to work (it's accepted by istiod however), it just wasn't working (the error is it should be ENVIRONMENT, not ENV).

I decided to restart the workload to see if it was some sort of non-updating config issue, but then the proxy failed to start:

{"level":"warn","time":"2024-08-06T09:31:19.700752Z","msg":"Envoy proxy is NOT ready: config received from XDS server, but was rejected: cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected"}

And the workload was stuck.

Removing includeAdditionalHeadersInCheck allowed the workload to start.

Version

1.22

Additional Information

No response

hzxuzhonghu commented 2 months ago

How about validating this fields before applying

Stono commented 2 months ago

Do you mean in istiod's validator so it's rejected by the apiServer if invalid?

Stono commented 2 months ago

By extension to this I just messed up an envoyfilter

spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_OUTBOUND
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
            subFilter:
              name: envoy.filters.http.router
    patch:
      operation: INSERT_BEFORE
      value:
        name: decompressor
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.http.decompressor.v3.Decompressor
          decompressor_library:
            name: basic
            typed_config:
              '@type': type.googleapis.com/envoy.extensions.compression.gzip.decompressor.v3.Gzip
              chunk_size: 8192
              max_inflate_ratio: <---- set value bigger than the max (1032) here
              window_bits: 15

And that had the same effect, chaos :D feels like these typed_configs could be checked by a validating webhook?

istio / istio