https://www.ory.sh/ logo
Join Slack
Powered by
Hello! Does anyone have experience successfully pr...
# talk-oathkeeper
p
Hello! Does anyone have experience successfully proxying a gRPC service with oathkeeper? I've tried a few match configurations to proxy my gRPC calls, but the requests show up as strange in the logs:
Copy code
oathkeeper_1 | time=2023-03-10T20:30:26Z level=info msg=started handling request http_request=map[headers:map[] host: method:PRI path:* query:<nil> remote:172.24.0.1:55394 scheme:http]
oathkeeper_1 | time=2023-03-10T20:30:26Z level=warning msg=Access request denied audience=application error=map[debug: message:Requested url does not match any rules reason: stack_trace:
(This is running in docker desktop) I would expect to see the gRPC calls making http/2 post requests, but it's coming up with this strange 
method:PRI
. Here's my match rule:
Copy code
-
  id: "grpc:public"
  upstream:
    url: "<http://localhost:9001>"
    preserve_host: true
  match:
    url: "<http://localhost:4455/><**>"
    methods:
      - POST
      - HEAD
      - GET
      - PUT
      - PATCH
      - DELETE
      - CONNECT
      - TRACE
  authenticators:
    -
      handler: anonymous
  authorizer:
    handler: allow
  mutators:
    -
      handler: noop
Where localhost:9001 is running my gRPC service. I also tried this match config, seeing there's some level of support with gRPC (via middleware?), but that had the same results
Copy code
match:
    authority: localhost:4455
    full_method: services.reports.v1.ReportsService/CreateGuestToken
Any help would be appreciated - thank you!
f
just a guess.. but 
method:PRI
p
I think that's what's going wrong, but my understanding is that oathkeeper proxy supports http/2. The 
method:PRI
seems like a part of the http/2 spec - https://www.rfc-editor.org/rfc/rfc7540#section-3.5
I'm not sure if it's something I've set up wrong, or if this is an area of http/2 that oathkeeper's not sure how to handle
f
did you addi it to the list of allowable methods in the rule?
Copy code
match:
p
Good idea, let me try
Same issue. I'm still learning about http/2 but it sounds like the 
PRI
method is part of a connection handshake/preface, and would look like:
Copy code
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"
Which probably corresponds to this:
Copy code
Not Found status_code:404] http_request=map[headers:map[x-forwarded-for:172.24.0.1] host: method:PRI path:* query:<nil> remote:172.24.0.1:55448 scheme:http] http_response=map[status_code:404]
I wonder if I need a special match rule to just pass anything with this special method along to my backing server
Trying this, I'm not seeing match:
Copy code
-
  id: "http2:pri"
  upstream:
    url: "<http://localhost:9001>"
    preserve_host: true
  match:
    url: "*"
    methods:
      - PRI
  authenticators:
    -
      handler: anonymous
  authorizer:
    handler: allow
  mutators:
    -
      handler: noop
f
the other odd thing that stands out is.. whats going on with that host being nil
p
Definitely. This is the first I've read about the 
PRI
method in http/2. From the spec, this sounds like a valid thing, though.
Copy code
This method is never used by an actual client.
      This method will appear to be used when an HTTP/1.1 server or
      intermediary attempts to parse an HTTP/2 connection preface.
So I wonder if missing typical request data is just characteristic of this special-case http method
I'll dig further on the raw requests next week. Have a great weekend!
For a follow up on this for anyone curious. I think oathkeeper has trouble supporting the http/2 "h2c" flow, which includes a special method request (the method is "PRI"). The requests I was seeing failing are initialization of the "h2c" protocol of http/2, which is the unencrypted form of http/2. • This is http/2 over plaintext rather than over TLS. • See: https://httpd.apache.org/docs/2.4/howto/http2.html Here's an issue with a different proxy, but it shows the same problem, and a workaround when setting up that proxy: https://github.com/elazarl/goproxy/issues/407 And here's a go package that implements h2c as a wrapper: https://pkg.go.dev/golang.org/x/net/http2/h2c My workaround was to enable TLS on my gRPC service, so it doesn't go through this handshake. However, it seems like this is a part of http/2 that oathkeeper doesn't currently handle - I'm thinking this is a bug
18 Views
Open in Slack
PreviousNext
Powered by