feat: authorization implementation

[zhaohuabing]

This PR adds gateway API translator, XDS translator, and e2e tests for the Authorization setting of the SecurityPolicy.

Only source IP is supported for now. Other principals such as JWT claims, basic auth, etc. will be supported later.

Fix: #2462
Related: #2250

Example config:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-with-authorization-client-ip
  namespace: gateway-conformance-infra
spec:
  parentRefs:
  - name: same-namespace
  rules:
  - matches:
    - path:
        type: Exact
        value: /protected
    backendRefs:
    - name: infra-backend-v1
      port: 8080
---
      
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: authorization-client-ip
  namespace: gateway-conformance-infra
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: http-with-authorization-client-ip
  authorization:
    defaultAction: Deny
    rules:
    - action: Allow
      principal:
        clientCIDRs:
        - 10.0.1.0/24
        - 10.0.2.0/24
---

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
  name: enable-client-ip-detection
  namespace: gateway-conformance-infra
spec:
  clientIPDetection:
    xForwardedFor:
      numTrustedHops: 1
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: same-namespace

Test results:

curl -I --header "Host: www.example.com" --header "X-Forwarded-For: 10.0.2.1" http://172.18.255.203:80/protected
HTTP/1.1 200 OK

curl -I --header "Host: www.example.com" --header "X-Forwarded-For: 10.0.3.1" http://172.18.255.203:80/protected
HTTP/1.1 403 Forbidden

[codecov]

Codecov Report

Attention: Patch coverage is 81.73913% with 42 lines in your changes are missing coverage. Please review.

Project coverage is 67.37%. Comparing base (dd35514) to head (5a37c9e).

Files	Patch %	Lines
internal/xds/translator/authorization.go	78.01%	16 Missing and 15 partials ⚠️
internal/gatewayapi/securitypolicy.go	90.62%	3 Missing and 3 partials ⚠️
internal/gatewayapi/helpers.go	81.81%	1 Missing and 1 partial ⚠️
internal/gatewayapi/backendtrafficpolicy.go	75.00%	1 Missing ⚠️
internal/xds/translator/local_ratelimit.go	50.00%	0 Missing and 1 partial ⚠️
internal/xds/translator/ratelimit.go	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3399      +/-   ##
==========================================
+ Coverage   67.25%   67.37%   +0.11%     
==========================================
  Files         166      167       +1     
  Lines       19722    19914     +192     
==========================================
+ Hits        13265    13418     +153     
- Misses       5503     5522      +19     
- Partials      954      974      +20     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[arkodg]

LGTM thanks !

[zhaohuabing]

I am testing this and got error

'Unable to translate authorization rule: invalid CIDR address: 1.2.3.4'

I could apply the configuration fine, but I was wondering why it was not provisioned. I could see that error in securitypolicy status. Just thinking, should it be validated in creation of securitypolicy that ip address contains mask as well?

Good point. I added a regex validation for CIDR. It should prevent most invalid input such as lacking of mask, but still need a second check in gateway API translation for some corner cases.

Otherwise looks good, I have verified and looks like working like should. However, I am just thinking that we might need to split the filter to two different rbac filters? I am thinking like ip policies as first in order, and then others after authentication things like jwt (that we can use jwt information for authorization)?

I actually proposed the same during the API review. :-)

Most gateway implementations have a standalone IP Allow/Deny list. However, some, like the Istio Authorization API, integrate this feature into their Authorization API.

Incorporating the client IP range in the Authorization enables use cases that require a combination of the client IP and other conditions. For instance, " allows admin users access an HTTPRoute from use-west-region, but not from other regions", which is either impossible or significantly challenging to implement with two independent filters.

[zirain]

LGTM, please fix the conflict.

[zetaab]

one nit, otherwise lgtm

[zetaab]

perhaps prettier would be use golang in https://github.com/envoyproxy/gateway/blob/main/api/v1alpha1/validation/securitypolicy_validate.go to check that its valid?

[zhaohuabing]

It's two-level validation, first level is k8s API server, the second level is in gateway API translation in parseCIDR method.