Enable filtering with HTTP properties configured through yaml

[lukasz-kaminski]

Currently, we're always using path, method and JWT to make queries to OPA. We should allow for better elasticity.

[anderseknert]

Would it make sense to forward the whole HTTP request "as-is" (as much as that is possible) as an option to provide OPA with all data available there?

[lukasz-kaminski]

I guess we can provide an array of http properties that users can request in their config file, also JWT. Like

opa.filter.request-include:
   jwt: encrypted (/decrypted)
   http:
     method: true
     path: true
     headers: [Content-Type, Origin]

So that would be the default implementation and it could be overridden or extended to add some custom data to the request.

What do you think?

[anderseknert]

The reason to filter out attributes from the original request would be to keep the payload size low?

I'm not sure I find the special treatment of JWTs necessary - checking for its presence in the headers inside a policy is trivial anyway, no?

And there should probably be an option to include the body. at least given some content types.

Besides that, I like it :)

[lukasz-kaminski]

The reason to filter out attributes from the original request would be to keep the payload size low?

Yes, also some of those might be sensitive and they don't necessarily have to be sent to localhost, OPA instance might be remote.

I'm not sure I find the special treatment of JWTs necessary - checking for its presence in the headers inside a policy is trivial anyway, no?

You're right, I don't know why I fixated on this :)

And there should probably be an option to include the body. at least given some content types.

Of course, properties I've posted above are only an example.

Besides that, I like it :)

I'm glad to hear that!

[lukasz-kaminski]

So for the first version of this feature I'll go with the following:

--- 
opa.filter.data.http: 
  method:
    include: all # or none - by default
    except:
      - OPTIONS
  path:
    include: all # or none - by default
    except:
      - /setPassword # because the password is sent in query params
  headers: 
    include: all # or none - by default
    except:
    - Content-Type
    - Origin
    - Authorization
    - bla # any string really
  sessionId.include: true # false by default
  cookies:
    include: all # or none - by default
    except:
      - secretToken
  queryParams.include: true # false by default
  body.include: true # false by default

[anderseknert]

Looks great. Is include also a list or can you only say all and blacklist?

[lukasz-kaminski]

Yeah, the idea is to have two ways:

include: all
except:
  - something

and

include: none
except:
  - something

[anderseknert]

Awesome!