curious why we are choosing AND here
OR fits here better

or maybe we can't use HeaderMatch here and may need some other type

here is the use case, id like to deny traffic when x-geoip-country contains foo or bar
so maybe

headers:
- name: x-geoip-country
   values:
   - "foo"
   - "bar"  

fits better here
cc @nezdolik

OR can be easily achieved with separate rules, but there is no good way to implement AND expect here. This approach also aligns with the Gateway API HTTPRouteMatch behavior, where multiple HTTPHeaderMatch are ANDed together.

For example, a common use case is setting the default action to Deny while allowing requests from John and Alice in the sales apartment.

    authorization:
      defaultAction: Deny
      rules:
      - action: Allow
        principal:
          headers:
          - name: x-user-id
            value: john
          - name: x-org-id
            value: sales
      - action: Allow
        principal:
          headers:
          - name: x-user-id
            value: alice
          - name: x-org-id
            value: sales

For the use case in your comment：

    authorization:
      defaultAction: Allow
      rules:
      - action: Deny
        principal:
          headers:
          - name: x-geoip-country
            value: foo
      - action: Deny
        principal:
          headers:
          - name: x-geoip-country
            value: bar

One potential concern of this approach is that the rules could be a long list if there are many countries, but if we move OR logic into the headers, the headers can also be lengthy, so there is no fundamental difference between these two approaches.

We could also make header match highly flexibl, allowing expressing logic such as ((foo == bar || foo1 == bar1) && foo2 == bar2). However, this would significantly increase UI complexity. It would not be intuiative for end users, as there would be too many layers of condition combinations.

    authorization:
      defaultAction: Allow
      rules:
      - action: Deny
        principal:
          headers:
          - name: x-geoip-country
            value: foo
      - action: Deny
        principal:
          headers:
          - name: x-geoip-country
            value: bar

is too lengthy, the common case is there will be hundreds of such entries, which requires 5x more lines

your previous example could be reduced to

    authorization:
      defaultAction: Deny
      rules:
      - action: Allow
        principal:
          headers:
          - name: x-user-id
            values:
            - alice
            - john
          - name: x-org-id
            values: 
            - sales

Ha, you're right! I was blind by trying to reuse the exiting HeaderMatch, instead, an array should be used for header value:

    authorization:
      defaultAction: Deny
      rules:
      - action: Allow
        principal:
          headers:
          - name: x-user-id
            values: [john, alice]
          - name: x-org-id
            values: sales

    authorization:
      defaultAction: Allow
      rules:
      - action: Deny
        principal:
          headers:
          - name: x-geoip-country
            values: [foo, bar, ...]

This is similar to what we have done for JWT:

        principal:
          jwt:
            provider: example1
            scopes: [foo, bar]

should methods live in the top level outside principal because its falls under actions / operation performed by the principal

Yeah, moving methods outside of principal looks better.

referencing istio here https://istio.io/latest/docs/reference/config/security/authorization-policy/#Operation
should we have a top level operation here ?
so we can have operation.methods and leave room for operation.paths in the future ?

A new AuthorizationHeaderMatch is introduced here, as the existing HeaderMatch is not suitable for authorization use case.

Only exact matches are supported for now. It should be good enough for authorization. If use cases for other matching types arise, we can add a MatchingType field later.

This existing comment seems to be in wrong place. Moving it to the header comment.